From ruby-math-admin@ruby-lang.org Thu Aug 30 00:20:26 2001 Received: from tonton.nagaokaut.ac.jp (tonton.nagaokaut.ac.jp [133.44.2.115]) by blade.nagaokaut.ac.jp (8.8.8/8.8.8/Debian/GNU) with ESMTP id AAA10743; Thu, 30 Aug 2001 00:20:26 +0900 Received: (from root@localhost) by tonton.nagaokaut.ac.jp (8.11.3/8.11.3) id f7TFDkW73037; Thu, 30 Aug 2001 00:13:46 +0900 (JST) (envelope-from ruby-math-admin@ruby-lang.org) Received: from voscc.nagaokaut.ac.jp (voscc.nagaokaut.ac.jp [133.44.1.100]) by tonton.nagaokaut.ac.jp (8.11.3/8.11.3av) with ESMTP id f7TFDic73015; Thu, 30 Aug 2001 00:13:44 +0900 (JST) (envelope-from ruby-math-admin@ruby-lang.org) Received: from helium.ruby-lang.org (helium.ruby-lang.org [210.251.121.214]) by voscc.nagaokaut.ac.jp (8.9.3/3.7W) id AAA13270; Thu, 30 Aug 2001 00:13:43 +0900 (JST) Received: from hoyogw.ruby-lang.org (localhost [127.0.0.1]) by helium.ruby-lang.org (Postfix) with ESMTP id 5D8B63A1F; Thu, 30 Aug 2001 00:12:42 +0900 (JST) Date: Thu, 30 Aug 2001 00:11:57 +0900 From: matz@ruby-lang.org (Yukihiro Matsumoto) Reply-To: ruby-math@ruby-lang.org Subject: [ruby-math:00615] Re: int / int -> ? To: ruby-math@ruby-lang.org Message-Id: <999097917.455151.21034.nullmailer@ev.netlab.jp> In-Reply-To: =?ISO-2022-JP?B?GyRCQFBETTc9PHkbKEIncw==?= message of "Wed, 29 Aug 2001 18:56:33 +0900"<200108290956.SAA06812.keiju@ishitsuka.com> References: <998780106.552016.3455.nullmailer@ev.netlab.jp> <200108290956.SAA06812.keiju@ishitsuka.com> X-ML-Name: ruby-math X-Mail-Count: 00615 X-MLServer: fml [fml 3.0pl#17]; post only (only members can post) X-ML-Info: If you have a question, send e-mail with the body "help" (without quotes) to the address ruby-math-ctl@ruby-lang.org; help= X-Mailer: cmail 2.61+20001225 on GNU Emacs 20.7.2 / Mule 4.1 (AOI) User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/20.7 (i386-debian-linux-gnu) MULE/4.1 (AOI) Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=ISO-2022-JP Precedence: bulk Lines: 142 X-Virus-Scanned: by AMaViS perl-10 まつもと ゆきひろです In message "[ruby-math:00614] Re: int / int -> ?" on 01/08/29, 石塚圭樹 writes: |>David Alan BlackのBehaviorとかを使ってくくってもらいたいくらい。# あ、 |>それは良いアイディアかも。RAAのbehaviorを見てみてください。 | |これって、[ruby-dev:14003]で出したやつ(の一般化したもの)でしょう? ただし、 |thread safeでない && 振る舞いを変える度に文字列をevalしている ので、 |[ruby-dev:14003]のアイディア(の実装したもの)のほうが、まだよいと思います |が? だって、Behaviorは動くけどアイディアは動かないもの。動く方が 1000倍すぐれていると思います。ま、どうでも良いことですが。 |>|coerceとかはいくら使いにくいといっても、必要なことはどうにか実現可能です |>|が、今回のは互換性を維持しつつ実現するのは実質不可能なんですよね... |> |>おっしゃることが良く分かりません。「望む仕様がある(この場合 |>は int/int -> ratinal)」が、それは「互換性を維持しつつ実現す |>るのは実質不可能である」、ということまでは同意しますが、だか |>らどうしろと？ | |そういう意味ではありません。数値クラスの拡張の機能があるのはよいけど、う |まく拡張できるとは限らない。ってことです. ま、それは同意します。なかなか理想の拡張方法は見つからないも のですよね。 |例えば、Matrixは数値クラスを拡張しているわけですが、Matrix#detのようにあ |るべき仕様を実現できないようなことを言っています。 ごめん、よくわかってないのですが、detは整数の/は整除であるこ とを知っていれば解決できるのですよね。 |>まず第一に「私はRationalを実装しません」。これは確実です。私 |>はRationalについて十分に理解してませんし、バグなしに作る自信 |>も十分なパフォーマンスを出す自信もありません。Bignumでこりま |>した。 | |Rationalの実装はBignumのように難しくないです。rational.rbでやっているこ |とをCに移しかえるだけですから。つまり、分子と分母の組で実現し、実質的な |計算はIntegerの方に委譲するわけですね。ただし, パフォーマンスを考えると |gcdはこのままのアルゴリズムではまずいでしょうが。 私にとって実装が難しいか難しくないかを決めるのは石塚さんじゃ ないでしょう？ ;-) |>第二に「だれか他の人にやってもらうのには不安があります」。つ |>まり、将来のRationalはcoerceやPrecisionを含めてRubyの他の部 |>分全体との整合性をとって実現されるべき、かなり難しい問題です。 |>それができる人がいるのかどうか相当不安です。 | |そうです? その辺りはまったく心配する必要はないと思います. 本質的なアルゴ |リズムは、CであろうがRubyで書かれていようが変りませんので。 そうかなあ。現状のRationalとかはなんとなくRubyの数システムと は違うような気がしてますが、「組み込みじゃないから」というの を言い訳にして自分を納得させてます。組み込んじゃうとその言い 訳はなくなるわけですから、rational.rbをCで記述し直すレベルで はすまないと思います。しかし、ではどのように設計すれば良いの かということについて、私は決定的な意見を持てないでいるんです よね。なんとなく「違う」と感じるだけで。 こういう現状で誰かに依頼できるとは思えません。自分でさえなに を求めているのかはっきり自覚してないのに。 |>そういえば、Precisionって使われてるのかなあ。 | |これって、拡張した(精度を持つ)数値クラスのみで意味がありますからね. そう |いえば、Rationalは対応していないな... あとで、対応しておこうっと。 お願いしますね。 |>第三に、int/int -> rationalにすることによるモデルの変化の心 |>理的影響は無視できないと思ってます。つまり、今まで一応はCや |>FORTRANのような「伝統的計算機言語の数値モデル」に従ってきた |>のですが、それから離れることになるわけですよね。たとえば私は |>old type(＋数学苦手)なのでこのモデルには不安を感じます。 | |うーん. どうせ, 一般の処理では割り算なんかめったにしないんだからそんなに |気にしなくていいんじゃないの? 一般の処理では整除はするかも知れませんが? |でも, それも//を導入すればよいわけだし。 それは楽観的だなあ。非互換性をあまりに小さく見積もっているの では。この変更は * 機械的に検出できない * 戻り値の型が今までと違う という点でけっこう面倒だと思うんですが。 |それに、数値処理をしたい場合は今のままでは危険がいっぱいです。 | |たとえば、以下のメソッド: | | def mean(*numary) | sum = 0 | for n in numary | sum += n | end | sum / numary.size | end | |でさえもまともに(思った通りに)動作しない。こういう状況はかなりまずい状況 |と思いますが? | |>> mean(1,2) |=> 1 |>> mean(1.0,2.0) |=> 1.5 |>> require "mathn" |>> mean(1,2) |=> Rational(3, 2) 「思った通り」というのは主観が入っているわけで、これだけでは 十分な説得力があるとは思えませんです。「整数を与えたのだから 整数を返す(引数の方に応じて適切な戻り値を返す)」という解釈を 持つ人だってありえるわけですよね。 さらにいえば、sumを整数のゼロで初期化している時点で型に無頓 着と言われてもしょうがないと思います。Rubyは式に型こそありま せんが、型に無頓着で構わない言語ではないと思います。 def mean(*numary) sum = 0.0 for n in numary sum += n end sum / numary.size end >> mean(1,2) => 1.5 >> mean(1.0,2.0) => 1.5 >> require "mathn" >> mean(1,2) => 1.5 まつもと ゆきひろ /:|)