[#42503] floatの値がずれる — Sato Hiroshi <hirocy.f01@...>
hirocyと申します.
33 messages
2006/07/04
[#42504] Re: floatの値がずれる
— rubikitch <rubikitch@...>
2006/07/04
From: Sato Hiroshi <hirocy.f01@plala.to>
[#42505] Re: floatの値がずれる
— Sato Hiroshi <hirocy.f01@...>
2006/07/04
hirocyです.るびきちさん,ありがとうございます.
[#42506] Re: floatの値がずれる
— Sato Hiroshi <hirocy.f01@...>
2006/07/04
続けてですみません.hirocyです.
[#42509] Re: float の値がずれる
— Shin-ichiro HARA <sinara@...>
2006/07/04
原です。
[#42536] Array#default — take_tk <ggb03124@...>
たけ(tk)です
16 messages
2006/07/06
[#42544] Re: Array#default
— Yukihiro Matsumoto <matz@...>
2006/07/06
まつもと ゆきひろです
[#42569] JVN、スクリプト言語「Ruby」の2件の脆弱性情報を公表 — Takahiro Kambe <taca@...>
こんばんは。
19 messages
2006/07/11
[#42570] Re: JVN、スクリプト言語「Ruby」の2件の脆弱性情報を公表
— Yukihiro Matsumoto <matz@...>
2006/07/11
まつもと ゆきひろです
[#42572] Re: JVN、スクリプト言語「Ruby」の2件の脆弱性情報を公表
— Takahiro Kambe <taca@...>
2006/07/11
In message <1152619872.835566.21152.nullmailer@x31.priv.netlab.jp>
[#42575] Re: JVN、スクリプト言語「Ruby」の2件の脆弱性情報を公表
— Yukihiro Matsumoto <matz@...>
2006/07/11
まつもと ゆきひろです
[#42578] Re: JVN、スクリプト言語「Ruby」の2件の脆弱性情報を公表
— Kazuhiko <kazuhiko@...>
2006/07/12
かずひこです。
[#42579] Re: JVN、スクリプト言語「Ruby」の2件の脆弱性情報を公表
— Tanaka Akira <akr@...>
2006/07/12
In article <87irm334qa.wl%kazuhiko@fdiary.net>,
[#42592] Re: JVN、スクリプト言語「Ruby」の2件の脆弱性情報を公表
— Takahiro Kambe <taca@...>
2006/07/19
こんばんは。
[#42599] includeされたmoduleからの定数参照 — 二宗 崇 <nisyu@...>
にしゅうです。
5 messages
2006/07/26
[#42608] Debug Assertion Failed! on stable-snapshot — Shusaku <tsyk@...>
Shusakuです。
5 messages
2006/07/28
[ruby-list:42523] Re: float の値がずれる
From:
Shin-ichiro HARA <sinara@...>
Date:
2006-07-05 10:18:44 UTC
List:
ruby-list #42523
原です。 >斎藤と申します。皆さんBigDecimal嫌いなのかな :-( んなことないですって。(^^; >もちろんいろいろな考えがあるとは思うのですが、「小数は有理数である」 >という思考の段階を一段踏まなければならないというのは(とりあえず >自分に取っては)直観に反するような気もします。やはりここはBigDecimalの >出番ではないでしょうか。 hirocyさんの質問には、まずBigDecimalを紹介すべきでしょう。 実際、るびきちさんが紹介しましたし。 >さらに実装の都合上、どうがんばってもRationalの方が(下では10倍以上) >遅いです。 Floatの誤差の問題でRationalの利用を推奨する理由はあまりない >ように思うのですが…。逆にメリットがあるなら、教えていただけると幸いです。 問題の設定の仕方ではBigDecimalが解答にならない場合があります。 例えば意外なことにFloatをBigDecimalに変換することはできません。 BigDecimalのインプットはStringですから。意外じゃなくて、原理的に 当然ですけど。 もちろん、BigDecimal(0.01.to_s)などとすればいいわけですけど、例え ば、BigDecimal(100000000000000.1.to_s)は、0.1E15であって、 0.1000000000000001E15ではありません。つまりFloat->BigDecimalには 標準的な手段がなく、別の方法つまりRational経由とかに話が飛んだり するわけです。 実際にはFloat->BigDecimalが必要なケースがそうあるわけでもなく、 String->BigDecimalで十分なことが多いと思います。