FNE.JP::とあるIT系脱求職者の日記(仮称)

http://www.iodata.jp/company/guidance/message/index.htm
笑わせるわ。

ハンドルリークも直せないのに、『皆様のデジタルライフを支える存在』ってのは、北陸独特の冗談ですか？

今月も20日は土曜日だったので、物凄い混雑だったのですが、行ってきました。

20日に静岡駅へ行けば500円でランチ喰えますよ。
静岡中部の方々ならば、土日祝に重なれば、おかいものきっぷ使えますし。
＃きっぷは4月以降どうなるか、今のところ不明ですが。

別に、クローラーによって、httpsへのアクセスがあってもいいんですけど、さすがにhttps側のインデックス化は、オレオレ証明書サイトにとっては、ちょっとね。

http側にもほぼ同じ内容があるわけで、普通はhttp側をインデックス化するはずだと思っていたんだけど、ちょいとググったら、https側の検索結果。

まぁ、内容改ざんの危険性が無い方を優先ってことなら文句は言えないんだけど、にしても、http側の方が暗号化無い分、若干レスポンス速いと思うので上位に来てもいいはずと思っていたんだけど、このあたりどうなのか。

とりあえず、ググルさんからのボットアクセスに対しては、httpsリンクを張らないように手を入れてみたので、またしばらく様子見。

戸惑いだけでは先に進まない。

HLCOMP関数は-1,0,1を返すため、整数型を使っていた。
至極当然だろう。

だが、ここに落とし穴があった。

多桁数比較関数として、HLCOMPを用意してみたものの、Excel95のIF関数内で条件に使うと、なぜか#NUM!エラーになる。

HLCOMPを別セルで計算して、その値を条件に使えば問題ないし、IF関数の真偽値としてエラーを返す可能性の無いリテラルを指定すれば、これもエラーにならない。

HLCOMPの仕様は、引数2つをとり、＞なら1、＝なら0、＜なら-1を返すというもの。
確かに、#NUM!エラーを返すパスもあるんだけど・・・
同様に、#NUM!を返す可能性のあるSQRT関数を条件に使う場合、そんな問題発生しないんだよなぁ。

で、Excel2003だと、再現しない。
＃95～2003のどのバージョンまで再現するかは未確認(やらなきゃまずいかなぁ)。
原因はExcel95にあると思うのだけど・・・

ExcelでSQRTに負数を与えると、#NUM!エラーとなるわけだが、多桁の現実装は絶対値に対して平方根を計算している。

互換関数もよさげにできたっぽい評価結果が得られてるんだけど、そろそろ公開をと考えているのだが、さて。

今回比較関数を用意したので、負数を事前に排除することもできるわけだし、#NUM!エラーを返すようにするかな。

追加で絶対値を返す関数を用意する意味も出てくるし。

結果は「できませんでした」。

比較的電圧降下の少ない赤色LEDを使用して、抵抗も入れずにやってみたんだけど、結果点灯せず。

LEDは双方向導通するよう並列化したけど、どうも、電流も電圧も足りないらしく、通信すら行われない。
ジャンパで直結すると、導通して半二重通信が可能となる。
LED自体は通電するとちゃんと点灯するので切れてはいない。

光る小さなRJ-45ループバックコネクタって出来たらなぁと思ったのだけど、何らかの外部電源を持ってこないと難しいようだ。
＃これをやるとNIC自体の破壊につながる可能性があるので、断念。

http://www.iodata.jp/support/qanda/answer/s16484.htm
について、本当にGV-SC200だけの問題なのか、質問してみたところ、

「GV-SC300シリーズ、GV-SC400につきましては、ハンドルリークについて、全く発生しないということではございませんが、数が少ない状態となります。」という、正式回答を得ることができた。
結局、SEG CLIP全シリーズ、多かれ少なかれ、ハンドルリークするってことらしい。
この分だと、他のGV-*シリーズでも同じようなことが起こってるかもね。

あと、「GV-SC200の場合は、どのような状態でございましても、ハンドルリークが発生する状況でございました。」だそうな。
本当に信じられねぇな。

ここまで3ヶ月。
現象を明確に公開できもせず3ヶ月。
現象の改善も無く3ヶ月。

メモ。

カウンタログを眺めていて、何となくおかしな感じがしていた。