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

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

>>> In message [ruby-dev:5754] Re: compare to NaN (Re: Re: call for finite/isnan	 testers) 
    On Fri, 26 Feb 1999 16:57:11 +0900, [e-mail] (石塚圭樹 ) said:

keiju> けいじゅ＠日本ラショナルソフトウェアです.
keiju> 
keiju> In [ruby-dev :5723 ] the message: "[ruby-dev:5723] Re: compare to NaN
keiju> (Re: Re: call for finite/isnan testers) ", on Feb/25 22:53(JST) EGUCHI
keiju> Osamu writes:
keiju> 
keiju> >えぐち＠エスアンドイー です。
keiju> 
keiju> >keiju> >＃半田付けは、おかげでめちゃめちゃうまいです。
keiju> >keiju> そういう人も尊敬しちゃいマスです(^^;;;
keiju> >
keiju> >でも最近は、面実装なので段々赤外線で半田ペーストを
keiju> >融解する自動機が主流化して、こういう技能も段々
keiju> >廃れていくみたいです。
keiju> 
keiju> おぉ!! そんなものがあるんですね(^^;;

自動半田槽も、あと数年の命かもしれません。
いわんや手付けなんて ^^;

keiju> >ＰＣ組み立てるのに半田ゴテは不要になってしまったし、、
keiju> 
keiju> いわれてみると確かにそうですね(^^;;;

最後には Intel か Cyrix が chipset と RAM を CPU に統合して、、、

keiju> >keiju> そういう話しは何度かあったような気がしますが, 
keiju> >keiju> 何か理由があって採用されなかった覚えがないでもないです.
keiju> >
keiju> >特異メソッドや再定義が実装を困難にしてたのでは？
keiju> 
keiju> 松本氏の裏話がありましたね.

このはなし、確か私が Ruby を使いだして１カ月ぐらいの時、
まともとさんから、聞いたと思います。(おぼろげ)
他の言語と比べると、

 * 移項（式の変形）……駄目
 * ループアンローリング……駄目
 * 共通部分式の削除……駄目
 * 定数の畳み込み……駄目

と極めて厳しい状況なので、eval の細かな実装のチューニングと
GC や個々の method の性能向上が最適化の根幹をなしそうですね。
あ、あと正規表現。。

keiju> >keiju> >『代数論』って奥深いのに素人もむづかしいって事が
keiju> >keiju> >わかるのはなんでだろう。
keiju> >keiju> 私も代数苦手です. 目(頭?)で見えないものは難しい(^^;;;
keiju> >
keiju> >え゛、苦手のレベルが違うのかな？？？
keiju> >わたしは、そうすると苦手ではありません。
keiju> >最初からわかんないです ^^; ＜困った生徒の典型
keiju> 
keiju> でも, 似たようなものかも(^^;;; 原さんとかごとけんさんとかと比べたら, 
keiju> 無に等しいです.

けいじゅさんとあの方達との差は、絶対値が多きすぎてわからないです。^^;;;
＃仮数部の桁（共通の知識）が足りないもんで ^^)l

keiju> >keiju> >あぁ、可逆性以外の解釈を想像できませんでした。
keiju> >keiju> >そうかぁ、『正確』という背景を汲み取る必要あるんですね。
keiju> >keiju> >で、Float => Rational は暗黙に起こらないので、
keiju> >keiju> >「正確とみなす」を狙ったと暗示していませんか、、
keiju> >keiju> >＃そんな事はないかぁ。。
keiju> >keiju> 
keiju> >keiju> そんなことあります. 話しがコンガラがっていマスね(^^;;; 
keiju> >keiju> 
keiju> >keiju> 結局何がいいたいんでしたっけ?
keiju> >
keiju> >ちょうど、Mathmatica で 10 + 1^-32 の値が
keiju> >Rational であるということで、決着したのでは。
keiju> >うぅん、、無限精度かぁ。。
keiju> 
keiju> そういえば. Rubyでは
keiju> 
keiju>   1e10 => Float
keiju> 
keiju> ですが, Integer(Bignum)にして欲しいと思うのは私だけ? Floatにしたければ
keiju> 
keiju>   1.0e10 
keiju> 
keiju> って書く.

これに賛成一票！
ただし互換性問題が発生しませんか？
Ruby1 と Ruby2 の互換性って、どの程度を考えれば良いのだろう？？？

keiju> >あと、Bignum の性能に依存します。
keiju> >が、Ruby の Bignum の性能は悪くないので
keiju> >Rational にも勝機はあります。
keiju> 
keiju> この辺でやめましょう(^^;;;

そうですね ^^;;;

keiju> >keiju> まあそうですが, 構文木って内部構造なので何時変わるか分からないしあまり
keiju> >keiju> 表にだしたくないのでは? その内バイトコードになるかも知れないし....
keiju> >
keiju> >そのとおりですね。
keiju> >いま正規表現のように、特殊な構文で
keiju> >遅延評価式を表せないか考えています。
keiju> >
keiju> >例えば
keiju> >	% 1 + PI * 2 %
keiju> >
keiju> >の様に % で括る方法で表記して、内部的には
keiju> >
keiju> >	( + 1 ( * PI 2 ) )
keiju> >
keiju> >で保持しておくわけです。
keiju> >＃なんで lisp 風味なのだろう
keiju> 
keiju> 遅延評価というよりも式の操作を行ないたいんですよね? そうでもないのかな?
keiju> 遅延するだけならブロックを使うだけでもよいと思うんですが...

そうです。
式の操作で、

 + 畳み込みによる、無限精度を維持したままの式の簡略化
 + 公理／定理の適用(バックトラッキング機構も？)

が出来るとよろしいかと、、これはむしろ、ruby の
上のアプリケーションとしての実装がよいと思いつつあります。

keiju> >keiju> OpenC++ってそんなに動的なんですか? 全然知らないのですが...
keiju> >
keiju> >キーワードの追加は出来ますね、
keiju> >演算子の強さとかリテラルの追加までできるかは、
keiju> >読み切れてません。ごめんなさい ^^;;
keiju> 
keiju> 私も暇があったら調べてみますです. 

ruby で構文木を触りたくない／触られたくないと言う問題を
どう解決しているのか（していないのか）を観てみたいと思います。
ただ向こうはコンパイラなので事情が若干違うのだけれども。。

keiju> >keiju> >進化の過程で廃れちゃったのですね。。;_;
keiju> >keiju> 廃れてはいないんでしょう多分. reduceはまだこのタイプだったと思います.
keiju> >
keiju> >あれって lisp ですよね。
keiju> >たしか電気屋さんが、論理設計のシュミレターが
keiju> >reduce の上で動いていると言ってたけど、別人さんかな？
keiju> 
keiju> うーん. きっとそうでしょう.

このころのＰＣが遅くて、帰宅前に JOB 流してました。
そのころも夜中に(も)仕事してたので、
	『とまったら、この操作やっといて』
とか言われて、夜中の５時頃(もう朝か)ごそごそやってました。^^;;;

keiju> >映画はきれいでしたねぇ、原作はさらに重いですね。
keiju> >、、それが良いのだけれど。
keiju> 
keiju> そうなんですか...

感じ方は、それぞれですが、、
、、と言って言いすぎるとメタバラ系になってしまう ^^;;;

keiju> >keiju> # 融合といえば諸星大二郎(?)の生物都市が気持ちが良さ悪いですね(^^;;;
keiju> >あの電話を取ると、電話と融合しちゃう奴ですね。
keiju> 
keiju> あ. そうです. そうです.
keiju> 
keiju> >keiju> # あと, 映画になりますが, クローネンバーグの裸のランチも...
keiju> >これはまだみてないなぁ
keiju> 
keiju> こっちは融合するわけでもないんですけどね. 気持ちが良さ悪いという意味で
keiju> は, さらに上をいっているかなと(^^;;;

生物都市に匹敵する、 気持ちが良さ悪なんですか？
実写で？？？

	えぐち