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

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

>>> On Sat, 20 Feb 1999 18:24:59 +0900, [e-mail] (石塚圭樹 ) said:

keiju> けいじゅ＠日本ラショナルソフトウェアです.
keiju> 
keiju> In [ruby-dev :5371 ] the message: "[ruby-dev:5371] Re: compare to NaN
keiju> (Re: Re: call for finite/isnan testers) ", on Feb/20 01:26(JST) EGUCHI
keiju> Osamu writes:
keiju> 
keiju> >えぐち＠エスアンドイー です。
keiju> 
keiju> >keiju> >たしかに、あれだけ単純な構文で、表現力は異様なまでに強力ですね。
keiju> >keiju> >でも、なぜか lisp で考える事ができるようになれないんだなぁ。
keiju> >keiju> >＃育ちの問題？
keiju> >keiju> 
keiju> >keiju> ですかね. 私はアセンブラの次はlispでしたので, そんなに嫌いじゃないです.
keiju> >
keiju> >私の場合は、アセンブラの次は、、
keiju> >マイクロコードでした ^^;;;;
keiju> >んでも、lisp きらいじゃないですよ。(^^)
keiju> 
keiju> マイクロコード... Lispマシンってことはないですよね(^^;;;

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

keiju> >keiju> 一応. Rationalも正規化(約分)しますので. そうはならないんですね...
keiju> >
keiju> >約分のコストって、どうなんでしゅうか？
keiju> 
keiju> ユークリッドの互除法を使うのでそんなにコストはかからないと思います. そ
keiju> れよりも, 分母が巨大になっていく方が問題になるんじゃないかしら?

う、アルゴリズム事典読んでから書かなかったのがバレバレ^^;;;;

keiju> >『素数表を用意しておけば、最大公約数の計算中の
keiju> >除数の候補を絞れるだろうな』
keiju> >ぐらいは思いつきますが、分子か分母が Bignum だったりすると、
keiju> >さすがに重かろうと、、、あぁ、そのために約分するんだった。^^;;;
keiju> 
keiju> こんな感じです:
keiju> 
keiju> class Integer
keiju>   def gcd(int)
keiju>     a = self.abs
keiju>     b = int.abs
keiju>   
keiju>     a, b = b, a if a < b
keiju>   
keiju>     while b != 0
keiju>       void, a = a.divmod(b)
keiju>       a, b = b, a
keiju>     end
keiju>     return a
keiju>   end
keiju> end
keiju> 
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> >keiju> >最終的な表現形式の問題でないのであれば、
keiju> >keiju> >わたしも Ratinal * Float -> Rational に賛成です。
keiju> >keiju> うーん....
keiju> >
keiju> >この辺り、私が Fortran や C の型変換規則に
keiju> >ドップリつかってるせいで、自分がそう考えていると
keiju> >錯覚してるのかなぁ？
keiju> 
keiju> Fortran/CにはFraction/Rationalってないですしね... そこからどっちのモデ
keiju> ルにでも拡張できると思いますよ.

ていうか、桁溢れ恐怖症なのかも知れません。^^)l

keiju> >けいじゅさんの御意見だと、
keiju> >
keiju> >  Ratinal * Float -> Rational 
keiju> >
keiju> >が望みなら
keiju> >
keiju> >  Ratinal * Rational(Float) -> Rational 
keiju> >
keiju> >と明示的にキャストすれば良いじゃないか！
keiju> >
keiju> >って事ですか？
keiju> 
keiju> そうですね. とうぜんですが, それならOKです.
keiju> 
keiju> 1.0って書かれた時に, 機械ではそれがどれほどのものか判断できないですよ
keiju> ね? 明示的にこいつは実は 正確に1何だぞと宣言してもらう分にはいいんです.

1.0 と書いた人意外には、判らないですね。
1.000 と書いたらどうかと言うのは、別の議論ですが、、

parser に手を入れない限り、Fixnum/Bignum/Float 以外は
リテラルとしては読めないので、

	型(数値), 型.new(数値), 型(数値, 精度)

等の関数風味の形式になると思うんですが、この
フォームの枠組みで、精度の指定もユーザが自然に一貫して
コード上に表現したいですね。

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

異なる型間の演算は、どちらの型に合わせてから行なうか？
と言う議論で、既に汚れた値を保持していると思われる側に
合わせる必要はないと言う部分についてです。
＃変な書き方で失礼しました。 _o_

C で double + float を行なった時に float を double に
暗黙の型変換する理由は「そうすれば、その値は不変であるから」
なわけで、値が不変な方向への型の整合を取ると言う観点から、
の私は主張しているわけです。
これは、多くの言語に共通の態度だと思います。
＃だから正しいとは主張しませんが ^^;;;;

keiju> >それは正しいと思う、、、でも、感覚が受け入れてくれない、、
keiju> 
keiju> 原さんのメイルにもあるように, Integer/RationalとFloat系は全然違うもの
keiju> なんですね. 感覚的には, 
keiju> 
keiju>   Fixnum <=> Bignum <=> Rational => Float
keiju>   |<------正確な値の世界----->|    |<-近似値の世界----
keiju> 
keiju> って感じですね.

こう書いて頂くと、

 + 近似の近さ
 + 表現可能な範囲

の２つの違いが良く見えますね。
{ { Fixnum, Bignum, Rational } { Float, Bigfloat } { Complex, Matrix } }

の様な、３つの集合にわかれますね。
便宜上、この３つに名前を付けて。クラスとして括って
インターフェースを提供するって事が考えられますね。

keiju> >有効数字としての精度と、表現可能範囲としての精度の
keiju> >両面について Bigfloat に過度な期待を持っています。
keiju> >しかし同時にこれは、Bigfloat とて、有限の有効数字と
keiju> >有限の表現範囲を持たざるを得ないと言う事で、
keiju> >最大限に努力しても、Rational を(精度的には)越えられない
keiju> >というジレンマがあります。
keiju> 
keiju> ですね. でも, それは四則演算の世界だけであって, 関数の世界ではBigfloat
keiju> がNo1ですから, 私も期待して待っています(^^;;;

それは、関数ライブラリが欲しいと言う事ですね。
思うに、四則以外のいわゆる関数は、多くの場合 Bigfloat 固有でなく、
アルゴリズムの実現ですので、 Float 向けに書いたものでも、

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

keiju> >keiju> >式の木構造を、そのまま記憶するクラスなんてどうでしょうか？
keiju> >keiju> 昔提案したんですが, 完全に却下されました(^^;;;
keiju> >
keiju> >あ、そうでした？
keiju> >記憶にないなぁ、(だいぶ昔ですか？)
keiju> 
keiju> MLF(meta level future)の提案の初期段階だと思いました. 
keiju> 
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> >ますまてぃか って、そうしてると思ってました。
keiju> >keiju> >交換則で樹を変形させて、定理／公式のＤＢと照合してるのかと、、
keiju> >keiju> ふーん. どうなんでしょうね...
keiju> >
keiju> >中の仕組みを、想像するとワクワクしませんか？
keiju> 
keiju> ですね(^^;;; でも, 今はパターンマッチとかではなくて, 代数的に演算して
keiju> いるみたいですが...
keiju> 
keiju> 知っているのは積分のことだけですが, 昔はパターンマッチが主流だったけど, 
keiju> 最近は変わってきていると聞いた覚えがあります.

私は、実際の処理系に殆んど触れた事がないので、もとより
想像するしかないですが、チェスの終盤の総当たり戦の
イメージでした。

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

絶対、そう思います (^^)

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

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

ただ、mod_ruby なスレッドでも、構文拡張的な eRuby が
話題となっていたので、構文／文法の次元では eRuby も
数理解析も同じだと思います。

eRuby が出来たら真似しよっと(、、てのはだめ？)

	えぐち