[ruby-dev:5569] Re: compare to NaN (Re: Re: call for finite/isnan testers)

けいじゅ＠日本ラショナルソフトウェアです.

何かすごくメイルが溜っているなぁ...

In [ruby-dev :5400 ] the message: "[ruby-dev:5400] Re: compare to NaN
(Re: Re: call for finite/isnan testers) ", on Feb/20 22:50(JST) EGUCHI
Osamu writes:

>えぐち＠エスアンドイー です。

>keiju> マイクロコード... Lispマシンってことはないですよね(^^;;;

>さすがに、それはないです、^^;;
>モノは、工業用シーケンサの機械語を実行するエンジンで、TTL ロジックだけで
>組まれていました(2901 とかのビットスライス使わないで、74LS と FuseROM だけ！)
>メモリアクセスタイミング生成などもμコードのお仕事でした ^^;;;;;;;
>これでリレーシーケンスをイミュレートするわけです。

うーん. 最初っからそういう世界でしたか(^^;;; そういうお方は尊敬しちゃ
うなあ(^^;;;

>keiju> コストがかかるのは, whileループですが, 小さい数で大きい数をdivmodしつ
>keiju> づけるだけですから, ループの数はそんなに大きくないかと...
>
>そう言えば、これの再帰版の
>
>  def gcd(int)
>  return self if int == 0
>  int.gcd(self % int)
>  end
>
>ってテールリカージョンの典型で載ってますね^^;;;;;;;

確かにそっちの方がシンプルですね.

>あと、while に入る前に、
>
>  q = a | b
>  while (q & 1) == 0
>    a >>= 1
>    b >>= 1
>  end
>
>とか、、(せこ^^;)

どうなんでしょうね? 効果あるのかな??

>keiju> Fortran/CにはFraction/Rationalってないですしね... そこからどっちのモデ
>keiju> ルにでも拡張できると思いますよ.
>ていうか、桁溢れ恐怖症なのかも知れません。^^)l

確かに, Rationalにすれば桁溢れはしませんが, Bigfloatでも平気ですよ(^^;;;

>keiju> 1.0って書かれた時に, 機械ではそれがどれほどのものか判断できないですよ
>keiju> ね? 明示的にこいつは実は 正確に1何だぞと宣言してもらう分にはいいんです.
>
>1.0 と書いた人意外には、判らないですね。
>1.000 と書いたらどうかと言うのは、別の議論ですが、、

ですね.

>parser に手を入れない限り、Fixnum/Bignum/Float 以外は
>リテラルとしては読めないので、
>
>	型(数値), 型.new(数値), 型(数値, 精度)
>
>等の関数風味の形式になると思うんですが、この
>フォームの枠組みで、精度の指定もユーザが自然に一貫して
>コード上に表現したいですね。

これ別のスレッドで議論していますね. 参加して下さい(__;;;

>keiju> >その上で、
>keiju> >『でも、そんな事しても、精度が向上するわけじゃないよ！』
>keiju> >と言った事でしょうか。
>keiju> ??
>
>異なる型間の演算は、どちらの型に合わせてから行なうか？
>と言う議論で、既に汚れた値を保持していると思われる側に
>合わせる必要はないと言う部分についてです。
>＃変な書き方で失礼しました。 _o_
>
>C で double + float を行なった時に float を double に
>暗黙の型変換する理由は「そうすれば、その値は不変であるから」
>なわけで、値が不変な方向への型の整合を取ると言う観点から、
>の私は主張しているわけです。
>これは、多くの言語に共通の態度だと思います。
>＃だから正しいとは主張しませんが ^^;;;;

値っていうのが微妙ですね. 

double/floatはフォーマット上も完全上位互換になっているのでいいんですが.
Float => Rational では, 値以外にも正確な値であるという情報が付加されて
しまいます. そこが気になるんですね.

あとは, 原先生とごとけん先生のスレッドに加わって下さい.

# 恐いですけど(^^;;;

>keiju>   Fixnum <=> Bignum <=> Rational => Float
>keiju>   |<------正確な値の世界----->|    |<-近似値の世界----

>こう書いて頂くと、
>
> + 近似の近さ
> + 表現可能な範囲
>
>の２つの違いが良く見えますね。
>{ { Fixnum, Bignum, Rational } { Float, Bigfloat } { Complex, Matrix } }
>
>の様な、３つの集合にわかれますね。
>便宜上、この３つに名前を付けて。クラスとして括って
>インターフェースを提供するって事が考えられますね。

coerceの話しは当面しないとなっているので(^^;;;

>keiju> ですね. でも, それは四則演算の世界だけであって, 関数の世界ではBigfloat
>keiju> がNo1ですから, 私も期待して待っています(^^;;;
>それは、関数ライブラリが欲しいと言う事ですね。

そうですね. 四則演算だけなら正直いってRationalがあるし, Bigfloatはあま
り必要はないと思います.

>思うに、四則以外のいわゆる関数は、多くの場合 Bigfloat 固有でなく、
>アルゴリズムの実現ですので、 Float 向けに書いたものでも、

>Float(n) の箇所を self.type(n) とする程度で、上の Set の
>第二集団に適用できると思います。
>＃精度整合のメソッドが完備している必要はあるのだけれど。。

なるほど. それもいえますね. 基本的には四則演算が定義できていればどの
FlaotでもOKですしね. 色々な意味で無駄が省ける.

そういえば, Floatを抽象クラスにするって案があったけどどうなったんでしょ
う?? これもごとけんさんがやっていたかな?

確かそうだと思ったんですが, そうであればFloatのメソッドとすれば良さそ
うですね. それか, モジュールとして実装するか.

>keiju> >  a = Expr("PI / 4")
>keiju> >  puts a		=>   0.7853981634
>keiju> >  puts a.inspect	=>   Expr(PI/4)
>keiju> >  puts a.sin!		=>   0.7071067812
>keiju> >  puts a.inspect	=>   Expr(sin(PI/4))
>keiju> >  puts a += 2		=>   2.7071067812
>keiju> >  puts a.inspect	=>   Expr(sin(PI/4)+2)
>keiju> >  puts a -= 2		=>   0.7071067812
>keiju> >  puts a.inspect	=>   Expr(sin(PI/4))
>keiju> >
>keiju> >なんてカッコ良いと思うんですけど。。。
>keiju> 
>keiju> うーん...
>
>この、『うーん...』は、『変な事考えるやつだな』
>の うーん... ですか ^^)l

なんか, 文字列に足したり引いたりしているだけって感じがしたものですから
(^^;;;

>keiju> >難点は、既存の演算子の中に馴染んでくれないので、
>keiju> >文字列で式を与える方法が、多用されそうだと言う事でしょう。
>keiju> >そうすると、外観上 eval() と酷似する事になりそうです。
>keiju> >、、そうか、それでいいんだ、 ruby の node をユーザが定義する方法が
>keiju> >出来るだけで良いのか、、うぅん、気分的には行けそうなんだけど、、
>keiju> 
>keiju> 私のイメージは, 構文木を直接操作するイメージでした.
>
>あ、ruby の node って、その構文木の節の事です。
>Proc などは、かなりこれに近い気がします。

これと上の操作って違いがあるよな??

>keiju> 知っているのは積分のことだけですが, 昔はパターンマッチが主流だったけど, 
>keiju> 最近は変わってきていると聞いた覚えがあります.
>
>私は、実際の処理系に殆んど触れた事がないので、もとより
>想像するしかないですが、チェスの終盤の総当たり戦の
>イメージでした。

違うみたいですよ.

>ruby に組み込んじゃうのか、ruby に上に組むのかで
>だいぶ様子が変わって来ると思います。
>前者は大げさ、後者は効率に懸念あり。

>ただ、mod_ruby なスレッドでも、構文拡張的な eRuby が
>話題となっていたので、構文／文法の次元では eRuby も
>数理解析も同じだと思います。
>
>eRuby が出来たら真似しよっと(、、てのはだめ？)

うーん. ちょっと違うような... 

__
................................石塚 圭樹＠日本ラショナルソフトェア...
----------------------------------->> e-mail: [e-mail] <<---