[ruby-dev:6400] Re: Bigfloat [compare to NaN]

えぐち＠エスアンドイー％徳山出張中 です。

GOTO Kentaro wrote:
> 
> ごとけんです
> 
> In message "[ruby-dev:6362] Re: Bigfloat [compare to NaN]"
>     on 99/03/16, EGUCHI Osamu <[e-mail]> writes:
> 
> >えぐち＠エスアンドイー％徳山出張中 です。
> 
> 出先からも参加なさる熱意に敬意を表します(^^;;

ただの現実逃避という説も ,,,,^^;;;;;

> >たとえば、
> >
> >   f = "x" + "y" + "a" + "b"
> >   f.replace!({"x", 1},{"y",2})
> >   puts f
> >=> 3 + a + b
> >
> >といった置換系を考えています。
> >（これを関数と呼べるかは別として、 ;-p）
> >
> >式の変形も
> >
> > f.replace!({1-a**2, (1+a)*(1-a)})
> >
> >の様に出来ないかと考えています。
> >この場合、仮引数 a を任意の式にマッチさせる
> >表現手段が必要になってしまい、実現できていません。 ^^;;;
> 
> どこまで楽しむかの問題なのかも知れませんが，実用性を
> 考えるなら，ユーザーインターフェイスと評価系をそれぞれ
> つくっていく方がやはり自然な気がします．それで，その後で

大筋そのとおりだと思います。
ともあれ、Ruby の Parser を流用する事で、
かなり見た目に高度な解析（演算子の強さ、畳み込みなど）
が出来てし合う事が解ったので、楽しみ方面に走って染ましました。^^;;

> ユーティリティ的に上のような小道具を用意した方がよいかと．
> 折衷的な方法は考える局面が多すぎるのではないでしょうか??
> また上の様な方針だと評価のタイミングを完全には設計できない
> のもつらいと思います．

そうですね、実際に文字列を受け取って、それを
式の内部表現に変換するのを設計するのは結構面倒ですが、
やはり、地道に設計するのが早道ですね。

> >この方法の最大の難点は、
> >Ruby らしくないという事です。 ^^;;;
> >＃どうみても OO じゃない ！
> 
> 内部的には演算子に基づいた Ruby の表現を用いるのではなく，
> 型をクラスとして表現していく方がいいんではないでしょうか??
> Scanner はユーザーインターフェイスの問題として扱えばよいし，
> 内部モデルの記述はRubyで書く以上，自然にOO風味になっていく
> のではないかと．

ですね、
	ユーザインタフェース
	字句解析
	文法解析
	式の正規化
	恒常式の combine
	表示・可視化

の機能分類まで考えてますが、
助走で勢いつけないと、失速しそう ^^;;

	えぐち