2014年5月26日月曜日

HP Primeで円周率を計算してみたよ

遅うなりました。HP Primeで円周率を計算してみました。

Many Digits of Pi by Katie Wasserman - MoHPC
www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/articles.cgi?read=899

のプログラムをHP Prime向けに焼き直してみました。このプログラムでは小数点以下1000桁程度までの円周率を計算します。

------
EXPORT ARRYS := 126;
EXPORT DIGIT := 100000000;

//  C5(B) -> C4(A)
mv_A_B()
BEGIN
  LOCAL i;

  FOR i FROM 1 TO ARRYS DO
    C4(i) := C5(i);
  END;
END;

//  div C4(A)/f -> C5(B)
div_A_f(f)
BEGIN
  LOCAL i;
  LOCAL cy := 0;

  FOR i FROM 1 TO ARRYS DO
    C5(i) := floor((cy*DIGIT+C4(i)) / f);
    cy := (cy*DIGIT+C4(i)) - C5(i)*f;
  END;
END;

//  mul C4(A)/f -> C5(B)
mul_A_f(f)
BEGIN
  LOCAL i, w;
  LOCAL cy := 0;


  FOR i FROM ARRYS DOWNTO 1 DO
    w := C4(i)*f+cy;
    C5(i) := w-floor(w/DIGIT)*DIGIT;
    cy := floor(w/DIGIT);
  END;
END;


EXPORT PI_CALC()
BEGIN
  LOCAL n, f, w;


  //  array initialize
  C4:=MAKELIST(0.0,X,1,ARRYS,1);
  C5:=MAKELIST(0.0,X,1,ARRYS,1);

  //  loop countre 
  n := log(10)/log(2)*1000;

  FOR f FROM floor(n) DOWNTO 1 DO

    //  A * f -> B
    mul_A_f(f);
    //  B -> A
    mv_A_B();

    //  A / f -> B
    div_A_f(f*2+1);
    //  B -> A
    mv_A_B();

    //  A + 2 -> A
    C4(1) := C4(1)+2;

  END;


END;


--------


実行前に、CAS setting の「Exact」フラグを外しておくのが吉です (Exactフラグが付いていると、時間が掛かってしまいます)。


PCのシミュレータでも20秒くらいは掛かります。
変更 on 2015/03/18
最新のエミュレータで実行した所、何と6分半も掛かってしまいました。また、実行後、画面表示が「凍てつく」状態になり、一旦エミュレータを終了してからでないと、2変数統計表示が出て来ません。

計算結果は2変数統計機能のC4配列変数に収蔵されます。C4(1)には3, 以下、小数点以下を8桁ごとに分割して配列変数に収容しています。


変数DIGIT は、配列要素1つに割り当てる桁数を規定するもので、この数値の場合、配列要素1つにつき、8桁の計算を行います。残念ながら、これ以上にすると計算精度が損なわれる様です。
仕方がないので、1000桁の計算のため、125個 (=1000桁/8桁) の配列要素を用意しています。


AmazonのJulyさん、「日本語クィックガイドなし(正規輸入)」というカテゴリになりました。未だ、「日本語クィックガイドあり」にはモノがありませんが、準備中との事なので、首を長くして待っております。


追記 on 2014/05/27
よくコードを検討したら、若干の変更で、配列変数のコピー部分は不要でしたネ。後で修正版をupしようかしらん ?

245 件のコメント:

«最後   ‹次   201 – 245 / 245
akatuki さんのコメント...

Sentaro 様、こんばんは!

> 200コメント目のキリ番、おめでとうございます!

いえいえ、Sentaro様、やす様、藤堂様のコメントがあってこそです !
それを横取りする様にしまって、申し訳ない ... 。

> んと、変数の扱い方がわかれば後はUserRPLからSysRPLへは1対1で移植できるかと思ったらUNPICKとかSysRPLにはないコマンドがあることがわかってちょっと手間取りました。
> あとループ構造も初期値はBINT形式とか同じようにはいかないので、SysRPL形式に変換するところがちょっとややこしかったですね。

やはり、そんな感じですよネ。SysRPLの「辞書」を索いて置き換える、という感じでもあり、更にSysRPLの書き方も意識しないとならないので、手間が掛かる。
そこがパズルみたいで面白いのですが、変換のオーバーヘッドとなってしまう ... 。

> やはり整数型にするのが一番高速化に寄与しそうですよね。
> と思って、整数処理化しようと思うとBINTは5バイト、ZINTは任意精度ということで、なかなか一筋縄では上手くいきません(^^;もう少し経験値をつむ必要ありみたいです。

ZINTって自由長だったのですね。ウーン。
BINTならイケそうかな ? 2^(5*8-1) = 549755813888 なら、10桁くらいの表現が出来そうですが ... ?

> SysRPLやSaturnアセンブラもかなり昔から存在していると思われるのですけど、UserRPLからのコンパイラ系の自動変換ツールとか見当たらない?ってことは…結構内部構造がややこしいことになっているんでしょうか。

どうも、その様な。
一方、SysRPLの様な「パワーツール」は手練が少なく、なかなか普及しなかったため、自動変換ツールの様なものも作られなかった、のかなぁ ?

> いや、それとも、逆にコマンドに慣れていけば機械的コンパイラよりも最適化された形でSysRPLもアセンブラもサクサク書けてしまうってことでしょうかね(^^;

その境地に達したとなると「人間アセンブラ」ですネ ... 。

> HP電卓や機械語だとスタックは当たり前の概念ですけど、今の自然表示な関数電卓はもはやスタックを全然意識する必要がないので、便利にはなった反面、スタックという言葉自体廃れていく感じもしますね。

仰る通りであります。
今日、C/C++なんかでもスタックよりもheapの方が気になるという御時世らしく。電卓のファーム開発でも、そういう感じなのかしらん ?

> 昔、Z80のコンパイラを作っていじってたことがあったんですけど、その時の数式評価はまさにRPNそのものだったので、なんか、RPLプログラミングっていうのはマシン語への変換&最適化を手作業でするハンドコンパイル感覚を思い出します。

ギャーッ、コンパイラを作っておれらましたか ! これは恐れ入ります !
なんていうんですか、「形式論理」とか、結構難しい話がありますよね ... 。当方、未だによう判らんです。

> 当時にHP電卓使いだったら機械語のプログラミングは数段楽だったのかも?とちょっと思うところです(^^;

当方は見たことしかないのですが、HP16Cがbit計算専用で作られ、プログラマに結構使われたという話を思い出しました。

Sentaro さんのコメント...

akatuki様、こんばんは!

円周率ネタは私的にツボだったことはもちろんですけど、akatuki様のPrime移植から始まって、やす様のfx-5800Pへの移植&改良&Spigotアルゴリズムの導入、そして藤堂様のプチコン3号とバラエティ豊かに展開してきたのが大きいですね(^^)


>そこがパズルみたいで面白いのですが、

これはもう本当に同感です!
難解なパズルが解けたときの面白さゆえプログラミングは止められません!(^^;


>BINTならイケそうかな ? 2^(5*8-1) = 549755813888 なら、10桁くらいの表現が出来そうですが ... ?

あ゛…5バイトじゃなくて5ニブルでした(^^;
BINTだけでいけるとかなり高速化できそうですけどだと有効5桁くらいだとちょっと厳しい感じでしょうか。


>ギャーッ、コンパイラを作っておれらましたか ! これは恐れ入ります !
>なんていうんですか、「形式論理」とか、結構難しい話がありますよね ... 。当方、未だによう判らんです。

コンパイラといってもZ80の整数型BASICコンパイラなので「形式論理」とかまで全然いかないレベルの話で初歩の初歩クラスのコンパイラです(^^;


>HP16Cがbit計算専用で

こういう専用電卓があるというのがHPの凄さですよね。

akatuki さんのコメント...

Sentaro 様、こんばんは !

> これはもう本当に同感です!
> 難解なパズルが解けたときの面白さゆえプログラミングは止められません!(^^;

仰る通りです !

> あ゛…5バイトじゃなくて5ニブルでした(^^;
> BINTだけでいけるとかなり高速化できそうですけどだと有効5桁くらいだとちょっと厳しい感じでしょうか。

いや、そうでしたネ。Saturn、ニブルマシンでしたっけ ... 。
仰る通り、1要素5桁ではかなり苦しいです。ウーン

> コンパイラといってもZ80の整数型BASICコンパイラなので「形式論理」とかまで全然いかないレベルの話で初歩の初歩クラスのコンパイラです(^^;

いや、それでも凄いですよ ! 当方なぞ、思いもしません。

Sentaro さんのコメント...

akatuki様、こんばんは!

BINTでなんとか移植してみましたが、精度が6桁しかないのでBASEが2桁とかでないと上手く計算できないので結果的に遅くなってしまいました(^^;
ということで逆に倍精度版(15桁)にちょっと変更してみると、
通常精度が12桁で倍精度が15桁なので遅くなるかも?って思ってたら逆に速くなりました。
BASEを10桁に出来るのでこれが今のところ最速です。
ひょっとしたら内部は倍精度が基本なのかもしれません。
あと考えられる高速化はZINTですが、これがまだよくわかってません(^^;
CASの計算のために用意されているっぽいので、足算、引算、掛算だけなら無限精度といえるものですけど、割算が分数扱いで…。


SysRPL版その3 BINT版(6桁精度)
PI_CALC1_SysRPL3BINT.txt
100桁(BASE2桁) 1分12秒


SysRPL版その3 倍精度版
PI_CALC1_SysRPL3dbl.txt
100桁(BASE8桁) 0分46秒
100桁(BASE10桁) 0分37秒

PI_CALC2_SysRPL3dbl.txt
100桁(BASE6桁) 1分02秒
100桁(BASE7桁) 0分52秒



200コメント超えてページが新しくなったのでHP-50Gの今までの結果をまとめておきます。
PI_CALC1は通常アルゴリズム効率版で移植のベースはこれです。3DS_PI_CALC1.txt
Spigotアルゴリズム版のPI_CALC2はこれです。3DS_PI_CALC2.txt

UserRPL版その1(ベタ移植版)
PI_CALC1_UserRPL.txt 100桁(BASE8桁) 3分49秒
PI_CALC2_UserRPL.txt 100桁(BASE6桁) 5分43秒

UserRPL版その2 (配列スタック化)
PI_CALC1_UserRPL2.txt 100桁(BASE8桁) 2分 5秒
PI_CALC2_UserRPL2.txt 100桁(BASE6桁) 1分43秒

UserRPL版その3 (配列スタック化&ループ内最適化)
PI_CALC1_UserRPL3.txt 100桁(BASE8桁) 1分32秒
PI_CALC2_UserRPL3.txt 100桁(BASE6桁) 1分17秒


SysRPL版その3 (配列スタック化&ループ内最適化)
PI_CALC1_SysRPL3.txt 100桁(BASE8桁) 0分51秒
PI_CALC2_SysRPL3.txt 100桁(BASE6桁) 1分03秒

akatuki さんのコメント...

Sentaro 様、こんばんは ! お勤め、お疲れ様です !

> BINTでなんとか移植してみましたが、精度が6桁しかないのでBASEが2桁とかでないと上手く計算できないので結果的に遅くなってしまいました(^^;

ウーン、そうですよね ... 。遅くなってしまいましたか。

> ということで逆に倍精度版(15桁)にちょっと変更してみると、
> 通常精度が12桁で倍精度が15桁なので遅くなるかも?って思ってたら逆に速くなりました。
> BASEを10桁に出来るのでこれが今のところ最速です。
> ひょっとしたら内部は倍精度が基本なのかもしれません。

あっ、これはまた、意外ですね !
そういや、16ニブルで一括BCD計算とかやっていたのかしらん、Saturnって。それで倍精度計算が効率的になったのかな ?
勉強になります !

> あと考えられる高速化はZINTですが、これがまだよくわかってません(^^;
> CASの計算のために用意されているっぽいので、足算、引算、掛算だけなら無限精度といえるものですけど、割算が分数扱いで…。

ZINTって、そうだったのですか ! 道理で、別のデータ型だった、と ... 。
まだまだ不勉強なもので。色々と勉強させてもらい、申し訳ない。

> 200コメント超えてページが新しくなったのでHP-50Gの今までの結果をまとめておきます。
> PI_CALC1は通常アルゴリズム効率版で移植のベースはこれです。3DS_PI_CALC1.txt
> Spigotアルゴリズム版のPI_CALC2はこれです。3DS_PI_CALC2.txt

ウーン、マイッタ。
ここまでされますと、当方としても何かやらんとアカンのですが、いま、ちょっと忙しいので ... と「逃げ」を打っておきます。

ここまでSysRPLで来ると、つぎは「HPGCC」って事になりましょうか。一応Cですから、SysRPLよりは書きやすいと思います。問題となるのは計算結果の出力です。
ちなみに、乱数についてはRAND_MAXが違う (unsigned intで上限になっていますネ)など、細かい所で違いがあったりしますので、これはこれで頭の体操になる所も多いかと ... 。

藤堂俊介 さんのコメント...

 事務の仕事で大量に伝票を集計する仕事がなかったためか、カシオの加算式電卓もしくは検算電卓を使っていました。EXキーは集計業務には使わないとみてか、日本の大手メーカーは一般機種への採用を見送ったのでしょうか、使い方によっては便利かと思われます。

 スタックはカシオの関数電卓説明書に書かれていましたね。説明書は無くしがちなので、すべての機種の説明書を電子化しておくのも重要かもしれませんね。

Sentaro さんのコメント...

akatuki様、こんばんは!

>ZINTって、そうだったのですか ! 道理で、別のデータ型だった、と ... 。

割り算さえ精度落とさないで出来てくれればと思ったのはCASのNspireでもでしたけど、CASは整数ならば精度は完璧なのにapproxで浮動小数点化すると通常精度に落ちてしまうのが惜しいところです。
100桁÷5桁とかの計算で少数切捨で95桁整数で結果が出ると円周率計算みたいなのはすごく楽に簡単になりますね。

>ここまでSysRPLで来ると、つぎは「HPGCC」って事になりましょうか。

はい、さすがに次はSaturnアセンブラでというのはちょっとでなく敷居高そうなので、次はそういう流れかと思いますです(^^;

なのですが、SysRPLのSpigot版で遅いのがちと気になるのでそこもなんとか改善したいところではあります。

C版はfx-9860GII版で土台はあるので、50G用の入出力だけなんとかすればとりあえず動くものは出来そうです。
HPGCCはprintf()が普通に使えたりスタックとのやりとりも関数一発で出来そうなのでHPGCCの定石さえわかってしまえば移植はSysRPLよりは楽かもです。
ただ、akatuki様がおっしゃるように乱数の違いとか仕様の細かな違いをしっかり頭に入れておかないと変なところではまってしまうと面倒なので、じっくり取り組みたいと思います。どうもありがとうございます(^^)



藤堂様、こんにちは!

>スタックはカシオの関数電卓説明書に書かれていましたね。

SHARPの説明書からはすでにスタックの記述が無くなってるようですし、CASIOはまだまだスタックが現役なのでポイント高いです。

>説明書は無くしがちなので、すべての機種の説明書を電子化しておくのも重要かもしれませんね。

一昔前の機種となるとネットで入手できるのは海外版ばかりなので自前で電子化しておくことは確実に重要ですね(^^)

akatuki さんのコメント...

藤堂 様、今晩は !

> 事務の仕事で大量に伝票を集計する仕事がなかったためか、カシオの加算式電卓もしくは検算電卓を使っていました。EXキーは集計業務には使わないとみてか、日本の大手メーカーは一般機種への採用を見送ったのでしょうか、使い方によっては便利かと思われます。

ユーザーアンケートなどによって「機能の絞り込みが進んだ」という事なのかも知れません。
事務用電卓では、高機能化よりも高速動作を求める傾向があるらしく、機能が減ってしまうのは残念な所ではありますが、そういう「削ぎ落とした」機能などを高機能電卓に盛り込んでくれると、面白い事に ?

> スタックはカシオの関数電卓説明書に書かれていましたね。説明書は無くしがちなので、すべての機種の説明書を電子化しておくのも重要かもしれませんね。

仰る通りです。
最近のCASIO,Sharp製品はサイトからPDFを取り寄せる事が出来るのですが、昔のモノはなかなかありませんね。昔のモノ、例えばポケコンやプロ電のPDFなんか、結構需要がありそうなものです。
最近、Sharpは昔の電卓のカタログを電子書籍にして「無料」で読める(パゴスの垢が要るとか、バーロー !)とかやっておりますが、CASIOもコレに負けず、PB-100に付けていたプログラム教本とかPDFで公開したりしたら、結構面白い ? あるいは「関数電卓の教本」の様な冊子を販売店頭に置いていた時期があったのですが、これなんかPDFで公開してもイイものだと思うのです。

どうでしょうか、CASIO担当氏様。

akatuki さんのコメント...

Sentaro 様、今晩は !

> 割り算さえ精度落とさないで出来てくれればと思ったのはCASのNspireでもでしたけど、CASは整数ならば精度は完璧なのにapproxで浮動小数点化すると通常精度に落ちてしまうのが惜しいところです。
> 100桁÷5桁とかの計算で少数切捨で95桁整数で結果が出ると円周率計算みたいなのはすごく楽に簡単になりますね。

ウーン ? 自由精度整数の操作がNspireのCASと同等の作り、という事ですか !
この辺り、任意精度整数計算をうまく利用すると、結構面白そうですネ、ハイ ! 何かやってみたくなりましたが、さて何が出来るのか ... ?

> はい、さすがに次はSaturnアセンブラでというのはちょっとでなく敷居高そうなので、次はそういう流れかと思いますです(^^;

Saturnアセンブラは面倒そうです。それに、ARMでエミュレートしているらしく、今日的にはARMアセンブラの方がより良い様にも思えます。

> なのですが、SysRPLのSpigot版で遅いのがちと気になるのでそこもなんとか改善したいところではあります。

SysRPLの改変は、興味深い所です。無理をしない範囲で進めて戴き度。

> C版はfx-9860GII版で土台はあるので、50G用の入出力だけなんとかすればとりあえず動くものは出来そうです。
> HPGCCはprintf()が普通に使えたりスタックとのやりとりも関数一発で出来そうなのでHPGCCの定石さえわかってしまえば移植はSysRPLよりは楽かもです。

ですネ !

> ただ、akatuki様がおっしゃるように乱数の違いとか仕様の細かな違いをしっかり頭に入れておかないと変なところではまってしまうと面倒なので、じっくり取り組みたいと思います。どうもありがとうございます(^^)

いえいえ。少しかじったくらいで知識をひけらかして居る若輩モノです。
それでも、プログラムがバリバリバリっと動いてしまうので、結構面白いのですよ、HPGCC。

Sentaro さんのコメント...

akatuki様、こんばんは!

>最近、Sharpは昔の電卓のカタログを電子書籍にして「無料」で読める(パゴスの垢が要るとか、バーロー !)とかやっておりますが、

X1とかX68Kのサービスマニュアルとか無償公開されているらしいっていうので登録してたんですけど、結構古い1978年から1982年あたりの電卓のカタログもありました!
まだ蛍光管の電卓から液晶電卓への移行の時期のカタログなので貴重です(^^)
ただ、ガラパゴスのアプリ上でしか見れないのでこういう貴重な財産はぜひとも普通のPDFにして公開して欲しいところですね。


>ウーン ? 自由精度整数の操作がNspireのCASと同等の作り、という事ですか !

んと、まだ実際に何かやってみたわけじゃないので確実なことは分かってないのですけど、UserRPLでもCASのApproxチェックはずしておけば整数は無限桁演算になるので、それがZINTなのかなと…。


>それでも、プログラムがバリバリバリっと動いてしまうので、結構面白いのですよ、HPGCC。

入出力最小限で要部分だけ移植してみたら、バリバリっと動いてしまいました(^^;

藤堂様のプチコン3号で1000桁で約4秒、10000桁で約4分21秒だった最適化バージョンの32ビット整数版で、
1000桁(BASE5桁) 2秒
10000桁(BASE4桁) 3分5秒
程度ってことで、まずまずの結果です(^^)

akatuki さんのコメント...

Sentaro 様、遅うなりまして。

> X1とかX68Kのサービスマニュアルとか無償公開されているらしいっていうので登録してたんですけど、結構古い1978年から1982年あたりの電卓のカタログもありました!
> まだ蛍光管の電卓から液晶電卓への移行の時期のカタログなので貴重です(^^)

当方、電卓のカタログについては昔持っていたのですが、流石にもう、手元にはありません。
こういう取り組みは歓迎したいのですが、コンテンツビジネスっていうのがどうにも割り切れない ... 。

> ただ、ガラパゴスのアプリ上でしか見れないのでこういう貴重な財産はぜひとも普通のPDFにして公開して欲しいところですね。

仰る通りです !
しかし、資源をそこに割けるのかが問われているのでしょうね、今のSHARPは ... 。

> んと、まだ実際に何かやってみたわけじゃないので確実なことは分かってないのですけど、UserRPLでもCASのApproxチェックはずしておけば整数は無限桁演算になるので、それがZINTなのかなと…。

そうでしたか。それでも、十分面白そうです !
ただ、面白そうなネタを思いつかず ... 。長期戦です、ハイ。

> 入出力最小限で要部分だけ移植してみたら、バリバリっと動いてしまいました(^^;

ですヨ。

> 藤堂様のプチコン3号で1000桁で約4秒、10000桁で約4分21秒だった最適化バージョンの32ビット整数版で、
> 1000桁(BASE5桁) 2秒
> 10000桁(BASE4桁) 3分5秒
> 程度ってことで、まずまずの結果です(^^)

プチコンはBASICインタプリタで、50Gの方はCコンパイラ。
ウーン、やはり3DSのパワーは ... 。
しかし、まだまだ50Gでやっていきますヨ !

藤堂俊介 さんのコメント...

 スープを選ぶ、パンを選ぶなど、投稿前のクイズがでるので、投稿がうまくいかなった・・・。(;´д`)

 きょうはケーキを選ぶの難問が出た。

藤堂俊介 さんのコメント...

(余談)
 コンピュータ用語はほとんどが英語のカタカナ。Wikipeadiaの他言語版を調べたら、
(中国語)堆桟
(台 湾)堆畳
※日本語の漢字にしてあります。

 堆・・・ためる
 桟・・・
1 戸・障子などの骨組み。
2 板が反るのを防ぐために、打ちつけたり差し込んだりする横木。
3 土台や梯子(はしご)などに渡す横木。
 スタックの概念を示す図を表しているような。
 畳も、スタックの概念図を連想しそうですね。
 漢字で書いて、スタックとルビを売って使いたい気分。
 

Sentaro さんのコメント...

akatuki様、こんばんは!

入出力はHPGCC2のサイトに載っている円周率計算プログラムの仕様をそのまま取り入れたのでRPLに比べるとかなり楽な移植に(^^;
とりあえず、整数版、実数版ひとまず完了です。
picalc_HPGCC2.zip
-----------------------------------------------
計算時間
-----------------------------------------------
picalc
100桁(Base5桁)  0.039s
1000桁(Base5桁)  2.749s
10000桁(Base4桁) 337.490s

picalc1
100桁(Base5桁)  0.020s
1000桁(Base5桁)  1.735s
10000桁(Base4桁) 184.984s

picalc2
100桁(Base4桁)  0.011s
1000桁(Base4桁)  0.927s
10000桁(Base4桁) 102.777s
-----------------------------------------------
picalcf
100桁(Base10桁)  0.114s
1000桁(Base10桁)  10.025s
10000桁(Base10桁) 996.980s

picalc1f
100桁(Base10桁)  0.066s
1000桁(Base10桁)  5.519s
10000桁(Base10桁) 542.799s

picalc2f
100桁(Base7桁)  0.050s
1000桁(Base7桁)  4.565s
10000桁(Base7桁) 462.115s
-----------------------------------------------
整数版ならプチコン3号より速いですけど、実数版はFPUがないので遅めですね。
でも、さすがにHPGCCなのでPrimeよりは一桁以上速くなりました(^^)
PrimeもHPGCCが使えるようになってくれないと魅力半減ですね…。

>当方、電卓のカタログについては昔持っていたのですが、

うちにもいくつかあったんですけど、ある時期に全部処分してしまって今考えるとかなり惜しいことしました。
電卓カタログは古いものほど値打ちありそうですね。



藤堂様、こんにちは!

>(中国語)堆桟
>(台 湾)堆畳

字を見てなんとなく意味がわかるのがよいですね(^^)
スタックを日本語にしても同じ感じになりそうです。


>スープを選ぶ、パンを選ぶなど、投稿前のクイズがでるので、

お寿司とかパスタとかハンバーガーとか、これって、何パターンあるんでしょうね(^^;

ところで、プレビューしてから公開にするとこのクイズがスルーされるような気がするのですが気のせい???

akatuki さんのコメント...

藤堂 様、遅うなりました。

> スープを選ぶ、パンを選ぶなど、投稿前のクイズがでるので、投稿がうまくいかなった・・・。(;´д`)
> きょうはケーキを選ぶの難問が出た。

いや、申し訳ない。
当方も、手前のblogだというのに、少し書き込みを怠ると「謎の認証クイズ」が出るので、ホトホト困っておる次第で。
何が悲しいと言って、結構難問が多いのです。何を考えているのだか、blogger。

> コンピュータ用語はほとんどが英語のカタカナ。Wikipeadiaの他言語版を調べたら、
> (中国語)堆桟
> (台 湾)堆畳
> スタックの概念を示す図を表しているような。
> 畳も、スタックの概念図を連想しそうですね。
> 漢字で書いて、スタックとルビを売って使いたい気分。

面白い話題、有難う御座居ます。
「堆」という字を使う「堆肥」なんてものがありました。
スタック(Stack)いうと「藁の積み上げたもの」でしたネ。そんでもって「堆肥」になったのか。
「ボルタの電堆」なんてものもありました。

akatuki さんのコメント...

Sentaro 様、遅うなりました。

> 入出力はHPGCC2のサイトに載っている円周率計算プログラムの仕様をそのまま取り入れたのでRPLに比べるとかなり楽な移植に(^^;
> とりあえず、整数版、実数版ひとまず完了です。
> picalc_HPGCC2.zip
> 整数版ならプチコン3号より速いですけど、実数版はFPUがないので遅めですね。
> でも、さすがにHPGCCなのでPrimeよりは一桁以上速くなりました(^^)

お疲れ様です !
そういや、計時もやっておりますネ。参考になります ! 多謝 !!

> PrimeもHPGCCが使えるようになってくれないと魅力半減ですね…。

未だ、バイナリの実行メカが実装されていないので、惜しいです。
いや、もしかするとマニュアルに書かれていないだけなのか、などと疑ったりして ?
でも、そうだとすると、アメリカのハッカー集団が暴いていてもおかしくないのか ... 。ウーン。

> うちにもいくつかあったんですけど、ある時期に全部処分してしまって今考えるとかなり惜しいことしました。
> 電卓カタログは古いものほど値打ちありそうですね。

いや、ホントに勿体無いと思うのですヨ、今から思うに。
しかし、紙って結構かさばるので、どうしても処分してしまう ... 。

> ところで、プレビューしてから公開にするとこのクイズがスルーされるような気がするのですが気のせい???

あっ、そうでしたか ! これはチョット試してみたくなります。
当方、毎日の様にコメントを入れると謎クイズが出なくなる様に感じましたが、どうにも挙動不審 。

Sentaro さんのコメント...

akatuki様、こんばんは!

>そういや、計時もやっておりますネ。参考になります ! 多謝 !!

あ゛、(全然たいしたものではないですが…)肝心の時間計測部分のソースが抜けておりました(^^;

RPLでは1/8192の単位で計れるのでHPGCCでもそれで計れるかと思ったら秒単位しか計れなさそうで…ってことで一工夫したところですけど、なんとかRPL並に簡単に計れるようにようにしたいです。
どっかのレジスタを読めば可能になる感じでしょうかね?

あとは、HPGCC3でのオーバークロックをHPGCC2で実現させたいような感じも…(^^;


>当方、毎日の様にコメントを入れると謎クイズが出なくなる様に感じましたが、どうにも挙動不審 。

前回、前々回とプレビューから公開で認証がスルーされました。
今回もスルーになってしまうとこれは…?

akatuki さんのコメント...

Sentaro 様、こんばんは !

> あ゛、(全然たいしたものではないですが…)肝心の時間計測部分のソースが抜けておりました(^^;
> RPLでは1/8192の単位で計れるのでHPGCCでもそれで計れるかと思ったら秒単位しか計れなさそうで…ってことで一工夫したところですけど、なんとかRPL並に簡単に計れるようにようにしたいです。
> どっかのレジスタを読めば可能になる感じでしょうかね?

ウーム !?
内部に詳しくはないので ... 「?」です。申し訳ない。
ヘッダファイルとか見て、勉強してみようかなぁ ?

> あとは、HPGCC3でのオーバークロックをHPGCC2で実現させたいような感じも…(^^;

ありゃ、3ではオーバークロックだったのですか ! それでファーム書き換え ... ?
良く読んでいないので、うろ覚えですが、確か2では通常12MHz運転の50Gを72MHz運転に出来るとか。
「sys_slowOff();」で72MHz、「sys_slowOn();」で12MHz、という感じらしいなのか ?
これ以上でしばくために3ではファーム書き換え、って具合ですかネ。かなりクリチカル ?

> 前回、前々回とプレビューから公開で認証がスルーされました。
> 今回もスルーになってしまうとこれは…?

ウーン !?
やはり、そこが鍵の様ですネ。チョット試してみます !

Sentaro さんのコメント...

akatuki様、こんばんは!

昨日もプレビューから公開だと認証作業が不要でした。
ってことで、英数字入力や画像を選べからやっと開放されたっぽいです。
…と思ったのですが、よくよく考えるとgoogleにアカウントあってログインしっぱなしなのでそれでスルー出来たのかもです?


>ありゃ、3ではオーバークロックだったのですか ! それでファーム書き換え ... ?

まだソースとかヘッダファイルとか眺めている程度ですけど、オーバークロック用の関数がデフォルトで用意されているという感じみたいです。
本体ファーム書き換えはオーバークロック用なのかどうかは今のところわかってません(^^;

ただ、通常RPLで200MHzに出来るFEVALとかがありますから、HPGCC2でもオーバークロックは出来るはずなので、HPGCC3のソースを読んでちょこっと研究してみます。


>良く読んでいないので、うろ覚えですが、確か2では通常12MHz運転の50Gを72MHz運転に出来るとか。
>「sys_slowOff();」で72MHz、「sys_slowOn();」で12MHz、という感じらしいなのか ?

sys_slowOff()を削除してsys_slowOn()にすると一気に約1/6の速度になるので12MHzは合ってる感じです。
と考えると、スタックがずらずら並ぶと書き換えが微妙にもっさりするのは12MHz動作ということだったのかも(^^;

Sentaro さんのコメント...

そのまま「コメントを公開」だけでOkでした!

ログインしていれば「私はロボットではありません」は無視してもよさそうです(^^)

akatuki さんのコメント...

Sentaro 様、こんばんは !

> まだソースとかヘッダファイルとか眺めている程度ですけど、オーバークロック用の関数がデフォルトで用意されているという感じみたいです。
> 本体ファーム書き換えはオーバークロック用なのかどうかは今のところわかってません(^^;

当方も少し けさんく(←なぜか変換できない)してみました。

http://sourceforge.net/p/hpgcc/mailman/message/20384665/

仰るように、3には謹製サービスがある様です。

> ただ、通常RPLで200MHzに出来るFEVALとかがありますから、HPGCC2でもオーバークロックは出来るはずなので、HPGCC3のソースを読んでちょこっと研究してみます。

ウーン、やはり、ソース探求ですか ... 。
当方、そこまで踏み込んで行けそうにないので、Sentaro様の研究に期待します !

> sys_slowOff()を削除してsys_slowOn()にすると一気に約1/6の速度になるので12MHzは合ってる感じです。
> と考えると、スタックがずらずら並ぶと書き換えが微妙にもっさりするのは12MHz動作ということだったのかも(^^;

速度切り替えのメカは表示関連の都合であるっぽく、遅くしないと表示が乱れる ? 様な。
昔の8 bit PCで、DMAの都合とかでVRAMの操作をタイミングを気にしてアセンブリコードを書いた様な感じなのかも ?
(当方、そこまでやった事はありませんが)

> そのまま「コメントを公開」だけでOkでした!
> ログインしていれば「私はロボットではありません」は無視してもよさそうです(^^)

なるほどです !
しかし、ログインしっぱなしって、少々気になってしまいますね ... 。
そこまでするのか、Google。

Sentaro さんのコメント...

akatuki様、こんばんは!

>当方も少し けさんく(←なぜか変換できない)してみました。

毛三区(←なぜかこう変換するMSIME)、もとい、検索ありがとうございます(笑)

リンク先を読んでみると高精度タイマーは割り込みでしか実現不可能となるとなにげにやっかいな感じで、もう少し調べてみてダメだったら素直にHPGCC3に行くのがよさそうな感じも(^^;

>速度切り替えのメカは表示関連の都合であるっぽく、遅くしないと表示が乱れる ? 様な。

FEVALで200MHzにすると微妙に表示が乱れかかってる感があるのですが、そういうことだったのですね。
SH4のfx-CG10でも画面表示にDMA使っててメモリクロック上げすぎると画面が崩れてきますけど、似たような感じなのでしょう。
ハードウエアの深い部分はARMのデータシートをじっくり読む必要がありそうです。


>しかし、ログインしっぱなしって、少々気になってしまいますね ... 。
>そこまでするのか、Google。

ログインしっぱなしというか、ブラウザもChromeなので閉じてまた次にブラウザ開く時には自動的にログイン状態になっているというか…ログオフ忘れるのでいつもそのままだったりです(^^;
とりあえず、Google垢でログインして書き込みすれば認証は不要ってことになってるみたいでしょうか。

akatuki さんのコメント...

Sentaro 様、お晩です !

> リンク先を読んでみると高精度タイマーは割り込みでしか実現不可能となるとなにげにやっかいな感じで、もう少し調べてみてダメだったら素直にHPGCC3に行くのがよさそうな感じも(^^;

ウーン、やはりそんな感じですね。
HPGCC3は新しいプロジェクトで、HPGCCで検索すると3の話題が多く、2の方は本家サイトもドメインが売りに出されているという状態です。
これからは3の方が良いのかなぁ ... 。

> FEVALで200MHzにすると微妙に表示が乱れかかってる感があるのですが、そういうことだったのですね。
> SH4のfx-CG10でも画面表示にDMA使っててメモリクロック上げすぎると画面が崩れてきますけど、似たような感じなのでしょう。

当方、FEVALっていうの使った事がないものでよう判りまへんが ... 。
バイナリはハードの性能を極限まで引き出す分、色々と面倒になって来る、という具合ですネ。

> ハードウエアの深い部分はARMのデータシートをじっくり読む必要がありそうです。

踏み込んでみますか !
jdsysasm.pdf (http://www.hpcalc.org/details.php?id=7114)を眺めておりますと、深い部分のコードを作業するには、SaturnやARMのアセンブリをやらないとアカン様な感じで。
コレはキツイ。

> ログインしっぱなしというか、ブラウザもChromeなので閉じてまた次にブラウザ開く時には自動的にログイン状態になっているというか…ログオフ忘れるのでいつもそのままだったりです(^^;
> とりあえず、Google垢でログインして書き込みすれば認証は不要ってことになってるみたいでしょうか。

最近はbloggerもloginする時に、メールアドレスとパスワードを別々のページで入力する様になっていて、この辺り「少しセキュリティを考えているのか」と思われますが、そうか ! Googleとしては「loginすればセキュリティは保証してやる」というハラなのか !
何とも ... 。

そういや、細かい所が少しずつ変わっております。この辺りも不可解 ?

Sentaro さんのコメント...

akatuki様、こんばんは!

>HPGCC3は新しいプロジェクトで、HPGCCで検索すると3の話題が多く、2の方は本家サイトもドメインが売りに出されているという状態です。
>これからは3の方が良いのかなぁ ... 。

HPGCC2は本家サイトが消滅しちゃってるのですか…。
HPGCC2は本体書き換えずとも使えるのがポイント高いので残しておきたいところですけど、HPGCC3でしか出来ないことが多くなると移行するしかない感じですよね。
いずれNewRPLとかも試してみたいですし…。


>踏み込んでみますか !

S3C2410のデータシートをとりあえず落としました。
英語版なのはちと難儀ですけど、HPGCC3のソースと見比べるとなんとかなるでしょう(^^;


>jdsysasm.pdf (http://www.hpcalc.org/details.php?id=7114)を眺めておりますと、深い部分のコードを作業するには、SaturnやARMのアセンブリをやらないとアカン様な感じで。
>コレはキツイ。

う…む、やっぱりSaturnからARMまでいじらないといけないのですね(^^;
全部理解するまではかなり時間かかるかもですけどサンプルも付いていてすごく参考になりそうです。
それにしても、Saturnって4ビットCPUなのに64ビットレジスタあったりとかなり個性的なCPUですね。
こういう面白さが最近の電卓にもちょっと欲しかったり…(^^;

akatuki さんのコメント...

Sentaro 様、遅うなりました !

> HPGCC2は本体書き換えずとも使えるのがポイント高いので残しておきたいところですけど、HPGCC3でしか出来ないことが多くなると移行するしかない感じですよね。
> いずれNewRPLとかも試してみたいですし…。

HPGCC2は使いやすかったのですが、3のプロジェクトは、より高機能な環境を目指しているのでしょう。
ただ、2を少しでも使っていれば、3も見通しが良くなりそうな ?
NewRPLも面白そうですネ。コレは3も研究しがいがありそうです。
当方は、まだまだ不勉強なので、今暫くは2で作業を進めるつもりです、ハイ。

> S3C2410のデータシートをとりあえず落としました。
> 英語版なのはちと難儀ですけど、HPGCC3のソースと見比べるとなんとかなるでしょう(^^;

おっ、行きますネ !
結構大変な作業になりそうなので、のんびりと楽しみながら進めて戴き度。

> う…む、やっぱりSaturnからARMまでいじらないといけないのですね(^^;
> 全部理解するまではかなり時間かかるかもですけどサンプルも付いていてすごく参考になりそうです。

アセンブリコマンドASMで、Saturn, ARMのアセンブリも出来るらしいのですが、結構難易度が高そうで ... 。

> それにしても、Saturnって4ビットCPUなのに64ビットレジスタあったりとかなり個性的なCPUですね。
> こういう面白さが最近の電卓にもちょっと欲しかったり…(^^;

以前に少しかじったのですが、4 bit = 1 nibbleマシンで、それをまとめてBCD計算に使っているとかナントカ。
で、この辺りの考え方がItaniumのVLIWにつながったのかなぁ ? なんてネ。(ウソですヨ !)
そういや、PC-1246でしたか、アレも4 bitマシンでしたネ。Intel 4004も4 bitでしたっけか ?

たまには、こうしたお勉強もしないとアカンのですが、なかなか時間も取れず。
現在、SysRPLの方でゴチャゴチャやっておりまして、その内ネタとして公開しようと思っているのですが、結構難儀して居り。

Sentaro さんのコメント...

akatuki様、こんばんは!

>以前に少しかじったのですが、4 bit = 1 nibbleマシンで、それをまとめてBCD計算に使っているとかナントカ。

ニブルという言葉が頻繁に出てくるのがなにげに新鮮なのですが、30年くらい前の設計なのでいまどきのCPUと比べるとかなりの個性を感じますね(^^;

>そういや、PC-1246でしたか、アレも4 bitマシンでしたネ。Intel 4004も4 bitでしたっけか ?

4004は記念すべき最初の4ビットCPUですね。
PC-1246はマシン語使えないのが惜しかったですけど、4ビットCPUということでした。
もし実際には8ビットCPUだったとしても正体は不明ですね(^^;


ちょい前の話題ですが、こちらにCASIO電卓の古いカタログがPDFでアップされてます。
http://www.casio-calculator.com/
左のDownloadからCataloguesです。

80年代のカタログはいくつかは持っていたのですがすでに手元にないので、改めて今見ると新しい発見がちらほらとあったり…。

akatuki さんのコメント...

Sentaro 様、こんばんは!

> ニブルという言葉が頻繁に出てくるのがなにげに新鮮なのですが、30年くらい前の設計なのでいまどきのCPUと比べるとかなりの個性を感じますね(^^;

当方、Saturnでこんなものがあるって知ったクチなのですが、確かに「新鮮」ですネ。
30年前って、やはり歳がバレてしまう ... ?

> PC-1246はマシン語使えないのが惜しかったですけど、4ビットCPUということでした。
> もし実際には8ビットCPUだったとしても正体は不明ですね(^^;

ウーム ... 仰る通りです。

> ちょい前の話題ですが、こちらにCASIO電卓の古いカタログがPDFでアップされてます。
> http://www.casio-calculator.com/
> 左のDownloadからCataloguesです。
> 80年代のカタログはいくつかは持っていたのですがすでに手元にないので、改めて今見ると新しい発見がちらほらとあったり…。

いや、これは大変興味深い情報です ! 有難う御座居ます !

そういや、今日は大きな地震がありました。当方、結構大きな揺れに驚いてしまいましたヨ !

Sentaro さんのコメント...

akatuki様、こんばんは!

ちょっと思い立ってSysRPL版のローカル変数を名前無しにしたところ、Spigot版がかなりスピードアップしました。
LAMという表記が要らないのでソースが見易くなって、といってもいきなりこのソースだけ見ると何をやってるか分かりにくいのは相変わらず(^^;
今のところ、Spigot版が遅いのも相変わらずですが、倍精度の方が速くなるという逆転現象も…
最初の数分かかっていたUserRPL版からするとかなりの高速化が達成できました。
こういうところがHP-50Gの面白さですね(^^)

SysRPL版その4 (名無しローカル変数版)
PI_CALC1_SysRPL4.txt 100桁(BASE8桁) 0分39秒
PI_CALC2_SysRPL4.txt 100桁(BASE6桁) 0分37秒

SysRPL版その4 (名無しローカル変数版) 倍精度版
PI_CALC1_SysRPL4dbl.txt
100桁(BASE8桁) 0分35秒
100桁(BASE10桁) 0分28秒

PI_CALC2_SysRPL4dbl.txt
100桁(BASE6桁) 0分37秒
100桁(BASE7桁) 0分33秒


Spigot版の配列を行列にしてみたところ、若干速くなりましたが…倍精度が使えないみたいなのが惜しいです(^^;

SysRPL版その5 (名無しローカル変数版+配列MATRIX化)
PI_CALC2_SysRPL5.txt 100桁(BASE6桁) 0分35秒

akatuki さんのコメント...

Sentaro 様、こんにちは ! 負荷が上がっていて、遅うなりました !!

> ちょっと思い立ってSysRPL版のローカル変数を名前無しにしたところ、Spigot版がかなりスピードアップしました。
> LAMという表記が要らないのでソースが見易くなって、といってもいきなりこのソースだけ見ると何をやってるか分かりにくいのは相変わらず(^^;

名無し変数にすると、そんな功徳があるのですか !
コチャコチャしてしまいそうで、敬遠しておりましたが、これは一考の余地があります。お知らせ、多謝 !

> 今のところ、Spigot版が遅いのも相変わらずですが、倍精度の方が速くなるという逆転現象も…

ウーム ?
倍精度の方が早いというのは興味深いです。
もしかすると、倍精度はARMネィテイヴで構成されていたりして ? なんてネ。

> 最初の数分かかっていたUserRPL版からするとかなりの高速化が達成できました。
> こういうところがHP-50Gの面白さですね(^^)

当方も、コチャコチャとした事をやっていて、UserRPLとSysRPLとを作業して、劇的に速度向上があって面白いなぁと感心していた所です。

> Spigot版の配列を行列にしてみたところ、若干速くなりましたが…倍精度が使えないみたいなのが惜しいです(^^;

これも意外ですネ。
配列の大きさが固定であり、リスト検索の様な手続きを経ない分、要素のアクセスで速度が稼げた、という辺りなのかしらん ?

Sentaro さんのコメント...

akatuki様、おつかれさまです!

>名無し変数にすると、そんな功徳があるのですか !

1GETLAMとか1PUTLAMとかいう感じの味気ない感じだったので最初は敬遠していたところですけど、スタックの次に速いというのを見つけまして、実際試してみたらあっと驚く効果が!というところでした。
グローバル変数が遅いのは最初の頃からわかってましたけど、同じローカル変数でも名前の有無でこれだけ差が出るとは意外でした。


>当方も、コチャコチャとした事をやっていて、UserRPLとSysRPLとを作業して、劇的に速度向上があって面白いなぁと感心していた所です。

Cのソースをコンパイルして速くなるのとはまた違った、なんていうか不思議な面白さありますよね(^^)


>これも意外ですネ。
>配列の大きさが固定であり、リスト検索の様な手続きを経ない分、要素のアクセスで速度が稼げた、という辺りなのかしらん ?

配列をスタック上に置いてアクセスしているとしばらくするとガベージコレクションで1秒くらい止まるのですが、行列アクセスだとそれが起きないので速くなるという感じみたいです。
詳しくはわかってないので、見当違いかもですけど(^^;

akatuki さんのコメント...

Sentaro 様、お晩です。

> 1GETLAMとか1PUTLAMとかいう感じの味気ない感じだったので最初は敬遠していたところですけど、スタックの次に速いというのを見つけまして、実際試してみたらあっと驚く効果が!というところでした。
> グローバル変数が遅いのは最初の頃からわかってましたけど、同じローカル変数でも名前の有無でこれだけ差が出るとは意外でした。

ウーム。
ローカル変数といえども、変数名の照会に手間が掛かる、無名変数の場合は(局所変数領域の先頭)ポインタからの相対位置で示されるので早い、のかなぁ ?

> Cのソースをコンパイルして速くなるのとはまた違った、なんていうか不思議な面白さありますよね(^^)

仰る通りです !
Cは激烈に早いのですが、本体でポチポチ作業できて (もうイタズラはヤメレ)、効果が即座に判る、という所が面白いです。
Debug4 を入れてEmu50Gでコードを動かしてみましたが、確かにイイですね。問題は、実機よりも高速動作なので(オプションを設定すると実機と同様になるみたいですが)、いい感じでコードを動かしていると、実機に持って行った時に少々気落ちしてしまう所も ... 。

> 配列をスタック上に置いてアクセスしているとしばらくするとガベージコレクションで1秒くらい止まるのですが、行列アクセスだとそれが起きないので速くなるという感じみたいです。
> 詳しくはわかってないので、見当違いかもですけど(^^;

GCが発生しない、という辺りは「鍵」なのかも知れません。

Sentaro さんのコメント...

akatuki様、皆様、こんにちは!

ずっと出来ないものとばかり思っていたSysRPLでのUNPICKですけど、使えることがわかったので試してみたら若干速くなりました。

SysRPL版その6 (名無しローカル変数版) ROLL/UNROLL → PICK/UNPICK
PI_CALC1_SysRPL6.txt 100桁(BASE8桁)  36.7秒
PI_CALC2_SysRPL6.txt 100桁(BASE6桁)  34.5秒

SysRPL版その6 (名無しローカル変数版) 倍精度版 ROLL/UNROLL → PICK/UNPICK
PI_CALC1_SysRPL6dbl.txt
100桁(BASE8桁)  31.4秒
100桁(BASE10桁)  26.3秒

PI_CALC2_SysRPL6dbl.txt
100桁(BASE6桁)  33.5秒
100桁(BASE7桁)  29.9秒


それからずっと試してみたかった多桁のZINTでの直接の計算ですが…

SysRPL版その6 (ZINT、名無しローカル変数Debug4x版)
PI_CALCZ_SysRPL1.txt 100桁  1432秒

ってことで、異常に遅いので整数化処理はやる気なくして未遂です(^^;


ちなみに、TI Nspire CX CAS の多桁整数版では、
--------------------------
Define PiCalcZ(k)=      // 計算桁数
Prgm
 Local k,a,p,n,f,r
 f:=int(((k)/(log(2,10))))  // ループ回数
 a:=2
 For n,f,1,−1
  a:=((a*n)/(2*n+1))
  a:=a+2
 EndFor
 n:=getNum(a)      // 分子を取り出す
 d:=getDenom(a)     // 分母を取り出す
 r:=mod(n*10^(k),d)   // 剰余
 p:=((n*10^(k)-r)/(d))  // 分子から剰余を引いて割り切れるようにする
 Disp p
EndPrgm
--------------------------

PiCalcZ(100)  0.7s
PiCalcZ(255)  2.1s

計算結果aは分数になるので最後に整数化処理です。
速度的には劇的に速くなったんですけど、258桁以上は計算できず∞になります。
多桁といえども499桁までしか計算できないっぽいので途中でオーバーフローしてそうです。

従来の配列での計算だと
PICAL1B 100桁(BASE10桁) 13.3秒
PICAL2B 100桁(BASE7桁) 12.1秒
だったのでこちらは10倍以上の高速化になりました。

こうなるとHP Primeでも試してみたいところですけど、多桁演算をどうやるのかがまだ分かってなかったりします(^^;

akatuki さんのコメント...

Sentaro 様、こんばんは ! 遅うなりました。

> ずっと出来ないものとばかり思っていたSysRPLでのUNPICKですけど、使えることがわかったので試してみたら若干速くなりました。

お疲れ様です ! UNPICKって、

INDEX@ PTR 373D0 ( UNPICK_ )

という行でしょうか。これは勉強になります ! これから調べてみたく思います。

> それからずっと試してみたかった多桁のZINTでの直接の計算ですが…
> SysRPL版その6 (ZINT、名無しローカル変数Debug4x版)
> PI_CALCZ_SysRPL1.txt 100桁  1432秒
> ってことで、異常に遅いので整数化処理はやる気なくして未遂です(^^;

アレーッ、やってしまいましたのん !?
確かにアカンみたいですね。整数だからもう少し早いかと思っていたのですが、動的にメモリを確保するのに手間取っていて、それが足を引っ張っているのかしらん ?

> ちなみに、TI Nspire CX CAS の多桁整数版では、
> PiCalcZ(100)  0.7s
> PiCalcZ(255)  2.1s
> 計算結果aは分数になるので最後に整数化処理です。
> 速度的には劇的に速くなったんですけど、258桁以上は計算できず∞になります。
> 多桁といえども499桁までしか計算できないっぽいので途中でオーバーフローしてそうです。

Nspireのコードって、PRIMEっぽいのですね。勉強になります。
それはさておき、Nspire CASは、そこが難しいのですか ... 。
確かに特殊用途ではありますから、TIも「ここまでやらんだろう」と思っていたのだと。

> こうなるとHP Primeでも試してみたいところですけど、多桁演算をどうやるのかがまだ分かってなかったりします(^^;

言われてみればそうでした !
CASモードではZINTっぽい計算しておりました ! これを活かせばヨイ、という具合ですね。
ウーン。試してみようかなぁ ?

akatuki さんのコメント...

Sentaro 様

HP Primeのマニュアルを少し検討したのですが、現状ではどうも無理っぽい印象です。

任意長整数はCASモード「囲い込み」っぽい感じで、小文字ホーム変数に結果を代入し、PPLプログラムで使用すると、その時点でBCD変換されてしまう様です。

ただ、サービスルーチンは存在しているので、今後、(SysRPLの様に)システムサービスを利用できる様になれば、という期待があります。

Sentaro さんのコメント...

akatuki様、こんにちは!

>INDEX@ PTR 373D0 ( UNPICK_ )
>という行でしょうか。これは勉強になります ! これから調べてみたく思います。

はい!それです。
実機ではコマンドアドレス直接指定の「PTR 373D0」でDebug4xでは「UNPICK_」という感じです。
Debug4xで、ずっと使い方が分からなかったんですけど、CTRL+SPACEで出てくるコマンドアシスト?で「UNPICK_」が出てきたので使えることがわかりました。

>アレーッ、やってしまいましたのん !?
>確かにアカンみたいですね。整数だからもう少し早いかと思っていたのですが、動的にメモリを確保するのに手間取っていて、それが足を引っ張っているのかしらん ?

実数の速度に比べるとかなり桁違いに遅くなるので、ZINT処理はなにかオーバーヘッドが相当にある感じですね。
四則演算するにもZINT専用は無くてCAS用のコマンドを使うしかないみたいですし。


>任意長整数はCASモード「囲い込み」っぽい感じで、小文字ホーム変数に結果を代入し、PPLプログラムで使用すると、その時点でBCD変換されてしまう様です。

やはり、そうなりますよね(^^;

プログラムカタログで新規に作成する場合に、CASのチェックボックスがあるのが怪しいと思ってそこをチェックすると、、

#cas
test():=
BEGIN
return 0;
END;
#end

というのが出来て、それをちょこっといじって、

#cas
test(n):=
BEGIN
return n*n;
END;
#end

とかにすれば、CASモードで、
test(123456789)
15241578750190521
という結果になって多桁計算していることが確認できるのですけど、ループ構造とか入れるとエラーになって上手くいかず…で単純なプログラムしか出来ないという感じです(^^;

akatuki さんのコメント...

Sentaro 様、こんばんは ! 興味深い情報、多謝です !

> はい!それです。
> 実機ではコマンドアドレス直接指定の「PTR 373D0」でDebug4xでは「UNPICK_」という感じです。
> Debug4xで、ずっと使い方が分からなかったんですけど、CTRL+SPACEで出てくるコマンドアシスト?で「UNPICK_」が出てきたので使えることがわかりました。

いや、Debug4x にそういう使い方があったとは ! 恐れ入ります !
一方、アドレス直接指定のアドレス(373D0)ですが、どこに出ていたの ? と思っておりましたが、つぎのPDFにありましたネ !

HP 49 entries, PDF extract from the Database - HPCalc.org
http://www.hpcalc.org/details.php?id=5476

もっと勉強せなアカンです、ハイ。

> プログラムカタログで新規に作成する場合に、CASのチェックボックスがあるのが怪しいと思ってそこをチェックすると、、

あれっ、そう言われてみれば、そんなチェックボックスがありました !
古いエミュレータを使ってプログラムをやっておりましたが、以来、余り使っていなかった事もあって、見過ごしておりました。

> という結果になって多桁計算していることが確認できるのですけど、ループ構造とか入れるとエラーになって上手くいかず…で単純なプログラムしか出来ないという感じです(^^;

古いエミュレータには無かったチェックボックスなので、もしかすると、将来のファーム更新で使える様になったりするのかも ? と、チョット期待してみたりして ... 。

そういや、HP Primeのftpページ (?)、Conn kitファイルの日付だけが06/17になっております。ファイル名の方は同じなので、一旦引っ込めてからもう一度upしたみたいで、チョット気になります。

Sentaro さんのコメント...

akatuki様、こんばんは!

>一方、アドレス直接指定のアドレス(373D0)ですが、どこに出ていたの ? と思っておりましたが、つぎのPDFにありましたネ !

はい、私もそのPDFを見るまではUNPICKは使えないものだとばかり…(^^;
PTRコマンドで非公式コマンドでも使える目処がたったのでSysRPLの世界がまた広がりました。


>古いエミュレータには無かったチェックボックスなので、もしかすると、将来のファーム更新で使える様になったりするのかも ? と、チョット期待してみたりして ... 。

今後のバージョンアップに期待するしかなさそうですね。。。
って、思って、Hpcalcを探索していたら、
http://www.hpcalc.org/details.php?id=7534
CASプログラムの参考になるソースを見つけまして、そしたら普通にWHILEを使っていたのであれ?と思って、新たに最初からコマンドごとにエラーチェックしながらソースを書いていったら、ループ入れてもエラー出ることなく無く出来ちゃいました。
CASプログラムではエラーの出る箇所がいつも最初の方で??な場所だったりで???でした(^^;

というわけで、HP Primeでも多桁計算が出来ることに…。
ソースはNspireとほぼそっくりです(笑)
--------------------------
#cas
PiCalcZ(k):=       // 計算桁数
BEGIN
 local a,b,p,n,d,r;
 f:=ip(k/log(2));     // ループ回数
 a:=2; b:=1;
 for n from f downto 1 step -1 do
  a:=a*n/(2*n+1);
  a+=2;
 end;
 n:=numer(a);       // 分子を取り出す
 d:=denom(a);       // 分母を取り出す
 r:=irem(n*10^k,d);    // 剰余
 p:=iquo((n*10^k)-r,d);  // 分子から剰余を引いて割り切れるようにする
 return p;
END;
#end
--------------------------

CASモードで、
PiCalc(100)    0.21s
PiCalc(1000)   7.3s

Nspire同様に配列プログラム版からすると一気に速くなりました。

CASプログラムは関数と同じなので計算時間測定は
time(PiCalc(1000))としました。

最高1153桁まで計算できたということでNspireよりは多桁計算が可能でした(^^)

結果として、一番多桁演算可能なのは50GのZINTということになりそうですけど、計算時間があまりにも厳しいので…
ここはARMネイティブでの実装が望まれるところですね。


>そういや、HP Primeのftpページ (?)、Conn kitファイルの日付だけが06/17になっております。ファイル名の方は同じなので、一旦引っ込めてからもう一度upしたみたいで、チョット気になります。

ちょこっと落としてチェックしてみたところ、何も変わっちゃいませんでした(^^;

Sentaro さんのコメント...

ちょこっと、というかかなり訂正です(^^;
ループ回数を求めるlogが小文字だと自然対数LNになってしまっていたので結果が違いました。

--------------------------
#cas
PiCalcZ(k):=       // 計算桁数
BEGIN
 local a,b,p,n,d,r;
 f:=ip(k/LOG(2));     // ループ回数 LOGは小文字だとLNなので大文字に
 a:=2;
 for n from f downto 1 step -1 do
  a:=a*n/(2*n+1);
  a+=2;
 end;
 n:=numer(a);       // 分子を取り出す
 d:=denom(a);       // 分母を取り出す
 r:=irem(n*10^k,d);    // 剰余
 p:=iquo((n*10^k)-r,d);  // 分子から剰余を引いて割り切れるようにする
 return p;
END;
#end
--------------------------
HP Prime版 PICAL Z(CAS多桁版)

これでループ回数がかなり違ってしまったので計算結果も限界も違ってきて、
PiCalcZ(100)    0.512s
PiCalcZ(255)    2.585s
PiCalcZ(1000)   計算できず…

最高計算可能桁数は、
PiCalcZ(668)   19.192s
という結果です。

配列版での結果が、
HP Prime版 PICAL1B 100桁(BASE7桁) 1.4秒
HP Prime版 PICAL2B 100桁(BASE6桁) 0.9秒
こういう感じだったので、
Nspireに比べると、多桁計算でもあまり速くならない結果となりました…(^^;

akatuki さんのコメント...

Sentaro 様、お疲れ様です !

> はい、私もそのPDFを見るまではUNPICKは使えないものだとばかり…(^^;
> PTRコマンドで非公式コマンドでも使える目処がたったのでSysRPLの世界がまた広がりました。

ウーム。この情報、なかなか深いものがあります。ちょこっと調べて見たく。有難う御座居ます !

> って、思って、Hpcalcを探索していたら、
> http://www.hpcalc.org/details.php?id=7534
> CASプログラムの参考になるソースを見つけまして、そしたら普通にWHILEを使っていたのであれ?と思って、新たに最初からコマンドごとにエラーチェックしながらソースを書いていったら、ループ入れてもエラー出ることなく無く出来ちゃいました。
> CASプログラムではエラーの出る箇所がいつも最初の方で??な場所だったりで???でした(^^;
> というわけで、HP Primeでも多桁計算が出来ることに…。

いや、これは驚き ! 素晴らしい成果です、恐縮 !

> ちょこっと落としてチェックしてみたところ、何も変わっちゃいませんでした(^^;

そうですよネ ... 。
と思っていたら、もう新しいのがでておりますネ !

Sentaro さんのコメント...

akatuki様、こんばんは!

>と思っていたら、もう新しいのがでておりますネ !

やっぱりアップデートの兆候だったんですね。
ってことで、早速アップデートしてみたら、CASプログラムでの変な感じは直ってないみたいですし、何が変わったのかよくわかりません(^^;

とりあえず実使用で試すしかないので、
HP Primeでの多桁計算の高速化手段として、、
分子と分母でそれぞれ別に計算することにしてみました。

--------------------------
#cas
PiCalcZ2(k):= // 計算桁数
BEGIN
 local a,b,f,p,n,d,r;
 f:=ip(k/LOG(2)); // ループ回数 LOGは小文字だとLNなので大文字に
 a:=2; b:=1; // 分子:a 分母:b
 for n from f downto 1 step -1 DO
  a:=a*n;
  b:=b*(2*n+1);
  a:=a+2*b;
 end;
 n:=a; // 分子を取り出す必要なし
 d:=b; // 分母を取り出す必要なし
 r:=irem(n*10^k,d); // 剰余
 p:=iquo((n*10^k)-r,d); // 分子から剰余を引いて割り切れるようにする
 return p;
END;
#end
--------------------------
PiCalcZ2(100)    0.17s
PiCalcZ2(255)    計算できず…

最高計算可能桁数は、
PiCalcZ2(251)   0.506s
という結果でした。

途中で分数にならない分、かなり速くなるようですが計算可能桁数が減ってしまいます。。

ということで、これは50GのZINTでも効果あるのではと思ってやってみると…

SysRPL版その7 (ZINT分数回避、名無しローカル変数版 Debug4x用ソース)
PI_CALCZ_SysRPL2_debug4x.txt 100桁  31秒

配列版より速くならなかったのは惜しかったですけど、まずまずの結果となりました(^^)

前回の、
SysRPL版その6 (ZINT、名無しローカル変数版 Debug4x用ソース)
PI_CALCZ_SysRPL1_debug4x.txt 100桁  1432秒
からすると劇的な高速化です。

ZINTの利点として3万桁を越える範囲の整数を扱えるので計算桁数はかなりいけそうです。

1000桁でエミュだと73秒くらいですけど、
実機で3129秒、たった今終わりました(^^;

akatuki さんのコメント...

Sentaro 様、こんばんは ! お疲れ様です !

> ってことで、早速アップデートしてみたら、CASプログラムでの変な感じは直ってないみたいですし、何が変わったのかよくわかりません(^^;

ウーン。
PDFはそのままなので、Bug fixくらい ?

> HP Primeでの多桁計算の高速化手段として、、
> 分子と分母でそれぞれ別に計算することにしてみました。

あ、なるほど ! 上手い方法ですね !

> PiCalcZ2(100)    0.17s
> PiCalcZ2(255)    計算できず…
> 最高計算可能桁数は、
> PiCalcZ2(251)   0.506s
> という結果でした。
> 途中で分数にならない分、かなり速くなるようですが計算可能桁数が減ってしまいます。。

ムム !?
剰余を求める所で、アカンかった ? これは「食わせ物」ですネ。

> ということで、これは50GのZINTでも効果あるのではと思ってやってみると…
> SysRPL版その7 (ZINT分数回避、名無しローカル変数版 Debug4x用ソース)
> PI_CALCZ_SysRPL2_debug4x.txt 100桁  31秒
> 配列版より速くならなかったのは惜しかったですけど、まずまずの結果となりました(^^)
> ZINTの利点として3万桁を越える範囲の整数を扱えるので計算桁数はかなりいけそうです。
> 1000桁でエミュだと73秒くらいですけど、
> 実機で3129秒、たった今終わりました(^^;

お疲れ様です。
内蔵ルーチンの階乗でもかなり時間が掛かったので、これなら十分早い部類でしょうネ。

ところで、

> とりあえず実使用で試すしかないので、

との事ですが、HP Primeのコードってエミュレータでは動くのでしょうか ?
コピペしてみたのですが、行頭の「#cas」で構文エラーって出るのです。エミュレータの具合が悪いのか ?
MoHPC.orgの「hex」の方は、構文にエラーはないのですが、実行しても何も結果が出ず、式をそのまま返すだけ。チョット、ドツボにハマっております。相変わらず、初心者だなァ ... 。

Sentaro さんのコメント...

akatuki様、こんにちは!

>ウーン。
>PDFはそのままなので、Bug fixくらい ?

ファームウエアのアップデートを解凍して出てくる、
release_info.txt
に詳細が書いてあるんですけど、バグフィックスと地道な改善という感じですね。
今のところは自分の使い方ではアップデートの影響がほぼない状態です(^^;


>ムム !?
>剰余を求める所で、アカンかった ? これは「食わせ物」ですネ。

はい。剰余のところで限界が決まってしまってるみたいです。
試しに剰余手前の段階で止めると限界は275桁まで伸びます。
分子と分母を別々に計算すると桁数はリニアに増えていきますが、
分数のままで計算すると途中で約分されることもあって桁数が抑えられますね。
ま、その分、計算時間にしわ寄せが来るのですが…(^^;

>内蔵ルーチンの階乗でもかなり時間が掛かったので、これなら十分早い部類でしょうネ。

分数計算に比べると多桁整数の掛け算、足し算、引き算は遅くないことが分かりました。
計算終了後に結果出力で剰余や割り算してるところでえらいこと時間かかっているので、割り算が大変ってことですね。


>との事ですが、HP Primeのコードってエミュレータでは動くのでしょうか ?

はい、エミュでも実機でも速度以外は全く同様な動作です。

>コピペしてみたのですが、行頭の「#cas」で構文エラーって出るのです。エミュレータの具合が悪いのか ?

あ、これ私もハマってしまってた謎のCASのエラーかもですね。
行頭で出たり、その次で出たり、実際のエラーの箇所とは違うところで出てきたり、エラーがなさそうなのにエラーが出たりと謎が多いです。
とりあえず、↑の書き込みソースはインデントに全角スペースを入れているのですが、Primeではソース中に全角スペースがあっても動くことを確認済みなので、それがエラーになった原因ではないと思われます。
ですが、プログラム内の全角は予期せぬエラー発生の原因にもなりそうなので、
まっさらな新規プログラムに、こちらのテキスト版からのコピペで試してみてください。
HP Prime版 PICAL Z(CAS多桁版)
HP Prime版 PICAL Z(CAS多桁、分数回避版)

新規でCASのチェックボックスをチェックしなくても、通常プログラムから始めても#cas~#endの記述があるとCASプログラムと認識されるみたいですね。
コネクトキットで新規にプログラム作成する場合はCASチェックするところが見当たらないので気が付きました。


>MoHPC.orgの「hex」の方は、構文にエラーはないのですが、実行しても何も結果が出ず、式をそのまま返すだけ。チョット、ドツボにハマっております。相変わらず、初心者だなァ ... 。

もしかして、大文字と小文字が違ってたりしてませんでしょうか?
CASプログラムは、[Vars]キー押してからCAS変数のProgramから選択すると簡単に間違いなく入力できます(^^)

akatuki さんのコメント...

Sentaro 様、遅うなりました。

> あ、これ私もハマってしまってた謎のCASのエラーかもですね。
> 行頭で出たり、その次で出たり、実際のエラーの箇所とは違うところで出てきたり、エラーがなさそうなのにエラーが出たりと謎が多いです。

ウーム、そうですか。
仰るように、不可解な所で出くわすのですヨ。
ちょっと研究してみると面白そうですね、コレは。

> とりあえず、↑の書き込みソースはインデントに全角スペースを入れているのですが、Primeではソース中に全角スペースがあっても動くことを確認済みなので、それがエラーになった原因ではないと思われます。

そうでしたか !
全角スペースも当たり前に扱えるというのは「ワールドワイド」設計ですネ !

> ですが、プログラム内の全角は予期せぬエラー発生の原因にもなりそうなので、
> まっさらな新規プログラムに、こちらのテキスト版からのコピペで試してみてください。
HP Prime版 PICAL Z(CAS多桁版)
HP Prime版 PICAL Z(CAS多桁、分数回避版)

多謝です ! こちらはコピペでイッパーツ動作でした !

> 新規でCASのチェックボックスをチェックしなくても、通常プログラムから始めても#cas~#endの記述があるとCASプログラムと認識されるみたいですね。

仰る通りです。
このクロスハッチ、結構面白そうなもので、プラグマなんて機能もありました。

Undocumented feature(s) of rev 6030 - MoHPC
http://www.hpmuseum.org/forum/archive/index.php?thread-1427.html

今の所(?)、小数点と行末、区切り文字の指定と、整数のサイズ(32/64 bit?)を規定するという機能があるみたいです。
まあ、余り使い途を思いつかないので、今後は機能拡張されたら面白いか ? という感じです。

Sentaro さんのコメント...

akatuki様、こんにちは!

>仰るように、不可解な所で出くわすのですヨ。
>ちょっと研究してみると面白そうですね、コレは。

エラーの箇所をちゃんと示してくれないのはもはやバグとしか思えない挙動ですよね(^^;
普通のプログラムだとエラー気にしないでどんどん書いていけるんですけど、CASプログラムはまだまだ謎が多いです。


>このクロスハッチ、結構面白そうなもので、プラグマなんて機能もありました。
>今の所(?)、小数点と行末、区切り文字の指定と、整数のサイズ(32/64 bit?)を規定するという機能があるみたいです。

これは全然知りませんでした(^^;
公式に文書化されてない隠し機能が少なからず存在してそうですね。

akatuki さんのコメント...

Sentaro 様、こんばんは !

> エラーの箇所をちゃんと示してくれないのはもはやバグとしか思えない挙動ですよね(^^;
> 普通のプログラムだとエラー気にしないでどんどん書いていけるんですけど、CASプログラムはまだまだ謎が多いです。

Sentaro 様も、そういう感触ですか !
ウーム。CASの方はこなれていない、のかなぁ ?

> 公式に文書化されてない隠し機能が少なからず存在してそうですね。

アップデートで機能が付加されていく様な所もあり、今後の展開も面白い事になればイイですね。

«最後 ‹次   201 – 245 / 245   前› 最新»