[#34647] fork 不可能な環境での test_argv0_noarg — wanabe <s.wanabe@...>

ワナベと申します。

13 messages 2008/05/11
[#34667] Re: fork 不可能な環境での test_argv0_noarg — Yukihiro Matsumoto <matz@...> 2008/05/13

まつもと ゆきひろです

[#34742] Ruby 1.8.7-preview3 has been released — "Akinori MUSHA" <knu@...>

 Ruby 1.8.7-preview3 をリリースしました。

14 messages 2008/05/18
[#34744] Re: [ruby-list:44957] Ruby 1.8.7-preview3 has been released — Takahiro Kambe <taca@...> 2008/05/19

お疲れ様です。

[#34800] Windows2000上でtrunkがビルドできない — KIMURA Koichi <kimura.koichi@...>

木村です。

18 messages 2008/05/22
[#34801] Re: Windows2000上でtrunkがビルドできない — "U.Nakamura" <usa@...> 2008/05/22

こんにちは、なかむら(う)です。

[#34824] Re: Windows2000上でtrunkがビルドできない — KIMURA Koichi <kimura.koichi@...> 2008/05/23

木村です。

[#34850] Re: Windows2000上でtrunkがビルドできない — KIMURA Koichi <kimura.koichi@...> 2008/05/26

木村です。

[#34854] Re: Windows2000上でtrunkがビルドできない — "U.Nakamura" <usa@...> 2008/05/26

こんにちは、なかむら(う)です。

[#34889] Ruby 1.8.7-preview4 test-all failed in OpenSSL::TestSSL — Nobuhiro IMAI <nov@...>

いまいです。

10 messages 2008/05/29

[ruby-dev:34600] Re: ComplexFloat

From: Yukihiro Matsumoto <matz@...>
Date: 2008-05-07 13:21:26 UTC
List: ruby-dev #34600
まつもと ゆきひろです

In message "Re: [ruby-dev:34599] Re: ComplexFloat"
    on Wed, 7 May 2008 17:55:58 +0900, Shin-ichiro HARA <sinara@blade.nagaokaut.ac.jp> writes:

|まつもとさんが ComplexFloat を却下したい意向を表明して、もや
|はそれを覆すだけの説得力を持つ論拠がみつからないので、一応こ
|のスレッドは終わったと思います。

そうなんですか?

|が、ほとんど残務処理(敗戦処理?)ですが、ある程度誤解は解い
|ておきたいので、もうちょっとだけ。

|> * Complex.newの存在は純粋に互換性だけが理由だと考えています。
|>   ですから、Complex.newの存在はなんの根拠にならないと思います。
|>   いっそComplex.newを削ってもよいでしょう。
|
|ComplexFloat の話と Complex.new は関係ないです。 Complex.new
|の存在を根拠に何かを主張したはずはないんだけれど、書き方が紛
|らわしかったんだろうなあ。

そうですね。では、Complex.newは関係ないということで。

|> * Floatを成分として持つComplexとComplexFloatが挙動を含めて等
|>   しいものであるのにもかかわらずComplexFloatとComplexの両方
|>   があった方が良い理由として、
|> 
|>   (a) Complexの用法としてComplexFloatがほとんどであろうと推
|>       測される
|> 
|>   (b) 挙動がクラスで決まる、というのはよいことではないかと考
|>       える
|> 
|>   の2点があげられていますが、
|
|これは、「ComplexFloatとComplexの両方があった方が良い理由」では
|なくて、「ComplexFloatがあった方が良い理由」です。

でも、「両方あった方がよい」と思ってるんですよね。その辺がよ
くわからない。

|>   の2点があげられていますが、前提から考えて(どうせ同じ挙動な
|>   んだから)Complexの用法としてFloat成分がほとんどであろうがな
|>   かろうが、ComplexFloatを分離する根拠にはならないと思います。
|
|これは、f() を関数なり操作なり(= 挙動)とするとき、
|
|  (c) Float 成分の Complex である x と、それと等しい
|      ComplexFloat の y に対して f(x) と f(y) は等しい
|
|ので、y の方はいらないんじゃないか、ということですよね。(c)は
|その通りです。

そこは共有してるんですね。よかった。

|f() を関数なり操作なりとするとき、
|
|  (d) Complex である x と、それと等しい Complex の y に対して
|      f(x) と f(y) が等しくない
|
|ということがあり、これを問題にしました。
|
|くどいですが、もう一度言うと、(a) を ComplexFloat を分離する
|直接の根拠としたのではなく、(d) を Complex の欠点と指摘し、そ
|の欠点が無い ComplxFloat を組み込みとして導入する根拠とした。
|一方、Complex 利用者の多くは ComplexFloat があるのならそちら
|を利用するようになるだろう。その根拠が (a) です。
|
|ところで、ケース (d) が発生数する頻度も多くありません。こちら
|は頻度が少なくても問題であると考えました。(問題になる例として、
|すぐ思い浮かぶのは、行列の階数や行列式の話なのですが、分かり
|やすくないわりには説得力が十分とは言えないので、結局説明を断
|念しました。)

で、ここが重要です。まず確認ですが(d)のようなケースがあるん
ですね。私には「行列の階数や行列式の話」はわからないので、こ
こでは「ある」と仮定して話を進めます。

そのようなケースがあるとして、それは本質的に解決不能なんでしょ
うか。おそらくはそうなんでしょうね。しかし、頻度はあまり多く
なく、わかりやすくなく、説得力も十分ではないと。ふむ。

ここに説得力があり、問題が具体的であれば、それを解決するため
のアイディアが無いかみんなで知恵を絞る余地はあると思うのです
が、当の本人があきらめているようだしなあ。

|> 確かに数値クラス群はRubyの中では例外的にクラスが意味を持つ傾
|> 向がありますが、絶対視する必要はないように思うのです。
|
|確かにその通り、私は Ruby というプログラミング言語全体のバラ
|ンスを考える以上にこの性質を絶対視し過ぎていたかもしれません。
|
|これについては自己批判すると、最初 Ruby を見たとき、クラスが
|いわゆる「群・環・体」などの「代数系」を表現しているように見
|えていたく感激した、その感激を引きずっていたように思います。
|「そういうアナロジーも使えることがあります」程度に考えるべき
|でした。

だとするとそれはSmalltalkと石塚さんのおかげでしょう。私はい
まだに「群・環・体」などの「代数系」をまったく理解していませ
んです、はい。

                                まつもと ゆきひろ /:|)

In This Thread