https://redmine.ruby-lang.org/https://redmine.ruby-lang.org/favicon.ico?17113305112009-03-31T14:54:36ZRuby Issue Tracking SystemRuby master - Bug #1336: Change in string representation of Floatshttps://redmine.ruby-lang.org/issues/1336?journal_id=36662009-03-31T14:54:36Znobu (Nobuyoshi Nakada)nobu@ruby-lang.org
<ul></ul><p>=begin<br>
Hi,</p>
<p>At Tue, 31 Mar 2009 14:21:15 +0900,<br>
Brian Ford wrote in <a href="/issues/1336">[ruby-core:23075]</a>:</p>
<blockquote>
<p>Did the displayed formats of Floats change in 1.9?</p>
</blockquote>
<p>Yes.</p>
<blockquote>
<p>There was a thread <a href="https://blade.ruby-lang.org/ruby-core/22595">[ruby-core:22595]</a> on the ML about the<br>
format of Floats and marshaling, but there does not appear to<br>
be any indication that the normal display format would<br>
change. Also, I did not see any mention of a change of format<br>
in the Changelog.</p>
</blockquote>
<p>It's not about marshaling.</p>
<p>--<br>
Nobu Nakada</p>
<p>=end</p> Ruby master - Bug #1336: Change in string representation of Floatshttps://redmine.ruby-lang.org/issues/1336?journal_id=36672009-03-31T14:55:11Znobu (Nobuyoshi Nakada)nobu@ruby-lang.org
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Closed</i></li></ul><p>=begin</p>
<p>=end</p> Ruby master - Bug #1336: Change in string representation of Floatshttps://redmine.ruby-lang.org/issues/1336?journal_id=36682009-03-31T15:58:39Zbrixen (Brian Shirai)brixen@gmail.com
<ul></ul><p>=begin<br>
Hi,</p>
<p>On Mon, Mar 30, 2009 at 10:54 PM, Nobuyoshi Nakada <a href="mailto:nobu@ruby-lang.org" class="email">nobu@ruby-lang.org</a> wrote:</p>
<blockquote>
<p>Hi,</p>
<p>At Tue, 31 Mar 2009 14:21:15 +0900,<br>
Brian Ford wrote in <a href="/issues/1336">[ruby-core:23075]</a>:</p>
<blockquote>
<p>Did the displayed formats of Floats change in 1.9?</p>
</blockquote>
<p>Yes.</p>
</blockquote>
<p>Where was this discussed and what was the reason for changing it?</p>
<blockquote>
<blockquote>
<p>There was a thread <a href="https://blade.ruby-lang.org/ruby-core/22595">[ruby-core:22595]</a> on the ML about the<br>
format of Floats and marshaling, but there does not appear to<br>
be any indication that the normal display format would<br>
change. Also, I did not see any mention of a change of format<br>
in the Changelog.</p>
</blockquote>
<p>It's not about marshaling.</p>
</blockquote>
<p>Thanks for clarifying this part.</p>
<p>Brian</p>
<blockquote>
<p>--<br>
Nobu Nakada</p>
</blockquote>
<p>=end</p> Ruby master - Bug #1336: Change in string representation of Floatshttps://redmine.ruby-lang.org/issues/1336?journal_id=36692009-03-31T17:33:11Zzenspider (Ryan Davis)
<ul></ul><p>=begin</p>
<p>On Mar 30, 2009, at 23:58 , brian ford wrote:</p>
<blockquote>
<p>Where was this discussed and what was the reason for changing it?</p>
</blockquote>
<p>I can answer the latter:</p>
<blockquote>
<p>r22783 | nobu | 2009-03-05 01:36:39 -0800 (Thu, 05 Mar 2009) | 3 lines</p>
<ul>
<li>numeric.c (flo_to_s): keeps enough precision for round trip.<br>
<a href="https://blade.ruby-lang.org/ruby-core/22325">[ruby-core:22325]</a></li>
</ul>
</blockquote>
<p>=end</p> Ruby master - Bug #1336: Change in string representation of Floatshttps://redmine.ruby-lang.org/issues/1336?journal_id=36722009-04-01T02:08:22Zbrixen (Brian Shirai)brixen@gmail.com
<ul></ul><p>=begin<br>
On Tue, Mar 31, 2009 at 1:32 AM, Ryan Davis <a href="mailto:ryand-ruby@zenspider.com" class="email">ryand-ruby@zenspider.com</a> wrote:</p>
<blockquote>
<p>On Mar 30, 2009, at 23:58 , brian ford wrote:</p>
<blockquote>
<p>Where was this discussed and what was the reason for changing it?</p>
</blockquote>
<p>I can answer the latter:</p>
<blockquote>
<p>r22783 | nobu | 2009-03-05 01:36:39 -0800 (Thu, 05 Mar 2009) | 3 lines</p>
<ul>
<li>numeric.c (flo_to_s): keeps enough precision for round trip.<br>
<a href="https://blade.ruby-lang.org/ruby-core/22325">[ruby-core:22325]</a></li>
</ul>
</blockquote>
</blockquote>
<p>This is more "what it does" than why it was changed. Why was it needed?</p>
<p>Ruby cannot round-trip a lot of stuff via the object's to_s or inspect<br>
string. That's what marshal is for.</p>
<p>Why was it so important to change Ruby's long standing friendly<br>
floats? I personally see it having a lot of unintended consequences.</p>
<p>Brian</p>
<p>=end</p> Ruby master - Bug #1336: Change in string representation of Floatshttps://redmine.ruby-lang.org/issues/1336?journal_id=37002009-04-04T15:49:42Zrogerdpack (Roger Pack)rogerpack2005@gmail.com
<ul></ul><p>=begin</p>
<blockquote>
<blockquote>
<ul>
<li>numeric.c (flo_to_s): keeps enough precision for round trip.</li>
</ul>
</blockquote>
</blockquote>
<p>One possibility would be to allow Float#to_s to still be (depending on how you look at it) "friendly" or "imprecise."</p>
<p>And keep the precise version for Float#inspect.</p>
<p>The benefit of having them both verbose is that (tongue in cheek) it makes floats hideously ugly which might encourage people to avoid them :)</p>
<p>But having both available separately via #inspect and #to_s would be nice and I'd imagine a patch to that effect would be well received.</p>
<p>A discussion on it can be read at <a href="http://www.ruby-forum.com/topic/179361" class="external">http://www.ruby-forum.com/topic/179361</a></p>
<p>Cheers.<br>
-=r<br>
=end</p> Ruby master - Bug #1336: Change in string representation of Floatshttps://redmine.ruby-lang.org/issues/1336?journal_id=37012009-04-05T02:51:40Zbrixen (Brian Shirai)brixen@gmail.com
<ul></ul><p>=begin<br>
On Fri, Apr 3, 2009 at 11:49 PM, Roger Pack <a href="mailto:redmine@ruby-lang.org" class="email">redmine@ruby-lang.org</a> wrote:</p>
<blockquote>
<p>Issue <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: Change in string representation of Floats (Closed)" href="https://redmine.ruby-lang.org/issues/1336">#1336</a> has been updated by Roger Pack.</p>
<blockquote>
<blockquote>
<ul>
<li>numeric.c (flo_to_s): keeps enough precision for round trip.</li>
</ul>
</blockquote>
</blockquote>
<p>One possibility would be to allow Float#to_s to still be (depending on how you look at it) "friendly" or "imprecise."</p>
<p>And keep the precise version for Float#inspect.</p>
<p>The benefit of having them both verbose is that (tongue in cheek) it makes floats hideously ugly which might encourage people to avoid them :)</p>
<p>But having both available separately via #inspect and #to_s would be nice and I'd imagine a patch to that effect would be well received.</p>
<p>A discussion on it can be read at <a href="http://www.ruby-forum.com/topic/179361" class="external">http://www.ruby-forum.com/topic/179361</a></p>
</blockquote>
<p>It's not an issue of float precision. It is an issue of representation<br>
and there are many possibly representations of a float. The previous<br>
representation was user-friendly. The change is not.</p>
<p>The only justification for the change that I see is this idea that<br>
there is value to being able to round trip a float from #to_s through<br>
eval. However, I think that is a poor reason to change because:</p>
<ol>
<li>I can count the number Ruby classes that can be round-tripped this<br>
way on one hand.</li>
<li>There is a perfectly good mechanism for round-tripping any Ruby object.</li>
<li>If you don't want to marshal, you can use #sprintf when <em>you</em> want<br>
to round-trip a float via a string and eval.</li>
<li>The vast majority of times a float is represented as a string it is<br>
<em>not</em> to round-trip.</li>
</ol>
<p>So, this decision takes a marginal case for which a perfectly good<br>
mechanism already exists and promotes it to the common case. But<br>
that's not all. The consequence for the common case is that 2.4 is<br>
unnecessarily and uselessly echoed back to me as 2.3999999999999999.</p>
<p>It is very poor interface design to promote a marginal case above a<br>
common case. There is nothing that this change in representation makes<br>
better in the common case. It makes the common case hideous.</p>
<p>Floats are what they are. Use them as you will. Ruby used to have<br>
nice, friendly representations of floats for humans. Nothing gained,<br>
much lost. The decision should be reversed.</p>
<p>Brian</p>
<blockquote>
<h2>Cheers.<br>
-=r</h2>
<p><a href="http://redmine.ruby-lang.org/issues/show/1336" class="external">http://redmine.ruby-lang.org/issues/show/1336</a></p>
<hr>
<p><a href="http://redmine.ruby-lang.org" class="external">http://redmine.ruby-lang.org</a></p>
</blockquote>
<p>=end</p> Ruby master - Bug #1336: Change in string representation of Floatshttps://redmine.ruby-lang.org/issues/1336?journal_id=37022009-04-05T16:57:56Zheadius (Charles Nutter)headius@headius.com
<ul></ul><p>=begin<br>
brian ford wrote:</p>
<blockquote>
<p>So, this decision takes a marginal case for which a perfectly good<br>
mechanism already exists and promotes it to the common case. But<br>
that's not all. The consequence for the common case is that 2.4 is<br>
unnecessarily and uselessly echoed back to me as 2.3999999999999999.</p>
<p>It is very poor interface design to promote a marginal case above a<br>
common case. There is nothing that this change in representation makes<br>
better in the common case. It makes the common case hideous.</p>
<p>Floats are what they are. Use them as you will. Ruby used to have<br>
nice, friendly representations of floats for humans. Nothing gained,<br>
much lost. The decision should be reversed.</p>
</blockquote>
<p>Except that it was all a lie.</p>
<p>If a float can't be represented accurately, Ruby should not mask that,<br>
because it further perpetuates the mistaken belief that floats are<br>
accurate in Ruby. Treating 2.39999999999999 as 2.4 accomplishes exactly<br>
one thing: it hides the true nature of floats.</p>
<p>I can appreciate the desire to have arbitrary-precision floating-point<br>
math as the default in Ruby, but that's not the case right now. What we<br>
have in Ruby 1.8 and 1.9 before this change is the horrible middle<br>
ground of imprecise floats <em>pretending</em> to be precise. And we have run<br>
into real-world bugs where JRuby's original lack of float-masking caused<br>
application failures; people believed they could expect 2.4 in all cases<br>
instead of 2.399999999999999. We should not have had to make our floats lie.</p>
<p>I would say either floats should always be arbitrary precision, or they<br>
should be honest about their imprecision. Anything else is doing the<br>
developer a disservice.</p>
<p>=end</p> Ruby master - Bug #1336: Change in string representation of Floatshttps://redmine.ruby-lang.org/issues/1336?journal_id=37052009-04-06T03:24:42Zbrent (Brent Roman)brent@mbari.org
<ul></ul><p>=begin</p>
<p>I have to agree with Brian on this.</p>
<p>A quick, informal survey of various other languages shows that, by default,<br>
most<br>
will faithfully convert floating point 2.4 from a string to float and back<br>
again.</p>
<p>'C', 'C++', Lua, Haskell, Matlab, BASIC, Pascal, etc.<br>
all output "2.4" when their best floating point approximation of 2.4 is<br>
converted to a string<br>
with default options.</p>
<p>Python, however, does output 2.3999...<br>
While someone can probably find another commonly used language that behaves<br>
as Python does in this regard, I'm sure such languages are firmly in the<br>
minority.</p>
<p>A good compromise solution, in Ruby's case, would be to redefine<br>
Float#inspect such that it preserves the value's full precision without<br>
rounding (for round-tripping, ultimate "truth", or whatever), while leaving<br>
Float#to_s as it was.</p>
<p>This is consistent with other uses of the inspect method. Consider, for<br>
example, that String and Symbol#to_s will return unquoted, ambiguous output<br>
strings, while the corresponding #inspect methods return fully quoted,<br>
unambiguous results.</p>
<p>It might also be a good idea to include a paragraph or two about the<br>
behavior of limited precision floating point numbers in Ruby Doc for the<br>
Float class. Include {puts 2.4} verses {p 2.4} as an example. After all,<br>
the crux of this issue is education about the behavior of Floats that every<br>
programmer using them really needs to understand, regardless of how they are<br>
output.</p>
<p>Having said all this, I'm not going to get too worked up about it. I will<br>
just sigh and add:</p>
<p>class Float<br>
def to_s<br>
"%g" % self<br>
end<br>
end</p>
<p>to the home grown Ruby version compatibility library that I already require<br>
in most of my apps.</p>
<ul>
<li>brent</li>
</ul>
<p>brixen wrote:</p>
<blockquote>
<p>On Fri, Apr 3, 2009 at 11:49 PM, Roger Pack <a href="mailto:redmine@ruby-lang.org" class="email">redmine@ruby-lang.org</a> wrote:</p>
<blockquote>
<p>Issue <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: Change in string representation of Floats (Closed)" href="https://redmine.ruby-lang.org/issues/1336">#1336</a> has been updated by Roger Pack.</p>
<blockquote>
<blockquote>
<ul>
<li>numeric.c (flo_to_s): keeps enough precision for round trip.</li>
</ul>
</blockquote>
</blockquote>
<p>One possibility would be to allow Float#to_s to still be (depending on<br>
how you look at it) "friendly" or "imprecise."</p>
<p>And keep the precise version for Float#inspect.</p>
<p>The benefit of having them both verbose is that (tongue in cheek) it<br>
makes floats hideously ugly which might encourage people to avoid them :)</p>
<p>But having both available separately via #inspect and #to_s would be nice<br>
and I'd imagine a patch to that effect would be well received.</p>
<p>A discussion on it can be read at <a href="http://www.ruby-forum.com/topic/179361" class="external">http://www.ruby-forum.com/topic/179361</a></p>
</blockquote>
<p>It's not an issue of float precision. It is an issue of representation<br>
and there are many possibly representations of a float. The previous<br>
representation was user-friendly. The change is not.</p>
<p>The only justification for the change that I see is this idea that<br>
there is value to being able to round trip a float from #to_s through<br>
eval. However, I think that is a poor reason to change because:</p>
<ol>
<li>I can count the number Ruby classes that can be round-tripped this<br>
way on one hand.</li>
<li>There is a perfectly good mechanism for round-tripping any Ruby object.</li>
<li>If you don't want to marshal, you can use #sprintf when <em>you</em> want<br>
to round-trip a float via a string and eval.</li>
<li>The vast majority of times a float is represented as a string it is<br>
<em>not</em> to round-trip.</li>
</ol>
<p>So, this decision takes a marginal case for which a perfectly good<br>
mechanism already exists and promotes it to the common case. But<br>
that's not all. The consequence for the common case is that 2.4 is<br>
unnecessarily and uselessly echoed back to me as 2.3999999999999999.</p>
<p>It is very poor interface design to promote a marginal case above a<br>
common case. There is nothing that this change in representation makes<br>
better in the common case. It makes the common case hideous.</p>
<p>Floats are what they are. Use them as you will. Ruby used to have<br>
nice, friendly representations of floats for humans. Nothing gained,<br>
much lost. The decision should be reversed.</p>
<p>Brian</p>
<blockquote>
<h2>Cheers.<br>
-=r</h2>
<p><a href="http://redmine.ruby-lang.org/issues/show/1336" class="external">http://redmine.ruby-lang.org/issues/show/1336</a></p>
<hr>
<p><a href="http://redmine.ruby-lang.org" class="external">http://redmine.ruby-lang.org</a></p>
</blockquote>
</blockquote>
<p>--<br>
View this message in context: <a href="http://www.nabble.com/-ruby-core%3A23075---Bug--1336--Change-in-string-representation-of-Floats-tp22798535p22896937.html" class="external">http://www.nabble.com/-ruby-core%3A23075---Bug--1336--Change-in-string-representation-of-Floats-tp22798535p22896937.html</a><br>
Sent from the ruby-core mailing list archive at Nabble.com.</p>
<p>=end</p> Ruby master - Bug #1336: Change in string representation of Floatshttps://redmine.ruby-lang.org/issues/1336?journal_id=37082009-04-06T12:51:04Zmame (Yusuke Endoh)mame@ruby-lang.org
<ul></ul><p>=begin<br>
I agree with Brian.</p>
<p>I think it is a spec for Ruby 1.8 and 1.9 to fail to round-trip,<br>
even if it may be inconvenient a little. I cannot find a reason<br>
why `round-trip' feature is more important than compatibility.</p>
<p>In addition, the change actually attacked my some scripts... :-(</p>
<p>`inspect' used to return user-friendly (and sometimes imprecise)<br>
representation.<br>
Why not create a new method Float#dump for round-trip and precise<br>
representation (like String#dump) ?</p>
<p>If Float#inspect must be changed, please go over the shortest<br>
representation algorithm which was mentioned in <a href="https://blade.ruby-lang.org/ruby-core/22629">[ruby-core:22629]</a>.</p>
<p>Just my 2 cents,</p>
<p>2009/4/5 brian ford <a href="mailto:brixen@gmail.com" class="email">brixen@gmail.com</a>:</p>
<blockquote>
<p>On Fri, Apr 3, 2009 at 11:49 PM, Roger Pack <a href="mailto:redmine@ruby-lang.org" class="email">redmine@ruby-lang.org</a> wrote:</p>
<blockquote>
<p>Issue <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: Change in string representation of Floats (Closed)" href="https://redmine.ruby-lang.org/issues/1336">#1336</a> has been updated by Roger Pack.</p>
<blockquote>
<blockquote>
<ul>
<li>numeric.c (flo_to_s): keeps enough precision for round trip.</li>
</ul>
</blockquote>
</blockquote>
<p>One possibility would be to allow Float#to_s to still be (depending on how you look at it) "friendly" or "imprecise."</p>
<p>And keep the precise version for Float#inspect.</p>
<p>The benefit of having them both verbose is that (tongue in cheek) it makes floats hideously ugly which might encourage people to avoid them :)</p>
<p>But having both available separately via #inspect and #to_s would be nice and I'd imagine a patch to that effect would be well received.</p>
<p>A discussion on it can be read at <a href="http://www.ruby-forum.com/topic/179361" class="external">http://www.ruby-forum.com/topic/179361</a></p>
</blockquote>
<p>It's not an issue of float precision. It is an issue of representation<br>
and there are many possibly representations of a float. The previous<br>
representation was user-friendly. The change is not.</p>
<p>The only justification for the change that I see is this idea that<br>
there is value to being able to round trip a float from #to_s through<br>
eval. However, I think that is a poor reason to change because:</p>
<ol>
<li>I can count the number Ruby classes that can be round-tripped this<br>
way on one hand.</li>
<li>There is a perfectly good mechanism for round-tripping any Ruby object.</li>
<li>If you don't want to marshal, you can use #sprintf when <em>you</em> want<br>
to round-trip a float via a string and eval.</li>
<li>The vast majority of times a float is represented as a string it is<br>
<em>not</em> to round-trip.</li>
</ol>
<p>So, this decision takes a marginal case for which a perfectly good<br>
mechanism already exists and promotes it to the common case. But<br>
that's not all. The consequence for the common case is that 2.4 is<br>
unnecessarily and uselessly echoed back to me as 2.3999999999999999.</p>
<p>It is very poor interface design to promote a marginal case above a<br>
common case. There is nothing that this change in representation makes<br>
better in the common case. It makes the common case hideous.</p>
<p>Floats are what they are. Use them as you will. Ruby used to have<br>
nice, friendly representations of floats for humans. Nothing gained,<br>
much lost. The decision should be reversed.</p>
<p>Brian</p>
<blockquote>
<h2>Cheers.<br>
-=r</h2>
<p><a href="http://redmine.ruby-lang.org/issues/show/1336" class="external">http://redmine.ruby-lang.org/issues/show/1336</a></p>
<hr>
<p><a href="http://redmine.ruby-lang.org" class="external">http://redmine.ruby-lang.org</a></p>
</blockquote>
</blockquote>
<p>--<br>
Yusuke ENDOH <a href="mailto:mame@tsg.ne.jp" class="email">mame@tsg.ne.jp</a></p>
<p>=end</p> Ruby master - Bug #1336: Change in string representation of Floatshttps://redmine.ruby-lang.org/issues/1336?journal_id=37352009-04-11T15:17:24Zrogerdpack (Roger Pack)rogerpack2005@gmail.com
<ul></ul><p>=begin<br>
I like the recent change. Now it acts like this:</p>
<blockquote>
<blockquote>
<p>0.9<br>
=> 0.9<br>
2.1 - 3.0<br>
=> -0.8999999999999999<br>
(2.1-3.0) == -0.9<br>
=> false</p>
</blockquote>
</blockquote>
<p>Is this satisfactory, or would anyone still prefer Float#to_s => rounded, Float#inspect => non rounded (i.e. 0.9.inspect => "0.8999999999")? Just wondering since I brought up this mess :)<br>
I kind of like the current way. It hides some complexity while still explaining to end users why equality fails.<br>
Thanks for the update.</p>
<p>-=r<br>
=end</p> Ruby master - Bug #1336: Change in string representation of Floatshttps://redmine.ruby-lang.org/issues/1336?journal_id=37372009-04-11T16:03:01Znobu (Nobuyoshi Nakada)nobu@ruby-lang.org
<ul></ul><p>=begin<br>
Hi,</p>
<p>At Sat, 11 Apr 2009 15:17:24 +0900,<br>
Roger Pack wrote in <a href="https://blade.ruby-lang.org/ruby-core/23179">[ruby-core:23179]</a>:</p>
<blockquote>
<p>Is this satisfactory, or would anyone still prefer Float#to_s<br>
=> rounded, Float#inspect => non rounded (i.e. 0.9.inspect =><br>
"0.8999999999")? Just wondering since I brought up this mess<br>
:)</p>
</blockquote>
<p>I had another thought, Float#to_s could take an optional<br>
argument to specify the precision or the format.</p>
<p>e.g.:</p>
<p>0.9.to_s(3) #=> "0.900"<br>
0.9.to_s("e") #=> "9.000000e-01"<br>
0.9.to_s(prec: 4, width: 6) #=> " 9.000"</p>
<p>--<br>
Nobu Nakada</p>
<p>=end</p> Ruby master - Bug #1336: Change in string representation of Floatshttps://redmine.ruby-lang.org/issues/1336?journal_id=37382009-04-12T03:53:37Zbrent (Brent Roman)brent@mbari.org
<ul></ul><p>=begin</p>
<p>I'd prefer that Float#to_s => rounded, Float#inspect => non rounded<br>
(i.e. 0.9.inspect => "0.8999999999")</p>
<ul>
<li>brent</li>
</ul>
<p>Sakuro OZAWA wrote:</p>
<blockquote>
<p>Issue <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: Change in string representation of Floats (Closed)" href="https://redmine.ruby-lang.org/issues/1336">#1336</a> has been updated by Roger Pack.</p>
<p>I like the recent change. Now it acts like this:</p>
<blockquote>
<blockquote>
<p>0.9<br>
=> 0.9<br>
2.1 - 3.0<br>
=> -0.8999999999999999<br>
(2.1-3.0) == -0.9<br>
=> false</p>
</blockquote>
</blockquote>
<p>Is this satisfactory, or would anyone still prefer Float#to_s => rounded,<br>
Float#inspect => non rounded (i.e. 0.9.inspect => "0.8999999999")? Just<br>
wondering since I brought up this mess :)<br>
I kind of like the current way. It hides some complexity while still<br>
explaining to end users why equality fails.<br>
Thanks for the update.</p>
<a name="-r"></a>
<h2 >-=r<a href="#-r" class="wiki-anchor">¶</a></h2>
<p><a href="http://redmine.ruby-lang.org/issues/show/1336" class="external">http://redmine.ruby-lang.org/issues/show/1336</a></p>
<hr>
<p><a href="http://redmine.ruby-lang.org" class="external">http://redmine.ruby-lang.org</a></p>
</blockquote>
<p>--<br>
View this message in context: <a href="http://www.nabble.com/-ruby-core%3A23075---Bug--1336--Change-in-string-representation-of-Floats-tp22798535p23004293.html" class="external">http://www.nabble.com/-ruby-core%3A23075---Bug--1336--Change-in-string-representation-of-Floats-tp22798535p23004293.html</a><br>
Sent from the ruby-core mailing list archive at Nabble.com.</p>
<p>=end</p> Ruby master - Bug #1336: Change in string representation of Floatshttps://redmine.ruby-lang.org/issues/1336?journal_id=37392009-04-12T03:59:37Zbrent (Brent Roman)brent@mbari.org
<ul></ul><p>=begin</p>
<p>Your latter example seems quite nice.<br>
Especially if it would accept unabbreviated forms such as this:</p>
<p>0.9.to_s(precision: 4, width: 6) #=> " 9.000"</p>
<ul>
<li>brent</li>
</ul>
<p>Nobuyoshi Nakada-2 wrote:</p>
<blockquote>
<p>Hi,</p>
<p>At Sat, 11 Apr 2009 15:17:24 +0900,<br>
Roger Pack wrote in <a href="https://blade.ruby-lang.org/ruby-core/23179">[ruby-core:23179]</a>:</p>
<blockquote>
<p>Is this satisfactory, or would anyone still prefer Float#to_s<br>
=> rounded, Float#inspect => non rounded (i.e. 0.9.inspect =><br>
"0.8999999999")? Just wondering since I brought up this mess<br>
:)</p>
</blockquote>
<p>I had another thought, Float#to_s could take an optional<br>
argument to specify the precision or the format.</p>
<p>e.g.:</p>
<p>0.9.to_s(3) #=> "0.900"<br>
0.9.to_s("e") #=> "9.000000e-01"<br>
0.9.to_s(prec: 4, width: 6) #=> " 9.000"</p>
<p>--<br>
Nobu Nakada</p>
</blockquote>
<p>--<br>
View this message in context: <a href="http://www.nabble.com/-ruby-core%3A23075---Bug--1336--Change-in-string-representation-of-Floats-tp22798535p23004340.html" class="external">http://www.nabble.com/-ruby-core%3A23075---Bug--1336--Change-in-string-representation-of-Floats-tp22798535p23004340.html</a><br>
Sent from the ruby-core mailing list archive at Nabble.com.</p>
<p>=end</p> Ruby master - Bug #1336: Change in string representation of Floatshttps://redmine.ruby-lang.org/issues/1336?journal_id=37402009-04-13T07:28:33Zmatz (Yukihiro Matsumoto)matz@ruby.or.jp
<ul></ul><p>=begin<br>
Hi,</p>
<p>In message "Re: <a href="https://blade.ruby-lang.org/ruby-core/23181">[ruby-core:23181]</a> Re: [Bug <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: Change in string representation of Floats (Closed)" href="https://redmine.ruby-lang.org/issues/1336">#1336</a>] Change in string representation of Floats"<br>
on Sun, 12 Apr 2009 03:53:12 +0900, Brent Roman <a href="mailto:brent@mbari.org" class="email">brent@mbari.org</a> writes:</p>
<p>|I'd prefer that Float#to_s => rounded, Float#inspect => non rounded<br>
|(i.e. 0.9.inspect => "0.8999999999")</p>
<p>I see several people who prefer that way. Could you elaborate the<br>
reason behind the preference? Considering being to_s for mere string<br>
representation, and inspect being human readable string<br>
representation, I thought other way around.</p>
<pre><code> matz.
</code></pre>
<p>=end</p> Ruby master - Bug #1336: Change in string representation of Floatshttps://redmine.ruby-lang.org/issues/1336?journal_id=37412009-04-13T10:55:06Zbrent (Brent Roman)brent@mbari.org
<ul></ul><p>=begin</p>
<p>Perhaps I'm not understanding the question.<br>
Consider:</p>
<p>s = "string"<br>
s.inspect ==> "string" #this will round-trip<br>
s.to_s ==> string #this lacks the required delimiters</p>
<p>s = :symbol<br>
s.inspect ==> :symbol #similarly...<br>
s.to_s ==> symbol #but this lacks delimiters and is abiguous</p>
<p>a = [1,2,3] #again...<br>
a.inspect ==> [1, 2, 3]<br>
a.to_s ==> 123 #this is pretty useless</p>
<p>h = [:foo=>:bar, :bar=>:foo] #and, finally...<br>
a.inspect ==> {:foo=>:bar, :bar=>:foo}<br>
a.to_s ==> foobarbarfoo #as is this.</p>
<p>In all the above examples, the #inspect method outputs delimiters necessary<br>
for Ruby's parser to recreate the data object, while the #to_s method omits<br>
delimiters to produce terser, albeit sometimes ambiguous, output.</p>
<p>Admittedly, to_s doesn't work very well on collections, but, it will convert<br>
any basic type to a short, human readable string free of extraneous<br>
punctuation. Float#to_s should do the same for consistency' sake.</p>
<p>As a practical matter, changing Float#to_s at this point will cause many no<br>
longer maintained Ruby scripts to output confusing long trains of digits<br>
after the decimal. And, consider the bugs that will emerge when data base<br>
queries on ranges of values like 0.1 to 0.9, if the string representations<br>
actually passed (from Ruby via Float.to_s) into the data base engine (which<br>
for all we know is using decimal floats) are in fact 0.10000000000000001 to<br>
0.90000000000000002</p>
<ul>
<li>brent</li>
</ul>
<p>Yukihiro Matsumoto wrote:</p>
<blockquote>
<p>Hi,</p>
<p>In message "Re: <a href="https://blade.ruby-lang.org/ruby-core/23181">[ruby-core:23181]</a> Re: [Bug <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: Change in string representation of Floats (Closed)" href="https://redmine.ruby-lang.org/issues/1336">#1336</a>] Change in string<br>
representation of Floats"<br>
on Sun, 12 Apr 2009 03:53:12 +0900, Brent Roman <a href="mailto:brent@mbari.org" class="email">brent@mbari.org</a><br>
writes:</p>
<p>|I'd prefer that Float#to_s => rounded, Float#inspect => non rounded<br>
|(i.e. 0.9.inspect => "0.8999999999")</p>
<p>I see several people who prefer that way. Could you elaborate the<br>
reason behind the preference? Considering being to_s for mere string<br>
representation, and inspect being human readable string<br>
representation, I thought other way around.</p>
<pre><code> matz.
</code></pre>
</blockquote>
<p>--<br>
View this message in context: <a href="http://www.nabble.com/-ruby-core%3A23075---Bug--1336--Change-in-string-representation-of-Floats-tp22798535p23016776.html" class="external">http://www.nabble.com/-ruby-core%3A23075---Bug--1336--Change-in-string-representation-of-Floats-tp22798535p23016776.html</a><br>
Sent from the ruby-core mailing list archive at Nabble.com.</p>
<p>=end</p> Ruby master - Bug #1336: Change in string representation of Floatshttps://redmine.ruby-lang.org/issues/1336?journal_id=37422009-04-13T11:17:36Zmatz (Yukihiro Matsumoto)matz@ruby.or.jp
<ul></ul><p>=begin<br>
Hi,</p>
<p>In message "Re: <a href="https://blade.ruby-lang.org/ruby-core/23187">[ruby-core:23187]</a> Re: [Bug <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: Change in string representation of Floats (Closed)" href="https://redmine.ruby-lang.org/issues/1336">#1336</a>] Change in string representation of Floats"<br>
on Mon, 13 Apr 2009 10:54:46 +0900, Brent Roman <a href="mailto:brent@mbari.org" class="email">brent@mbari.org</a> writes:</p>
<p>|Perhaps I'm not understanding the question.<br>
|Consider:<br>
|<br>
|s = "string"<br>
|s.inspect ==> "string" #this will round-trip<br>
|s.to_s ==> string #this lacks the required delimiters<br>
|<br>
|s = :symbol<br>
|s.inspect ==> :symbol #similarly...<br>
|s.to_s ==> symbol #but this lacks delimiters and is abiguous<br>
|<br>
|a = [1,2,3] #again...<br>
|a.inspect ==> [1, 2, 3]<br>
|a.to_s ==> 123 #this is pretty useless<br>
|<br>
|h = [:foo=>:bar, :bar=>:foo] #and, finally...<br>
|a.inspect ==> {:foo=>:bar, :bar=>:foo}<br>
|a.to_s ==> foobarbarfoo #as is this.<br>
|<br>
|In all the above examples, the #inspect method outputs delimiters necessary<br>
|for Ruby's parser to recreate the data object, while the #to_s method omits<br>
|delimiters to produce terser, albeit sometimes ambiguous, output.</p>
<p>to_s for arrays and hashes are changed in 1.9.</p>
<p>Perhaps we need 3 ways for string representation:</p>
<ul>
<li>mere string representation</li>
<li>human readable representation</li>
<li>regenerating representation (as in <a href="https://blade.ruby-lang.org/ruby-core/23128">[ruby-core:23128]</a>)</li>
</ul>
<p>|As a practical matter, changing Float#to_s at this point will cause many no<br>
|longer maintained Ruby scripts to output confusing long trains of digits<br>
|after the decimal. And, consider the bugs that will emerge when data base<br>
|queries on ranges of values like 0.1 to 0.9, if the string representations<br>
|actually passed (from Ruby via Float.to_s) into the data base engine (which<br>
|for all we know is using decimal floats) are in fact 0.10000000000000001 to<br>
|0.90000000000000002</p>
<p>I'm not sure what you mean by "at this point". The point we move 1.8<br>
from 1.9 is the only point where we can make such changes. In<br>
addition, the latest trunk gives you "0.1" for 1.0.inspect.</p>
<pre><code> matz.
</code></pre>
<p>=end</p> Ruby master - Bug #1336: Change in string representation of Floatshttps://redmine.ruby-lang.org/issues/1336?journal_id=37432009-04-13T13:12:22Zbrent (Brent Roman)brent@mbari.org
<ul></ul><p>=begin</p>
<p>I'm not sure I understand the difference between "mere string" and "human<br>
readable" representations.<br>
Could you give an example?</p>
<p>1.8 is similar enough to 1.9 that many straightforward scripts will run<br>
without change.<br>
However, Float#to_s is likely used in almost every script that uses Floats,<br>
even those that would otherwise run unchanged under 1.9. I think changing<br>
it introduces bugs in these for no great gain. Others on this thread have<br>
already said the same.</p>
<p>I'm sure you meant that 0.1.inspect would produce "0.1" for the current<br>
trunk.<br>
I could see how careful string conversion could ensure that simple constant<br>
literals would always<br>
be preserved. The trouble really begins only after one starts doing<br>
arithmetic with them.</p>
<p>What does the current trunk output for (2.1-3.0).to_s ?</p>
<p>Consider that (here at least):<br>
2.1-3.0+0.9 == 1.110223024625156540e-16</p>
<p>I'd like to be proven wrong, but I currently believe that the one cannot<br>
create a human friendly Float string conversion that is also a regenerating<br>
representation.</p>
<ul>
<li>brent</li>
</ul>
<p>Yukihiro Matsumoto wrote:</p>
<blockquote>
<p>to_s for arrays and hashes are changed in 1.9.</p>
<p>Perhaps we need 3 ways for string representation:</p>
<ul>
<li>mere string representation</li>
<li>human readable representation</li>
<li>regenerating representation (as in <a href="https://blade.ruby-lang.org/ruby-core/23128">[ruby-core:23128]</a>)</li>
</ul>
<p>|As a practical matter, changing Float#to_s at this point will cause many<br>
no<br>
|longer maintained Ruby scripts to output confusing long trains of digits<br>
|after the decimal. And, consider the bugs that will emerge when data<br>
base<br>
|queries on ranges of values like 0.1 to 0.9, if the string<br>
representations<br>
|actually passed (from Ruby via Float.to_s) into the data base engine<br>
(which<br>
|for all we know is using decimal floats) are in fact 0.10000000000000001<br>
to<br>
|0.90000000000000002</p>
<p>I'm not sure what you mean by "at this point". The point we move 1.8<br>
from 1.9 is the only point where we can make such changes. In<br>
addition, the latest trunk gives you "0.1" for 1.0.inspect.</p>
<pre><code> matz.
</code></pre>
</blockquote>
<p>--<br>
View this message in context: <a href="http://www.nabble.com/-ruby-core%3A23075---Bug--1336--Change-in-string-representation-of-Floats-tp22798535p23017694.html" class="external">http://www.nabble.com/-ruby-core%3A23075---Bug--1336--Change-in-string-representation-of-Floats-tp22798535p23017694.html</a><br>
Sent from the ruby-core mailing list archive at Nabble.com.</p>
<p>=end</p> Ruby master - Bug #1336: Change in string representation of Floatshttps://redmine.ruby-lang.org/issues/1336?journal_id=37442009-04-13T16:19:22Zrue (Eero Saynatkari)
<ul></ul><p>=begin<br>
Excerpts from Yukihiro Matsumoto's message of Mon Apr 13 05:17:28 +0300 2009:</p>
<blockquote>
<p>Perhaps we need 3 ways for string representation:</p>
<ul>
<li>mere string representation</li>
<li>human readable representation</li>
<li>regenerating representation (as in <a href="https://blade.ruby-lang.org/ruby-core/23128">[ruby-core:23128]</a>)</li>
</ul>
</blockquote>
<p>I think I am in agreement, but I would like to amend the<br>
description of the three to confirm:</p>
<p>#to_s: String representing the object mainly for output<br>
#inspect: Internal details, ivars etc., mainly for debug<br>
#dump: Round-trip/evalable representation</p>
<p>The latter's usefulness is slightly questionable since, as<br>
was pointed out, one may round-trip through e.g. Marshal,<br>
but it could be assumed to be a 'lighter-weight' version<br>
(surely a less intimidating one) of the same.</p>
<p>Since String#dump already exists, perhaps a different name<br>
is in order for the latter. Call it #to_eval or whatever,<br>
but I believe these three offer the necessary granularity<br>
of semantics.</p>
<p>Is this an agreeable proposition?</p>
<p>--<br>
Magic is insufficiently advanced technology.</p>
<p>=end</p> Ruby master - Bug #1336: Change in string representation of Floatshttps://redmine.ruby-lang.org/issues/1336?journal_id=37472009-04-14T13:45:41Zrogerdpack (Roger Pack)rogerpack2005@gmail.com
<ul></ul><p>=begin<br>
currently (for curiosity sake) trunk does:</p>
<blockquote>
<blockquote>
<p>[1,2,3].to_s<br>
=> "[1, 2, 3]"<br>
[1,2,3].inspect<br>
=> "[1, 2, 3]"</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>-0.9<br>
=> -0.9<br>
2.1-3.0<br>
=> -0.8999999999999999<br>
2.1-3.0+0.9<br>
=> 1.1102230246251565e-16<br>
1.9-0.9<br>
=> 0.9999999999999999</p>
</blockquote>
</blockquote>
<p>I'd personally be all right with how it is now or with having .to_s round and .inspect either (not round or behave like .to_s does currently). As long as somehow or other users are alerted to that fact that "1.9-0.9 ain't one" (a fact slightly obscured previously).<br>
Thanks.<br>
-=r<br>
=end</p> Ruby master - Bug #1336: Change in string representation of Floatshttps://redmine.ruby-lang.org/issues/1336?journal_id=37482009-04-14T14:05:28Zmatz (Yukihiro Matsumoto)matz@ruby.or.jp
<ul></ul><p>=begin<br>
Hi,</p>
<p>In message "Re: <a href="https://blade.ruby-lang.org/ruby-core/23189">[ruby-core:23189]</a> Re: [Bug <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: Change in string representation of Floats (Closed)" href="https://redmine.ruby-lang.org/issues/1336">#1336</a>] Change in string representation of Floats"<br>
on Mon, 13 Apr 2009 13:12:13 +0900, Brent Roman <a href="mailto:brent@mbari.org" class="email">brent@mbari.org</a> writes:<br>
|<br>
|What does the current trunk output for (2.1-3.0).to_s ?</p>
<p>"-0.8999999999999999"</p>
<p>|Consider that (here at least):<br>
|2.1-3.0+0.9 == 1.110223024625156540e-16<br>
|<br>
|I'd like to be proven wrong, but I currently believe that the one cannot<br>
|create a human friendly Float string conversion that is also a regenerating<br>
|representation.</p>
<p>I agree with it. My opinion is that IF we need to get regenerating<br>
string representation, we need a method dedicated to the purpose<br>
(e.g. dump). I am not yet convinced we need such method.</p>
<p>And the current situation is #to_s and #inspect for floats share the<br>
implementation, so both methods give same representation.</p>
<p>The reason for the change (increased precision) was too many people do<br>
not understand the nature of floating point values on computers, and<br>
fall in error traps by illusion partly emphasized by dropping<br>
precision in string representations.</p>
<pre><code> matz.
</code></pre>
<p>=end</p> Ruby master - Bug #1336: Change in string representation of Floatshttps://redmine.ruby-lang.org/issues/1336?journal_id=37492009-04-14T14:22:58Zheadius (Charles Nutter)headius@headius.com
<ul></ul><p>=begin<br>
Yukihiro Matsumoto wrote:</p>
<blockquote>
<p>The reason for the change (increased precision) was too many people do<br>
not understand the nature of floating point values on computers, and<br>
fall in error traps by illusion partly emphasized by dropping<br>
precision in string representations.</p>
</blockquote>
<p>Well put. This is what I tried to get across in my too-long response.<br>
Don't hide the imprecision behind false precision, because it only leads<br>
to bugs.</p>
<ul>
<li>Charlie</li>
</ul>
<p>=end</p> Ruby master - Bug #1336: Change in string representation of Floatshttps://redmine.ruby-lang.org/issues/1336?journal_id=37502009-04-14T15:06:54Zshyouhei (Shyouhei Urabe)shyouhei@ruby-lang.org
<ul></ul><p>=begin<br>
Gary Wright wrote:</p>
<blockquote>
<p>I don't think it is even possible unless you introduce binary (or maybe<br>
hex) floating point literals. That is the only way you are going to be<br>
able to safely round-trip between an internal IEEE floating point value<br>
and a string representation.</p>
</blockquote>
<p>No that's not the only one. Take a look at <a href="https://blade.ruby-lang.org/ruby-core/23145">[ruby-core:23145]</a>. You can reach<br>
to the same answer when you happen to think that hexadecimal numbers are all<br>
representable in decimal. So are binaries. Not all decimal floats can be<br>
represented in binary, but all binary floats must have a corresponding decimal<br>
representation. That is sufficient for this situation.</p>
<p>=end</p> Ruby master - Bug #1336: Change in string representation of Floatshttps://redmine.ruby-lang.org/issues/1336?journal_id=37512009-04-14T17:22:59Zzenspider (Ryan Davis)
<ul></ul><p>=begin</p>
<p>On Apr 13, 2009, at 00:19 , Eero Saynatkari wrote:</p>
<blockquote>
<p>I think I am in agreement, but I would like to amend the<br>
description of the three to confirm:</p>
<p>#to_s: String representing the object mainly for output<br>
#inspect: Internal details, ivars etc., mainly for debug<br>
#dump: Round-trip/evalable representation</p>
</blockquote>
<p>I agree with this and thought/hoped that was the original intent of<br>
inspect.</p>
<p>In smalltalk (a stream-based IO system) they use #printOn: like our<br>
puts/to_s and #storeOn: for something like a meld of your #dump and<br>
#inspect. storeOn: outputs the code that would eval to an object equal/<br>
equivalent to the original (see below). Unfortunately, our #inspect<br>
for non-core objects don't default to a ruby expression.</p>
<p>I think #to_ruby would be a better name than #dump. It doesn't clash<br>
with Marshal/YAML and matches #to_s and friends.</p>
<blockquote>
<p>storeOn: aStream<br>
"Append to the argument aStream a sequence of characters that is an<br>
expression whose evaluation creates an object similar to the<br>
receiver."</p>
<p>aStream nextPut: $(.<br>
self class isVariable<br>
ifTrue: [aStream nextPutAll: '(', self class name, ' basicNew: ';<br>
store: self basicSize;<br>
nextPutAll: ') ']<br>
ifFalse: [aStream nextPutAll: self class name, ' basicNew'].<br>
1 to: self class instSize do:<br>
[:i |<br>
aStream nextPutAll: ' instVarAt: ';<br>
store: i;<br>
nextPutAll: ' put: ';<br>
store: (self instVarAt: i);<br>
nextPut: $;].<br>
1 to: self basicSize do:<br>
[:i |<br>
aStream nextPutAll: ' basicAt: ';<br>
store: i;<br>
nextPutAll: ' put: ';<br>
store: (self basicAt: i);<br>
nextPut: $;].<br>
aStream nextPutAll: ' yourself)'</p>
</blockquote>
<p>=end</p> Ruby master - Bug #1336: Change in string representation of Floatshttps://redmine.ruby-lang.org/issues/1336?journal_id=37692009-04-17T22:02:20Zrogerdpack (Roger Pack)rogerpack2005@gmail.com
<ul></ul><p>=begin</p>
<blockquote>
<p>In addition, the change actually attacked my some scripts... :-(</p>
</blockquote>
<p>Does it still break them? Can anyone give an example where the "more honest" #to_s broke their scripts (for my curiosity sake).<br>
It seems the general thought currently is that to_s should be "dishonest" and inspect should be "honest"? This would work well, as at least in irb users would know more precisely what was going on, while still preserving pretty output and backwards compat.<br>
Thanks.<br>
-=r<br>
=end</p>