[#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:34479] Re: ComplexFloat
> > そうは思いません。まず、言葉の問題かもしれませんが、基本的に (基本的に > > はですが) 振舞いは同じだと考えます。原さんが言われることは、消極的で皮 > > 相的な完璧さを求めているだけのような気がします。 > > 同意できません。どこで意見が食い違うんでしょうね。ふなばさんは、Float の > ような「不正確数」と Rational のような「正確数」の性質の違いについて、 > 過小評価しているんじゃないですかね。 そうではないと思います。正確数と不正確数を区別する Scheme でも同じです よね。 型の制約の強い言語では、原さんがいわれるようなことが言語仕様上の要請と してある、ということがありますね。逆に、従来型の Complex のようなもの を記述するのに、総称型のような概念を導入する必要がある場合があります。 ruby はそういう言語ではないですし、そういうヌルさが利点でもあるので、 原さんがいわれるような事は、ruby にはそぐわないところがあると思います。 原さんがいわれるような事は、数値クラスに限らず、コンテナ的クラスには概 ね充てはまってしまいますが、それが悪い事だとは思いません。それがダメで あるなら、Array(Integer) 型とかそういうものを導入することになるのだと 思います。 ruby では、クラスによって何かを制限したり、なにかを保証したりすること は馴染みませんし、一般に推奨されていませんよね。代りに、似たようなもの は、なるべく同じような振舞いになるよう心掛けるようにしているはずです。 そのあたり基本的な数値クラスで徹底されていないところはありますが、その 瑕疵のせいで、Complex の仕様が曲げられることはないと思います。 > 「コンテナ」と呼ぶことについては、私もしっくりきてなくて、便宜的に使っ > ています。Lisp、Scheme、Squeak、Factor の流儀については、よく分かりませ > んが、問題を抱えているのではないでしょうか。Gauche が、正確数としての複 > 素数を捨てたのは、それを意識してのことではないでしょうか。 Gauche でどういう判断をしているのか知らないですが、Gauche では、 rational をサポートしたのも比較的最近だったと思います。最初に見たとき は、rational もなかったと思います。Scheme では体系を示した上で省くこと は許されていますから。 > 整数だから Integer を使い、小数だから Float を使う、というのは自然です > ね。それがそのまま、複素整数だから Complex を使い、複素Float だから、 > ComplexFloat を使う、ということになるだけで、無駄も何もないです。 これについての答えはもう書いたつもりでいますが、結局、原さんのいわれる ことを徹底するなら、ComplexFloat ではなく、Complex(Float, Float) 型の ような表現が必要、ということになるのではないでしょうか。僕は ruby には 必要ないと思いますが。 原さんの考えに近づけていえば、ruby にも潜在的に、Complex(Float,Float) 型のようなものがあって、それに従って振舞いが決定されている、と考えても いいのじゃないでしょうか。 > > 僕自身は、当初から Complex も Rational も、もし拡張ライブラリとして採 > > 用されれば幸いだ、というくらいの気持で作りましたけど (それは今も変りあ > > りません)、ComplexFloat が組み込みで、おまけとして従来型の Complex を > > 添付する、というのは納得がいきません。 > > 私の感覚では、Complex はおまけではないです。ComplexFloat クラスと、 > Complex クラス、どちらか一方のみを選べということなら、Complex です。 > Complex の方がレパートリーが広いからです。 Complex を組み込みにするなら、ComplexFloat も組み込みしろ、というよう な言いかたが、ずっと引っかかっていました。ComplexFloat 派に人達は、本 気で、従来型の Complex が欲しいわけじゃないですよね。 Complex を残そう、というのは、単にそういったほうが、通りがいいからとい うこともあるし、あるいは僕に対するある種の配慮から出ているのかもしれま せん。 しかし、そうすると本質的な議論が出来ません。ComplexFloat になにか課題 や問題があっても、「Complex もあるんだから」ということになるし、単なる 優先順位の問題にすり替えられてしまったります。 ComplexFloat を推すなら、Complex は要らない、として、ComplexFloat で十 分である、ということを説得してもらいたいわけです。 > ComplexFloat を組込みにし、Complex は、石塚さんの complex.rb を使う手は > アリだと思います。しかし、せっかくのふなばさんの成果も無駄にしたくない。 ありがとうございます。厚意と受けとりましたが、遠慮なく全力で、ruby に は ComplexFloat で十分だということを説明してもらえればと思います。 Complex が添付されていることを前提に、ComplexFloat を導入する、みたい な話になったらおかしいでしょう。