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

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

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

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

>keiju> >たしかに、あれだけ単純な構文で、表現力は異様なまでに強力ですね。
>keiju> >でも、なぜか lisp で考える事ができるようになれないんだなぁ。
>keiju> >＃育ちの問題？
>keiju> 
>keiju> ですかね. 私はアセンブラの次はlispでしたので, そんなに嫌いじゃないです.
>
>私の場合は、アセンブラの次は、、
>マイクロコードでした ^^;;;;
>んでも、lisp きらいじゃないですよ。(^^)

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

>keiju> 一応. Rationalも正規化(約分)しますので. そうはならないんですね...
>
>約分のコストって、どうなんでしゅうか？

ユークリッドの互除法を使うのでそんなにコストはかからないと思います. そ
れよりも, 分母が巨大になっていく方が問題になるんじゃないかしら?

>『素数表を用意しておけば、最大公約数の計算中の
>除数の候補を絞れるだろうな』
>ぐらいは思いつきますが、分子か分母が Bignum だったりすると、
>さすがに重かろうと、、、あぁ、そのために約分するんだった。^^;;;

こんな感じです:

class Integer
  def gcd(int)
    a = self.abs
    b = int.abs
  
    a, b = b, a if a < b
  
    while b != 0
      void, a = a.divmod(b)
      a, b = b, a
    end
    return a
  end
end

コストがかかるのは, whileループですが, 小さい数で大きい数をdivmodしつ
づけるだけですから, ループの数はそんなに大きくないかと...

>keiju> >最終的な表現形式の問題でないのであれば、
>keiju> >わたしも Ratinal * Float -> Rational に賛成です。
>keiju> うーん....
>
>この辺り、私が Fortran や C の型変換規則に
>ドップリつかってるせいで、自分がそう考えていると
>錯覚してるのかなぁ？

Fortran/CにはFraction/Rationalってないですしね... そこからどっちのモデ
ルにでも拡張できると思いますよ.

>けいじゅさんの御意見だと、
>
>  Ratinal * Float -> Rational 
>
>が望みなら
>
>  Ratinal * Rational(Float) -> Rational 
>
>と明示的にキャストすれば良いじゃないか！
>
>って事ですか？

そうですね. とうぜんですが, それならOKです.

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

>その上で、
>『でも、そんな事しても、精度が向上するわけじゃないよ！』
>と言った事でしょうか。

??

>それは正しいと思う、、、でも、感覚が受け入れてくれない、、

原さんのメイルにもあるように, Integer/RationalとFloat系は全然違うもの
なんですね. 感覚的には, 

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

って感じですね.

>有効数字としての精度と、表現可能範囲としての精度の
>両面について Bigfloat に過度な期待を持っています。
>しかし同時にこれは、Bigfloat とて、有限の有効数字と
>有限の表現範囲を持たざるを得ないと言う事で、
>最大限に努力しても、Rational を(精度的には)越えられない
>というジレンマがあります。

ですね. でも, それは四則演算の世界だけであって, 関数の世界ではBigfloat
がNo1ですから, 私も期待して待っています(^^;;;

>keiju> >式の木構造を、そのまま記憶するクラスなんてどうでしょうか？
>keiju> 昔提案したんですが, 完全に却下されました(^^;;;
>
>あ、そうでした？
>記憶にないなぁ、(だいぶ昔ですか？)

MLF(meta level future)の提案の初期段階だと思いました. 

>  a = Expr("PI / 4")
>  puts a		=>   0.7853981634
>  puts a.inspect	=>   Expr(PI/4)
>  puts a.sin!		=>   0.7071067812
>  puts a.inspect	=>   Expr(sin(PI/4))
>  puts a += 2		=>   2.7071067812
>  puts a.inspect	=>   Expr(sin(PI/4)+2)
>  puts a -= 2		=>   0.7071067812
>  puts a.inspect	=>   Expr(sin(PI/4))
>
>なんてカッコ良いと思うんですけど。。。

うーん...

>難点は、既存の演算子の中に馴染んでくれないので、
>文字列で式を与える方法が、多用されそうだと言う事でしょう。
>そうすると、外観上 eval() と酷似する事になりそうです。
>、、そうか、それでいいんだ、 ruby の node をユーザが定義する方法が
>出来るだけで良いのか、、うぅん、気分的には行けそうなんだけど、、

私のイメージは, 構文木を直接操作するイメージでした.

>keiju> >ますまてぃか って、そうしてると思ってました。
>keiju> >交換則で樹を変形させて、定理／公式のＤＢと照合してるのかと、、
>keiju> ふーん. どうなんでしょうね...
>
>中の仕組みを、想像するとワクワクしませんか？

ですね(^^;;; でも, 今はパターンマッチとかではなくて, 代数的に演算して
いるみたいですが...

知っているのは積分のことだけですが, 昔はパターンマッチが主流だったけど, 
最近は変わってきていると聞いた覚えがあります.

# きっと, このMLの中にも詳しい人がいるのでは??

>keiju> >誰か作りませんか？
>keiju> 何か作ってみたいなあって思ったことはあります.
>keiju> # 作るとはいっていません(^^;;;
>
>スクリプティング向き言語の枠から、はみ出しそうな気はしますが、
>数学の問題にこれだけ熱くなるところをみると、
>しっかりとした物であれば、需要は充分ありそうですね。^^;;

喜ぶ人は多いでしょう(^^;;;

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