[PR] Excelで多桁計算するなら「Addin for Excel 95-2007 Basic Edition」!
[PR] 自由な名前で定数を共有?!「Addin for Excel 95-2007 Professional Edition」
[AA] 安かったから、買ったよ→BUFFALO ポータブルブルーレイドライブ BR-PX68U2-BK
[予告]次回メンテナンス(運用停止)は 12月7日 10:00~16:00 のうち2時間程度を予定しています。

Hobby::Excelの最近のブログ記事

前の10件 1  2  3  4  5  6  7  8  9

HyperLong系の加減乗除、開根、大小比較まで出来るようになっている0.7.1もまだ公開されてませんが、次回(0.7.2)の予告。

絶対値取得関数。
開根関数には必須。
実は、文字列として、たとえ負の数だろうが、- を先頭に付けるだけで、符号反転できたりする仕様なので、条件判定して、- を文字列連結しちゃえばいいんだけど、それだと32767文字超えちゃう可能性があるので、関数として用意しておいたほうがいい。

円周率定数関数。
定数なので、計算処理無しで返したいところ。
これまで、「そんなに長く円周率算出して実際使うのは10ケタも無いじゃん」って言われ続けてきた円周率をこれでもかというくらいに長く利用できるようになったので、なが~く出せるように。
ついでにSQRTPI関数っぽいものも。

あとは提供方法考え中なのが、返却の文字列長指定。
あると、結構便利な予感。

他には、SUM系の関数をと考えてるんだけど、今のところ未定。

ま、こんなところかな。
徐々に追加すれば良い。

多桁開根登録しますた

| コメント(0) | トラックバック(0)

Excelの多桁開根関数を追加したやつ、登録しました。

Addin for Excel 95-2007 Basic Edition

多分、来週には公開されるんじゃないかな。

サポートはこちら

今回のバージョンは、0.7.1になりまする。

是非、ご利用くださいな。

Excel95の挙動に対応

| コメント(0) | トラックバック(0)

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

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

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

Excel95の挙動に戸惑う

| コメント(0) | トラックバック(0)

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

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

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

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

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

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

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

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

次の版では互換関数を

| コメント(0) | トラックバック(0)

Excelで多桁計算
現在公開されているのは、四則演算まで。

開根実装の目途はついた(と思っている)。
遅いけど。

遅さをカバーする意味も含めて、全Excelで同じ桁数を返す互換関数を用意しようかと思っている。
255文字分で表現可能な値を返すってやつ。

返却を短くできる分、処理が軽くなるので、開根の遅さをある程度カバーできる。

入力(引数)文字数はExcelバージョン依存で出力(解)文字数は互換となる予定。

乗算の打ち切り方について、まだよくわかってないので、入力依存。
除算・開根の打ち切りはできる。
加算・減算の打ち切りはしない。

で、提供予定としておく。

ついでに、比較演算関数も加えたいなぁと考えている。

そして、あともう2つほど関数を考えているのだけど・・・

多桁開根、30秒台突入

| コメント(0) | トラックバック(0)

高速化ってのは、処理を軽量化する方向でやるのと、そうでない場合があると俺は思う。

前者はたとえば、条件分岐を減らしたり、計算回数を減らしたり、より簡易なコードにすることが多いと思う。
#Simple is Bestってやつ。

今回(今日)の大幅な高速化は後者。

1位にいくつか数を加えた場合の桁上がりを処理するのは、1位値が10を超える場合のみでいいという、いわゆる打ち切り条件を加えた。
#条件によっては効果が無いけれど、今回はやる前から処理分岐率50%で、その分の処理を打ち切れるという、かなの効果を見込んでいた。

桁上がり処理は、全桁を確実にループするため、条件によってやらなくていいというのは、メリットだろうと思ったわけだ。

おまけに、その処理は何度も通るため、結果、条件判断に掛るコストよりも大幅な処理速度改善につながったわけだ。

にしても、びっくりするのは、これで限界と思ってた60秒から30秒台まで高速化できたことよりも、処理のほぼ半分も無駄なことやってたこと。

さすがに俺もこれには笑うしかない。

#その後、もう少し手を入れて、30秒切るところまできました。

環境は、Core2Duo L7500(1.6GHz)のまま。

開根時に多用してる減算をどうにかしたら速くなるんじゃないかということで、加算減算を見直し。

今までは、加算では各桁加算ループと桁上がり処理ループに分けていたんだけど、ループを1回で済ませられるように変更。

減算も、桁下ろしループ、各桁減算ループ、桁上がりループの3ループを1ループ化。

これだけで、60秒を切りそうな勢いで高速化できた。
他にもいろいろと手を入れているものの、減算の変更は一番効いたと思う。

もう少し見直して、余裕で1分切りを目指したいと思う。

#でも、実用とは言い難いので、別の策を考え中。

多桁開根もう少し加速

| コメント(0) | トラックバック(0)

開根筆算では2桁ずつ下ろしてくる処理がある。
これを省略してみたところ、少し速くなって2や3の開根で80秒を切れるようになった。

これが限界だと思っても、諦めなければ、その先がある。
でも、多分、今のままで1分切るのは難しい。

hlsqrt.png
※A3には =HLMLT(A2,A2) で検算。

ヒープ破壊?

| コメント(0) | トラックバック(0)

多桁開根確認中、数バイトのnewでヒープ破壊の例外発生。

何が原因かは目下不明。

Free Heap block xxxxxxxx modified at yyyyyyyy after it was freed
と言われるので、yyyyyyyyアドレスを見ると、確かに周りと違う値。

参照変数は、別スコープに移動したし・・・飛び地を不用意に書き換える処理は入っていないはず。

OS再起動して再現するようなら調査続行か。

前の10件 1  2  3  4  5  6  7  8  9

サイトカウンタ

Total: 211,632 Hits, (Recent24Hours: 0 Hits)
~ Since 2010/01 ~

埋め込みツイッター

取得失敗;;
Now: 2024/11/21 19:26:41 JST

このアーカイブについて

このページには、過去に書かれたブログ記事のうちHobby::Excelカテゴリに属しているものが含まれています。

前のカテゴリはHobby::C++です。

次のカテゴリはHobby::MSDNです。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。

月別 アーカイブ

2024年5月

 日   月   火   水   木   金   土 
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  

埋め込みQRコード