On Fri, Mar 7, 2014 at 11:17 AM, Mark H. Harris firstname.lastname@example.org wrote:
Well, clearly s1 is wrong. And yet, s1 was coded by giving the system a normal human number, at a human level, and very innocently s1 is really badly broken but not immediately noticed until we try to square it...
s2 on the other hand is correct, but we had to go through some hoops to make sure that the system received the correct type. The system should be able to make this determination without the user having to determine types.
Once again, the problem occurs only because you're using a float literal, and 2.01 can't perfectly round-trip.
That's pretty much the value you had (I have a few more digits there, the square rooting and squaring probably cost some accuracy), so I'd say Decimal correctly round-tripped. The problem is the conversion from string (source code) to float to Decimal. You think that str()ing a float gives you a better round-trip, but that works only because you're using relatively small numbers.
Hmm. Is the rounding done by float.__str__() an attractive nuisance? Would it be better to show exactly what's stored, if only to remove the temptation to treat str(f) as "more correct" than f?