[#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:34322] Re: ComplexFloat
まつもと ゆきひろです
In message "Re: [ruby-dev:34318] Re: ComplexFloat"
on Fri, 11 Apr 2008 02:30:58 +0900, "Kenta Murata" <muraken@gmail.com> writes:
|だとすると,ふなばさんは私の提案の何に対して「いびつ」であると
|お感じになっているのでしょうか?そこがまだ理解できていないので
|教えてください.
「早すぎる最適化」を懸念しておられる気がします。私としては村
田さんの主眼が読み切れてないので保留します。
* 機能セット(C99 complex関数相当を提供する)
* 内部実装(C99 complexをオブジェクトに埋め込む)
* 効率(メモリ効率、計算効率)
* 拡張ライブラリの書きやすさ
の話が同時に出てくるので判断しがたいです。
たとえば、
|少なくとも C99 の複素関数群をサポートするか否かは Ruby の数値系の
|方向性に大きく影響するはずです.そして,複素関数群をサポートする場合の
|実装方法として _Complex を持つかどうかという話になるわけですが,
|それは今迄の議論で十分話し合われていると思います.すなわち,
|Float を VALUE で持つ必要性は無いということです.
で見ると、「影響するはずです」までは機能セットの話、
「Complexを持つかどうかという話」は内部実装の話です。また、
ComplexFloatを導入するのであれば、そこで「FloatをVALUEで持つ
必要性は無い」のはその通りですが、Complexクラスしか導入しな
いという前提では逆に「Floatを特別扱いしてVALUEで持たない必要
性」はまだ結論が出ていない(個人的には消極的)です。
さて、個別の論点について整理しましょう。
まず、機能セットについては反対しません。また、その実装として
(あれば)C99 complexを経由するのもよいと思います。ただし、C99
を必須にするのは当面避けたいので、利用するにしても結局互換層
を用意する必要があると思います。
内部実装についてですが、以前いただいたパッチのように直接オブ
ジェクトに埋め込むのは全体のメモリ効率を低下させるので採用し
がたいです。独立したComplexFloat(あるいはFloatComplex?)クラ
スを採用すると決めるまではこれは保留するのがよいのではないか
と思います。個人的にはあまり独立したクラスを導入したくないで
すが。
効率についてですが、メモリはできるだけ消費しない、速度は速い
に越したことはないですが、即値でない以上、限界があると思いま
す。また、Rubyから呼び出す以上、メソッド呼び出しのコストが大
きいので、事前の予測は困難ですからあまり急いで最適化について
考える必要はなさそうに思います。
最後に拡張ライブラリの書きやすさですが、C99を必須にできない
点などからある程度困難をともないますが、結局はCのcomplexを表
現するデータとRubyのオブジェクトを相互変換するAPIがあるかど
うかに帰結するように思います。これは内部実装をどのようにする
かとは独立の話です。
まつもと ゆきひろ /:|)