> I have given enough arguments and should let other people express
> their opinion without fearing an agressive response :)

In my opinion the behavior should exactly match the underlying binary  
representation of floats, otherwise I get results where I feel the  
system is 'fuzzing' while I didn't tell it to do so and I start to  
feel uneasy.

So where VisualWorks does
  (13/10) = 1.3 "true"
it makes me cringe, OTOH where it does
  1.3 = 1.3d "false"
it makes me feel right at home.

At the heart of the matter is that we use /decimal/ floating point  
notation to represent /binary/ floats, and the issues (surprises for  
some people) of approximation should be put at exactly that conversion  
place and not compensated elsewhere -- this way we get a system with  
the least surprises.

I am too new at Squeak to know how well separated #displayString  
(application behavior) and #printString (tools behavior) are, but it  
might help if the tools clearly show when the #printString of a float  
is approximate by prepending a ~ for example:

1.3 printString "~1.3"
1.0 printString "1.0"



Regarding #asExactFraction I'd say that is an ugly pleonasm but more  
importantly it is confusing (it suggests that #asFraction is fuzzing),  
hence it should be deprecated; #asFraction should do an exact  
conversion IMO.



R
-


_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Reply via email to