[#34556] /(.)(.)/.match("ab").select {|v| true } is empty — Tanaka Akira <akr@...>
以下のように、MatchData#select でブロックが常に真なのに結果
[#34567] write to broken pipe on Linux — Nobuyoshi Nakada <nobu@...>
なかだです。
まつもと ゆきひろです
なかだです。
[#34571] Re: [ruby-cvs:23495] Ruby:r16255 (ruby_1_8, trunk): * range.c (range_step): allow float step bigger than zero but less — Tanaka Akira <akr@...>
In article <200805011435.m41EZFBL003014@ci.ruby-lang.org>,
[#34605] Array#mapがEnumeratorを返さない — rubikitch@...
るびきちです。
[#34623] Marshal.load( Marshal.dump( Float ) )の不一致@1.8 — "H.Holon" <holon@...>
H.Holonです。
[#34646] break in lambda — Tanaka Akira <akr@...>
lambda 直下に break があったとき、なにごともなかったかのよう
[#34647] fork 不可能な環境での test_argv0_noarg — wanabe <s.wanabe@...>
ワナベと申します。
まつもと ゆきひろです
こんにちは、なかむら(う)です。
まつもと ゆきひろです
こんにちは、なかむら(う)です。
須藤です。
[#34648] Bignum のメソッドからの bigzero_p — wanabe <s.wanabe@...>
ワナベと申します。
[#34676] removing Array#nitems {} — "Akinori MUSHA" <knu@...>
Array#nitems はnilでない要素を数えるメソッドですが、ブロックを
[#34691] ext/openssl and newer OpenSSL — Takahiro Kambe <taca@...>
こんにちは。
[#34692] [ruby1.9] fork と thread — Hidetoshi NAGAI <nagai@...>
永井@知能.九工大です.
[#34726] memory leak by Array#sort! — Tanaka Akira <akr@...>
以下のように、Array#sort! の中で配列を変更するとメモりリークします。
[#34739] net/imap uses Thread#raise — Tanaka Akira <akr@...>
net/imap が原因だと思うのですが、
前田です。
In article <704d5db90805210204o7aa80c00lfeb13a34230c2c03@mail.gmail.com>,
なかだです。
[#34741] Date.parse("##-##-##") — "Akinori MUSHA" <knu@...>
Date.parse("##.##.##") の ruby_1_8 における挙動が trunk とも
> Date.parse("##.##.##") の ruby_1_8 における挙動が trunk とも
[#34742] Ruby 1.8.7-preview3 has been released — "Akinori MUSHA" <knu@...>
Ruby 1.8.7-preview3 をリリースしました。
お疲れ様です。
At Mon, 19 May 2008 11:28:10 +0900,
In message <86k5hrow30.knu@iDaemons.org>
もう一つ追加です。
At Mon, 19 May 2008 18:55:42 +0900,
[#34751] benchmark result of reverse_complement — SASADA Koichi <ko1@...>
ささだです.
[#34758] Re: [ruby-cvs:23717] Ruby:r16477 (trunk): * regparse.c (PINC): use optimized enclen() instead of — SASADA Koichi <ko1@...>
ささだです.
遠藤と申します。
[#34768] Improvement of lazy sweep patch — authorNari <authornari@...>
authorNariです。
まつもと ゆきひろです
[#34775] (1..5).step(SimpleDelegator.new(1.5)) {|x| p x} differ from (1..5).step(1.5) {|x| p x} — Tanaka Akira <akr@...>
以下のように (1..5).step(1.5) {|x| p x} と
[#34800] Windows2000上でtrunkがビルドできない — KIMURA Koichi <kimura.koichi@...>
木村です。
こんにちは、なかむら(う)です。
木村です。
木村です。
こんにちは、なかむら(う)です。
木村です。
こんにちは、なかむら(う)です。
[#34810] -Wall — SASADA Koichi <ko1@...>
ささだです.
[#34830] return value of pp — "Yusuke ENDOH" <mame@...>
遠藤です。
[#34877] [Ruby 1.9 - Bug #11] prelude.c compilation problem on mswin32 — redmine@...
Issue #11 has been updated by Usaku NAKAMURA.
[#34883] [#19002] RUBY_* constants — Kazuhiro NISHIYAMA <zn@...>
西山和広です。
[#34889] Ruby 1.8.7-preview4 test-all failed in OpenSSL::TestSSL — Nobuhiro IMAI <nov@...>
いまいです。
Nobuhiro IMAI さんは書きました:
At Sat, 31 May 2008 21:06:47 +0900,
この話題についていろいろ試していて気付いたのですが
[ruby-dev:34600] Re: ComplexFloat
まつもと ゆきひろです
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と石塚さんのおかげでしょう。私はい
まだに「群・環・体」などの「代数系」をまったく理解していませ
んです、はい。
まつもと ゆきひろ /:|)