[#38563] [Bug #1556] irb does not save history from 1.8.7-p83 and later — Nobuhiro IMAI <redmine@...>
Bug #1556: irb does not save history from 1.8.7-p83 and later
けいじゅ@いしつかです.
まつもと ゆきひろです
いまいです。
けいじゅ@いしつかです.
[#38571] [Bug #1582] IO.new Raises Other Errors between 1.8 and 1.9 — "ujihisa ." <redmine@...>
Bug #1582: IO.new Raises Other Errors between 1.8 and 1.9
チケット #1582 が更新されました。 (by Motohiro KOSAKI)
なかだです。
2010年2月27日9:43 Nobuyoshi Nakada <[email protected]>:
[#38602] [Feature: trunk] rb_objspace_each_objects — SASADA Koichi <ko1@...>
ささだです.
まつもと ゆきひろです
ささだです.
ささだです.
まつもと ゆきひろです
[#38607] [Feature: trunk] GC.stat — SASADA Koichi <ko1@...>
ささだです.
In article <[email protected]>,
ささだです.
In article <[email protected]>,
ささだです。
まつもと ゆきひろです
ささだです。
2010年10月15日16:32 SASADA Koichi <[email protected]>:
[#38608] Fixnum#fdiv — Tadayoshi Funaba <tadf@...>
Bignum#fdiv には大きな数である場合の配慮があるようですが、Fixnum ではな
fdiv では2つの異る解釈が混在しているように見えます。
まつもと ゆきひろです
> えーと、設計者は「fdivは結果がfloatになるdiv」くらいしか考え
まつもと ゆきひろです
> ふむ。「中途半端」というのはfixnumとbignumで食い違うと言う意
> > ふむ。「中途半端」というのはfixnumとbignumで食い違うと言う意
まつもと ゆきひろです
> 私が気にしているのは「挙動の理解しやすさ」ですね。
まつもと ゆきひろです
> 繰り返しになりますが、「より正確な除算」とかだと独立した実装
まつもと ゆきひろです
この件を修正しようとしていますが、
[#38609] [Feature: trunk] *_memsize() — SASADA Koichi <ko1@...>
ささだです.
[#38613] [BUG: trunk] called on terminated object — SASADA Koichi <ko1@...>
ささだです.
[#38695] [feature:trunk] let irb use pretty_inspect if possible — Yusuke ENDOH <mame@...>
遠藤です。
けいじゅ@いしつかです.
遠藤です。
けいじゅ@いしつかです.
[#38698] [Bug #1674] set_trace_func with 1line block — _ wanabe <redmine@...>
Bug #1674: set_trace_func with 1line block
[#38701] [Bug #1676] only last "return" is traced by set_trace_func — _ wanabe <redmine@...>
Bug #1676: only last "return" is traced by set_trace_func
[ruby-dev:38660] Re: Fixnum#fdiv
> 私が気にしているのは「挙動の理解しやすさ」ですね。 (中略) > Float(Rational(x,y)) > > と同じ結果を返す、と。そういうことであれば、私にとってすっき > りしますし、コストが若干気になりますが、それ以外に反対するよ > うな理由はどこにもありません。 > > 実際のところどうなんでしょう? そう考えていいと思います。が、実際に有理数にすることはないと思います。 多くの Scheme や Common Lisp の処理系では有理数型があるので、整数につい て / を実行すれば、有理数になりますが、浮動小数点数に変換する場合に機会 があります。実際そういう処理系はいくつもあります。Scheme なら exact->inexct、CL なら float など。まつもとさんがいわれるのはこれだと思 います。 でも、有理数のない Scheme 処理系では / でそういう配慮をするものがあるよ うですし、python の場合も有理数をサポートしたら true division は有理数 を返すようになるというこですが、今はそうではないです。 > |現状では fdiv も Complex になることもあり、rdiv と同様に考えればこれも > |おかしい、という可能性があると思います。 > > fdivがcomplexを返す場合、fは実部と虚部がfloatであることを示す、 > と私は理解しています。 計算対象を浮動小数点数にするのか、計算結果を浮動小数点数にするのか、こ こは重要な感じがするんですが、そうだとすると、Float(x)/Float(y) に近い 感じがします。 やはり、まつもとさんとしては、Float(x)/Float(y) であるべきという考えに 傾むいてる感じですね。