From: Masaaki Sakano Date: 2004-04-15T13:27:44+09:00 Subject: [ruby-list:39553] Re: int/int in Ruby2? 坂野 正明です。 議論が結構盛り上がっていて、嬉しく思います。 一点。現在の Ruby の仕様の理解が十分でない場合がしばしばありそうに 拝見しました。 # つまり、それくらい、「/」は一般的なのに、.quo とかはなかなか一般的 # にならない(導入されたのが比較的最近なのも大きな理由でしょうけど)… # というわけで、やはり「/」の挙動は重要ポイント、Ruby2 で変えられる # ものなら…、という意を強くしたものでありますが。 拙投稿で恐縮ですが、[ruby-list:39453] に現在の仕様のポイントを簡単に まとめてありますので、必要でしたら御参照下さい。 必須キーワードは、 ・rational ・mathn ・quo ・div (divmod も参考に) 辺りでしょうか。 気になるのは、整数への「/」で、C言語との"一致"を言う人を散見しますが、 現在、Ruby の「/」とC言語の「/」との挙動は"異なります" (似ていますけど)。 [ruby-list:39484] で私の意見のまとめとして、 int/int => rational と書いていますが、この表現は多少、誤解を招く部分があったかも知れません。 表現したかったのは、 rational/rational => rational が原則とし、分子、分母、結果いずれも、当たりが出れば Integer (Fixnum/Bignum) になり得るという形になりましょうか。 6/2 => 3 (分子、分母、結果とも Fixnum) 6/(3分の2) => 9 (分子、結果が Fixnum、分母は Rational) (2分の3)/(3分の2) => 1 (分子、分母が Fixnum、結果は Rational) (2分の3)/(7分の2) => (3分の7) (分子、分母、結果とも Rational) 要するに、現在、mathn を require した時の挙動そのものですが。 この利点については、[ruby-list:39484] で私見をまとめておりますので、 ここで再度述べることは避けます。 このように「/」を除算にすることで、Polymorphic な状態に(Rational 以下の範囲内で)最も近くなりそうですね ([ruby-list:39473] [ruby-list:39484])。 # Polymorphism (ポリモルフィズム) は、Ruby本(まつもと/石塚; アスキー)で # 「動的結合」(4.1章)と訳されているもの。メッセージ(演算)を送る際に、 # データ型を意識しなくて良い、という概念、と理解しています。 なお、もちろんこれとは少し異なって、Rational というクラスを厳然と Integer とは異なったものとしてユーザーに意識させる仕様も一つの考え方 でしょう。現在、rational のみを require した時の挙動です。 (私は mathn 仕様の方が優れていると感じますが、あえて考えますに)その 場合でも、そんなに困ることはないように思います。弊害は、 「Integer === foo」のような書き方をしている場合でしょうか(ご存知の ように、これは、Ruby ではあまり推奨されていない書き方のようですが)。 これ以外の困る場合は、結局、「/」が整除でないと困る場合、と 同じことになりましょうか。具体的には、[ruby-list:39484] で私見を 述べております --- 十分かどうかは皆様の御判断を仰ぐとして。 別の場所で議論していて気付いたことですが、integer (クラスの オブジェクト)の演算だから結果も integer で自然という意見を見ました。 これは説得力を感じませんでした。というのも、現在でも、 bignum/bignum => fixnum というように、クラスが変わる例はいくらでもあります。あるいは、 仮に Fixnum クラスの下に偶数クラス、奇数クラスというのを定義して みた場合を考えてみてはどうでしょう。 奇数 + 奇数 => 奇数(!) なんて仕様にしたとすると、かなり奇妙に感じます。 他はいざ知らず、数の演算の場合は、クラスを強くは意識せずともシーム レスにつながっていた方が、驚かなくて済みましょう。 今回の議論で、私が最も説得力を感じた表現は、藤高さんの ↓ でした。 | Subject: [ruby-list:39530] Re: int/int in Ruby2? | Message-Id: <20040410124125.FBD4.FUJITAKA@kt.rim.or.jp> | 長い目でみたら人間の思考コストは軽減される気がします。 | Rubyでは思考コストを追求し、 そう、思考コストを問題にしたいですね。長い目で見た時の。 ----- さて、以下は余談です。本題から離れますので、興味のある方だけ。 [ruby-list:39552] At Thu, 15 Apr 2004 10:23:41 +0900, wrote: > In message > on Mon, 12 Apr 2004 17:34:41 +0900, > Itou-T15@mail.dnp.co.jp wrote: > > 手計算に一致する、でしょうか？ > > > > たぶん内容的には、十分な桁数の１０進演算あたりかな > > 小数部が長い時は切り捨てられてもしょうがない。 > > そうでないときは数学と一致。 > こういう計算を行う電卓のようなアプリケーションはあってもよいかもしれま > せん。しかし、数値演算一般に適用するには曖昧で、実装も使い勝手も悪いで > しょう。 「小数部が長い時は『切り捨て』」たりすると、曖昧になり得ますが、 通常のリテラルの数字は(切り捨てなしに)正確に rational (integer も含む) として扱うなら、曖昧にはなり得ないと思います。 1.5 とあれば 3/2 (2分の3) になるだけですから。 # 1.5e2 とあれば、150 になるだけですね。指数表記のリテラルも # rational として扱うかどうかは別問題として。 実装も複雑とは思えません。感じとしては、たとえば、[ruby-list:35966] を、コアの部分として使えばいいわけです。パーサーが数字と判断した 部分の文字数を桁数(の保守的な見積り)として渡してやる、と。 # [ruby-list:35966] は、Float-to-Rational なので、実際は完全に # 同じわけではありませんが。 使い勝手も、ほとんどいいことばかりだと思いますが。 悪くなることは、 ・速度が落ちる → Float にすればいいだけですね。 Float用のリテラルを用意するのが一番スマートでしょうか。 Float() などで変換してもいいわけですが。 ・(リテラルを書く必要が出ることで)Float 数字を書き込む手間が増える → 思考コスト優先の Ruby で、Float をどうしても使いたい場面が そんなに多い気はしないのですが…? ・他言語のプログラムからRubyへの移植の手間が若干増える? → Float の丸め誤差まで完全に一致させたい場合はそうかも 知れませんが、そこまで必要な場合が多いかは??? いずれにせよ、それが移植のボトルネックになるとは考えにくい? ・他言語習得者がRuby屋に乗り換える時、違和感を感じる?? → Float でないと生理的に我慢できない、という場合(と速度が 必要な場合と)を除けば、習慣通り、(5.6 などと)書いて もらって問題ないでしょう。 # その"他"言語で、"5.6" と表記すれば、Floatを指すと仮定して。 くらいかと考えます。 つまり、問題にならない、と。 ただ…、"余談"と断りました通り、そういうこともできるし、それはそれで 悪くない(個人的には、いい)とは感じますが、これを Ruby2 の仕様へと 強く主張するつもりは全然ありません。 -- 坂野 正明