[#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:34473] Re: ComplexFloat
原です。 Tadayoshi Funaba さんは書きました: >> もう一度少し違う例を挙げると、Complex を導入すると >> >> x.class == y.class かつ x == y だが、x - z != y - z >> >> となる例があります。x = Complex(0, 1.6), y = Complex(0, Rational(16, 10)), >> z = Complex(0, 1) です。 >> >> 数値 x の振舞いは x の属するクラスで決まって欲しい、そのようなものが組 >> み込みではより望ましい、のではないでしょうか? > > そうは思いません。まず、言葉の問題かもしれませんが、基本的に (基本的に > はですが) 振舞いは同じだと考えます。原さんが言われることは、消極的で皮 > 相的な完璧さを求めているだけのような気がします。 同意できません。どこで意見が食い違うんでしょうね。ふなばさんは、Float の ような「不正確数」と Rational のような「正確数」の性質の違いについて、 過小評価しているんじゃないですかね。 > また、もっぱら浮動小数点数だけつかうのだ、と主張されるならば、そういう > ことを気にする必要は実際的にありません。 浮動小数点数だけだったらその通りですが、「だけ」ではないので気にするわ けです。 > 議論中コンテナといわれる方法 (個人的に違和感がありますが) は、Common > Lisp、Scheme、Squeak、Factor などに見られます。これらにはクラスがない > ものもありますが、型があり、同様に考えていいと思います。これらは良くな > いのでしょうか。それとも、ruby に特有の問題があるのでしょうか? 「コンテナ」と呼ぶことについては、私もしっくりきてなくて、便宜的に使っ ています。Lisp、Scheme、Squeak、Factor の流儀については、よく分かりませ んが、問題を抱えているのではないでしょうか。Gauche が、正確数としての複 素数を捨てたのは、それを意識してのことではないでしょうか。 > 僕も Complex は、ひとつだけ、というのは賛成です。それは、ruby の大クラ > ス主義とも合致しています。 > > この、ひとつでいい、というのは、 > > 「ああ、これは浮動小数点数だから ComplexFloat をつかおう」 > 「おっと、これは、整数だから、Complex だな」 > > などというのは無駄である、ということが前提にあったと思います。比較的最 > 近では、OrderedHash についての議論が思い出されます。 整数だから Integer を使い、小数だから Float を使う、というのは自然です ね。それがそのまま、複素整数だから Complex を使い、複素Float だから、 ComplexFloat を使う、ということになるだけで、無駄も何もないです。 > 僕自身は、当初から Complex も Rational も、もし拡張ライブラリとして採 > 用されれば幸いだ、というくらいの気持で作りましたけど (それは今も変りあ > りません)、ComplexFloat が組み込みで、おまけとして従来型の Complex を > 添付する、というのは納得がいきません。 私の感覚では、Complex はおまけではないです。ComplexFloat クラスと、 Complex クラス、どちらか一方のみを選べということなら、Complex です。 Complex の方がレパートリーが広いからです。 > ひとつというのは、本当にひとつであるべきなんで、これは拡張ライブラリだ > からいい、というのは反対です。最終的に ComplexFloat を組み込むことがあ > るならば、Complex は不採用にしたほうがいいと思います。そのように決定し > たら、今の Complex は引き上げるつもりです。必要ならば、当面は石塚さん > の実装を互換性のために復活させる、という対応でよいと思います。 ComplexFloat を組込みにし、Complex は、石塚さんの complex.rb を使う手は アリだと思います。しかし、せっかくのふなばさんの成果も無駄にしたくない。 > あるいは、まつもとさんが、決めかねるのであれば、Complex はどちらも当面 > 組み込まない、ということでもいいと思います。 > > 長くなりましたが、ComplexFloat を組み込むならば、従来型の Complex は、 > もう必要ない、というべきです。まつもとさんが、そういってくれるなら、僕 > は納得します。 今そこまで考えるのは早すぎますよ。だいたい私の「ComplexFloat は組込みで、 Complex は標準添付で」っていう提案に賛成したり反対したりしている人は今 のところ私とふなばさん以外いないですし、もうすこしうまく説得する例が多 くあれば、ふなばさんの気持ちが変わるかもしれないし、私の方が説得しよう としていろいろ考えているうちに、こりゃアカンって思ってしまうこともあり 得るし。 まー、ComplexFloat と Complex の2本立てってって、ややこしくてイケてない かもって感覚もあるんですよ。