多桁数比較関数として、HLCOMPを用意してみたものの、Excel95のIF関数内で条件に使うと、なぜか#NUM!エラーになる。
HLCOMPを別セルで計算して、その値を条件に使えば問題ないし、IF関数の真偽値としてエラーを返す可能性の無いリテラルを指定すれば、これもエラーにならない。
HLCOMPの仕様は、引数2つをとり、＞なら1、＝なら0、＜なら-1を返すというもの。
確かに、#NUM!エラーを返すパスもあるんだけど・・・
同様に、#NUM!を返す可能性のあるSQRT関数を条件に使う場合、そんな問題発生しないんだよなぁ。
で、Excel2003だと、再現しない。
＃95～2003のどのバージョンまで再現するかは未確認(やらなきゃまずいかなぁ)。
原因はExcel95にあると思うのだけど・・・
ExcelでSQRTに負数を与えると、#NUM!エラーとなるわけだが、多桁の現実装は絶対値に対して平方根を計算している。
互換関数もよさげにできたっぽい評価結果が得られてるんだけど、そろそろ公開をと考えているのだが、さて。
今回比較関数を用意したので、負数を事前に排除することもできるわけだし、#NUM!エラーを返すようにするかな。
追加で絶対値を返す関数を用意する意味も出てくるし。
コメントを暗号化して送りたいときに使うと良いと思う程度だけど、一応、SSL(HTTPS)に切り替えるためのリンクを上部に作成。
これもIISでモジュールフィルタ使って書き換えている。
サイト内リンクをhttpsに書き換える処理も入れてある。
＃トラックバックURLも書き換えちゃってるけど・・・
オレオレ証明書(ワイルドカード)なので、証明書エラーとか出まくるけど、暗号化は可能。
エラーを無くすには、ルート証明書をインストールすればいいんだけどね。
＃ルート証明書、公開してもいいと思うんだけど、躊躇中。
それこそ、気になったらコメント下さい。
＃サポートサイトでもSSL効くんだけど、オレオレだからリンク自粛。
証明書の有効期限もあるので、そのうちオレオレ認証局設置からオレオレワイルドカードSSL証明書取得やIISへのインストールまでの自己流手順書を作成しようかと思っている(予定)。
このサイトのカウンタは、IIS用マネージモジュールを使用している。
IHttpModuleを実装し、text/htmlで200レスポンスの場合だけカウンタログに入れて、クローラーかどうかを判断しつつ、カウンタログを書きだしているのは既出のとおり。
でも、どう考えてもクローラーっぽいアクセスログがあるんだけど、排除する判断が難しい。
判断が難しいのは、情報不足の気がしている。
そこで、リクエストメソッドとその他ヘッダも一緒に書きだせるように、データベーステーブルを拡張。
併せてモジュールも変更。
表示も少し変えて、過去24時間内のアクセスも併記できるようにした。
しばらくまた様子を見ることにする。
Excelで多桁計算。
現在公開されているのは、四則演算まで。
開根実装の目途はついた(と思っている)。
遅いけど。
遅さをカバーする意味も含めて、全Excelで同じ桁数を返す互換関数を用意しようかと思っている。
255文字分で表現可能な値を返すってやつ。
返却を短くできる分、処理が軽くなるので、開根の遅さをある程度カバーできる。
入力(引数)文字数はExcelバージョン依存で出力(解)文字数は互換となる予定。
乗算の打ち切り方について、まだよくわかってないので、入力依存。
除算・開根の打ち切りはできる。
加算・減算の打ち切りはしない。
で、提供予定としておく。
ついでに、比較演算関数も加えたいなぁと考えている。
そして、あともう2つほど関数を考えているのだけど・・・
高速化ってのは、処理を軽量化する方向でやるのと、そうでない場合があると俺は思う。
前者はたとえば、条件分岐を減らしたり、計算回数を減らしたり、より簡易なコードにすることが多いと思う。
＃Simple is Bestってやつ。
今回(今日)の大幅な高速化は後者。
1位にいくつか数を加えた場合の桁上がりを処理するのは、1位値が10を超える場合のみでいいという、いわゆる打ち切り条件を加えた。
＃条件によっては効果が無いけれど、今回はやる前から処理分岐率50%で、その分の処理を打ち切れるという、かなの効果を見込んでいた。
桁上がり処理は、全桁を確実にループするため、条件によってやらなくていいというのは、メリットだろうと思ったわけだ。
おまけに、その処理は何度も通るため、結果、条件判断に掛るコストよりも大幅な処理速度改善につながったわけだ。
にしても、びっくりするのは、これで限界と思ってた60秒から30秒台まで高速化できたことよりも、処理のほぼ半分も無駄なことやってたこと。
さすがに俺もこれには笑うしかない。
＃その後、もう少し手を入れて、30秒切るところまできました。
環境は、Core2Duo L7500(1.6GHz)のまま。
開根時に多用してる減算をどうにかしたら速くなるんじゃないかということで、加算減算を見直し。
今までは、加算では各桁加算ループと桁上がり処理ループに分けていたんだけど、ループを1回で済ませられるように変更。
減算も、桁下ろしループ、各桁減算ループ、桁上がりループの3ループを1ループ化。
これだけで、60秒を切りそうな勢いで高速化できた。
他にもいろいろと手を入れているものの、減算の変更は一番効いたと思う。
もう少し見直して、余裕で1分切りを目指したいと思う。
＃でも、実用とは言い難いので、別の策を考え中。
プロセス情報を操作する時例外出る場合があるようなので抑制。
ダウンロード
＃そうそう、しきい値10000ってのは結構妥当っぽい(http://technet.microsoft.com/ja-jp/windows/ee787049.aspx)のでそのまま。
＃＃曰く、「特定の時点で 1 万個を超えるハンドルを開いているプロセスは設計がよくないか、ハンドル リークが発生しているかのいずれかである～」だそうな。
当然、まだ回答は無い。
「いましばらく」という言葉は使用者や受け手、場面により、その示すであろう期間が異なる曖昧な言葉であるため、回答で使用すべきじゃないよな。
「○日までに再度ご連絡致します」って書けば、その日までは待とうと思うじゃん。
だめだよ、あの会社。
開根筆算では2桁ずつ下ろしてくる処理がある。
これを省略してみたところ、少し速くなって2や3の開根で80秒を切れるようになった。
これが限界だと思っても、諦めなければ、その先がある。
でも、多分、今のままで1分切るのは難しい。
※A3には =HLMLT(A2,A2) で検算。
多桁開根確認中、数バイトのnewでヒープ破壊の例外発生。
何が原因かは目下不明。
Free Heap block xxxxxxxx modified at yyyyyyyy after it was freed
と言われるので、yyyyyyyyアドレスを見ると、確かに周りと違う値。
参照変数は、別スコープに移動したし・・・飛び地を不用意に書き換える処理は入っていないはず。
OS再起動して再現するようなら調査続行か。
