[#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:34704] Re: int/int -> rational (Re: Re: ComplexFloat)
田中昌です。 |From: keiju@ishitsuka.com (石塚圭樹) > 実数がないのに複素数があるのはおかしいうんぬんの話がありましたが, 両者 > は独立に発展した概念ですのでいいんじゃないでしょうか? 独立というのがどういう意味合いかわかりませんが、 虚数単位が √-1 ですから、√x が実数であるということと 同じくらいに、複素数の実部・虚部も実数であると言えます。 もちろん実部・虚部が整数・有理数の複素数もあり得ますが、 それはたまたまそうなった特殊な場合であり、絶対値・べき乗 などの演算をすれば、実部・虚部は一般には実数になります。 ガウス整数を表したいのであれば、GaussianInteger などという クラスとして実装し直す必要があるのではないでしょうか。 > あと, 実数クラスは正木さんが作成されていますね. コーシー列を用いて実数 > を表現していると思いました. ただ, 実際には任意の数列を用いることができ > てしまうので実数と言うより超実数でしょうか(^^; これは非常に面白い取り組みだったと思いますが、 このことは、実数を正確に表すことの難しさを表しているとも言えます。 そこで、実数を表すには普通は不正確数が必要となるのですが、 その不正確数にはいろいろな実装が考えられます。 その実装により、複素数クラスの内部でも対処が必要となることもあります。 すでに、[ruby-dev:34357] の対処のため、Complex#/ メソッドの内部では Float が特別扱いにされています。 また、BigDecimal には演算精度をコントロールする機能があります。 もし BigDecimal を 複素数で使う場合は、 複素数クラスに精度をコントロールするメソッドが 欲しくなる場合も出てくるでしょう。 そういう場合は ComplexBigDecimal が必要になってくるでしょう。 こうしたことから、内部の実数クラスに特化した複素数クラスが いろいろ存在したとしてもおかしくはない、と言えます。 一方、実部虚部が任意の数値クラスである Complex クラスは、 大体正しく振る舞う複素数が手軽にできるという点で、有用だと思います。 大体動けばよいのであれば、中の型のせいで少々変な振る舞いをするとしても、 それはある程度しょうがないという気もします。 この辺の見解は、MLの話でも 人によって違っているようです。 以上のようなことを考えると、 組み込みクラスで唯一(概念的に)実数を表す Float に特化した ComplexFloat は、人によって仕様の見解が違うということもなく、 パフォーマンスがよいことから、 選択肢の1つとしてやはりそれほどおかしくはない、と思います。 もっとも、こうした話は微妙であることは確かなので、 ComplexFloat をことさら強く推すというわけではなく、 Complex の中で Float のパフォーマンスがよくなってくれさえすれば Complex でもいいかな、という気もしています。 田中昌宏