2010年3月アーカイブ

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

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ヶ月。

メモ。

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

前回、ブレッドボード用USB電源を作ったのだけど、いくら小さいとはいえ、ブレッドボードは嵩張る。

そこで、もっと小さなモジュールを作ってみた。

一応、Q&Aには載ったんだけどさ。

なんてこった。
今回、自信を持って答えを選択したのに、前回より大幅ダウン。

俺の知識、大間違いってことか。
新たに本を購入して、もう一度挑戦する。