[#34194] File.read (または String#include?) でSEGV — wanabe <s.wanabe@...>
ワナベと申します。
[#34200] Resolv.getaddress がエラーになる — "Kouhei Yanagita" <yanagi@...>
柳田です。
[#34239] MVM interface draft — Nobuyoshi Nakada <nobu@...>
なかだです。
[#34261] ComplexFloat — "Kenta Murata" <muraken@...>
村田です.
村田です.
なかだです。
むらたです.
こんにちは、なかむら(う)です。
むらたです.
こんにちは、なかむら(う)です。
むらたです.
In article <761216ce0804100221x67f10f12iab12b0e35b6f50e4@mail.gmail.com>,
むらたです.
まつもと ゆきひろです
利点としては、拡張ライブラリが書きやすい、ということ。正当化の理由とし
むらたです.
> 私にはいびつな進化という感じはしません.むしろ,せっかく C で実装できるのに
むらたです.
まつもと ゆきひろです
むらたです.
まつもと ゆきひろです
むらたです.
まつもと ゆきひろです
むらたです.
In article <761216ce0804120723n16bfbad7qdae90f142978d256@mail.gmail.com>,
むらたです.
In article <761216ce0804121011h6132d58fh4916ecbb29d58690@mail.gmail.com>,
むらたです.
In article <761216ce0804121039l605a8ec6sebe52afdbbb52160@mail.gmail.com>,
むらたです.
まつもと ゆきひろです
むらたです.
まつもと ゆきひろです
むらたです.
原です。
まつもと ゆきひろです
遠藤と申します。
原です。
In article <4808653F.80607@blade.nagaokaut.ac.jp>,
原です。
> 1. ComplexFloat を組込みにし、Complex を標準ライブラリとして提供する。
原です。
> 分かりににくかったですが、これは、ComplexFloat を含めた組込みの数体系が
こんばんは sheepman です。
まつもと ゆきひろです
けいじゅ@いしつかです.
まつもと ゆきひろです
けいじゅ@いしつかです.
まつもと ゆきひろです
けいじゅ@いしつかです.
原です。
けいじゅ@いしつかです.
Complex と ComplexFloat とクラスをふたつに分ける理由がどうに
原です。
まつもと ゆきひろです
原です。
[#34266] Ruby1.9 での $SAFE==4 時の autoload 動作 — Hidetoshi NAGAI <nagai@...>
永井@知能.九工大です.
[#34272] patch for [ruby-core:14537] — wanabe <s.wanabe@...>
ワナベと申します。
[#34278] Re: [ruby-cvs:23187] Ruby:r15947 (trunk): * lib/generator.rb: removed obsolete library. [ruby-core:16233] — SASADA Koichi <ko1@...>
ささだです.
まつもと ゆきひろです
[#34285] Complex#scalar? returns false — "Kenta Murata" <muraken@...>
むらたです.
[#34313] Enumerable#find_index vs. Array#index — "Akinori MUSHA" <knu@...>
[ruby-talk:178495] が発端で Enumerable#find_index というのが
まつもと ゆきひろです
[#34352] patch for — wanabe <s.wanabe@...>
ワナベと申します。
[#34391] Preparing for 1.8.7-preview1 — "Akinori MUSHA" <knu@...>
延び延びになってしまいましたが、ようやく enumerator 関連、
[#34393] fluent comma — "Yusuke ENDOH" <mame@...>
遠藤と申します。
[#34402] OpenSSL::SSL::SSLContext#set_params — Kazuhiro NISHIYAMA <zn@...>
西山和広です。
[#34430] str_new() may create broken string — wanabe <s.wanabe@...>
ワナベと申します。
[#34460] patch for ruby-dev:34236 — wanabe <s.wanabe@...>
ワナベと申します。
[#34476] coerce with Rational and Complex — "Yusuke ENDOH" <mame@...>
遠藤と申します。
[#34512] [ruby-core:16238]の検証 — Yukihiro Matsumoto <matz@...>
まつもと ゆきひろです
[#34515] M17N のリファレンス — sheepman <sh@...>
こんにちは sheepman です。
[#34540] 0**-1 == 0 ? — Yukihiro Matsumoto <matz@...>
まつもと ゆきひろです
ささだです。
[ruby-dev:34546] Re: ComplexFloat
まつもと ゆきひろです
In message "Re: [ruby-dev:34541] Re: ComplexFloat"
on Wed, 30 Apr 2008 18:50:06 +0900, Shin-ichiro HARA <sinara@blade.nagaokaut.ac.jp> writes:
|Tanaka Akira さんは書きました:
|> Complex と ComplexFloat とクラスをふたつに分ける理由がどうに
|> もわかりません。
|
|その理由こそちゃんと述べないといけないのですが、なかなか伝わ
|らないですね。うまく表現ができてないみたいです。一応答えるこ
|とができるところだけ答えます。
何度か読み返したのですが、やっぱりよくわかりません。
* Complex.newの存在は純粋に互換性だけが理由だと考えています。
ですから、Complex.newの存在はなんの根拠にならないと思います。
いっそComplex.newを削ってもよいでしょう。
* Floatを成分として持つComplexとComplexFloatが挙動を含めて等
しいものであるのにもかかわらずComplexFloatとComplexの両方
があった方が良い理由として、
(a) Complexの用法としてComplexFloatがほとんどであろうと推
測される
(b) 挙動がクラスで決まる、というのはよいことではないかと考
える
の2点があげられていますが、前提から考えて(どうせ同じ挙動な
んだから)Complexの用法としてFloat成分がほとんどであろうがな
かろうが、ComplexFloatを分離する根拠にはならないと思います。
「現行の組み込みの数値クラスはすべてクラスで決まっている」
とありますが、たとえばFixnumとBignumは本当は同じIntegerクラ
スにしたかったのが、一方が即値であるためにできなかったとい
う「私の思い」があり、「設計者がしたいのにできなかった」こ
とをもって「よいこと」と断じられるのは不本意です。
また、「数値クラスという単純であるべき」とありますが、
Complexというクラスひとつを導入するのとComplexFloatを代表す
る多数の「Complex族」を導入したり、あるいはComplexFloatとほ
ぼ同じ動作を内包するようなComplexクラスを並立させたりするこ
とは、成分ごとに挙動が多少変化するComplexよりも複雑に(私に
は)感じます。
という点から、さほど確たる根拠は感じられなかったのですが。複
素数とはそういうものだ、とかそういう話にはならないのですね
(それなら少なくとも私には口出しできない)。
|Complex() に Float を与えると、ComplexFloat と同じ挙動をする
|オブジェクトが得られます。同じような振舞いをするオブジェクト
|が2通りあることになりますね。あまり良くないが仕方がない、とい
|う考えです。最大の欠点?
|
|誰かが ComplexInteger を作ったとすれば、やはり Complex() に
|Integer を与えたものと2重になってしまうでしょう。
「しかたがない」というからには、「しかたがない」だけの理由が
あるんだと思うんですが、上記のようにそんなに「しかたがない」
とは感じませんでした。「単純であるべき」の「単純」はかなり主
観的ですし、「クラスで決まっている」というのもそこまで重要視
すべき性質であるとは感じませんでした。
|exact? と inexact? の導入は検討されてもいいと思います。しかし
|数の挙動を表現する情報としては不十分なわけで(例えば Rational
|と Integer は exact だけど挙動はかなり違う)、そのものズバリ
|「クラスが体を表す」のはいいことではないかと思うのですが…
|数値なのにクラスで性質が判断できない、という気持ち悪さを感じ
|過ぎなのかなあ。
確かに数値クラス群はRubyの中では例外的にクラスが意味を持つ傾
向がありますが、絶対視する必要はないように思うのです。
まつもと ゆきひろ /:|)