On 11/01/2016 07:28 AM, test wrote:
Hi Martin, thanks for this analysis, i really appreciate it. you did proof that, as you said "1.2000000000000002 *is* the correct answer for 1.19 roundTo: 0.1.". please excuse me - i seriously think it was very friendly of you to do this detailed analysis -, but my argument never was, that if i use Float>roundTo: this produces problematic floating-point-errors. if it produces floating-point-errors they wouldnt be unexpected. i thought this would be clear from my previous posts. what i tried to say is, that i am a simple user and pharo shouldnt expect from me, that i know, that if i want a result looking a bit more like 1.2, i should use "(x asFraction roundTo:(1/10))asFloat" instead of "x roundTo:0.1". the #round: method circumvents the irritating part of Float calcs imo in an inexpensive way, and rounding numbers is imo not a very exotic task, but to presume that i figure out (x asFraction roundTo:(1/10))asFloat by myself is simply expecting too much from me. otoh now i that i know how to do it, it's not a problem for me, if the majority wants to deprecate #roundTo:. Thank you again for the careful analysis werner
Hi Werner, Thanks for your comments. I posted the analysis because I did the analysis (and thought some others might want to see it), and I did the analysis because I wanted to find out whether that answer was right. Some Smalltalks are pretty bad in similar areas of Float handling. But aside from all the fine points, if you want a floating-point number to "look" nice and human-readable, (x asFraction roundTo:(1/10))asFloat will work, but I still recommend not rounding the number itself, but rounding the printing of the number. This is not a Pharo thing, it's an any-language-with-floats thing. In C you have printf, etc. In Pharo, you can use for instance: 1.19 printShowingDecimalPlaces: 1 ==> '1.2' This makes it easier for someone reading the code to see the intent. Regards, -Martin