From: Tadayoshi Funaba Date: 2008-02-03T17:33:54+09:00 Subject: [ruby-dev:33575] Re: rational, complex and nuby > ちょっと見たところ、Enumerable#stable_sort_byがsortを使っている > ので安定でないようです。 うっかりしていました。直しておきます。ありがとうございます。 > Numeric#infinite? 同様、「Floatかどうかというのはあまり関係がな > い」という気がします。それに、truncateはRationalにも追加されてい > たりで、floorだけが不要というのはちょっと疑問を感じます。 それはどうですかね。Numeric#floor の実装は、ぜんぜん一般的な解決になっ てないんですよ。rational では、別途実装すべきです。ruby では、抽象クラ スで、プロトコルなりインターフェイスを示すということもないので、Float でしか意味のないものを Numeric に置いておく必要はないと思います。 floor だけじゃないですよ。truncate、ceil、round も同じです。 むしろ、rational や complex に不用心に継承されるといった害悪のほうが気 になります。利用者が rational をつかっていて、floor をとったら、一旦、 Float を経由して精度を落していた、なんて想像しないでしょう。 > 実装上難しいというよりは、文法の拡張になるので記法のほうが問題で > すね。あとは必要性と。(#...)では、今まではコメントだったものが有 > 効な式になってしまう点が気になります。また、二次的ですが、エディ > タが混乱するというのもうれしくない点です。 僕も最初は、別のものを考えていたのですが、変更箇所を見た瞬間に (#...) でいいや、ということになってしまいました。決断に5秒とかかっていないの で、これが最高だというつもりもありません。ただ正直そんなに悪い感じもし てません。 > ちなみに、私が考えていたのは、@{...}とかです。ライブラリとして必 > 要なものは、1.9では大体準備できているので、そのうち時間が空いた > ら提案しようかとは思っていました。 文法的なことはともかく、期待しています。 > RationalやComplexの組込みは、リテラルも含めてまぁいいんじゃない > かと思うのですが、mathnはどうでしょうねぇ。少なくとも、//演算子 > にはいささか抵抗を感じます。たとえば string.split // などという > ものがsyntax errorになってしまうこととか。 まあ、簡単に ruby に採用されないようだがら、こういうものを作ってみたわ けですけど、実際には、たいした影響はないように感じています。// 自体は、 Smalltalk や Python にもあるので、新奇なものでもないですし。 文法上の課題としては、括弧のあつかいのほうがデカいので、むしろ、引数の 括弧省略を止めてもいいと思います。 とりあえず、rational と complex の組みこみ (未だあまりちゃんと組みこめ てないけど)、リテラルの導入あたりは今回の主眼だったので、そこが「まぁ いいんじゃないか」なら、十分でしょう。