2014-07-12 13:42 GMT+02:00 Andres Valloud <avalloud@smalltalk.comcastbiz.net>:
Well ok, so letting 1 / 2 = 0.5 answer false has nasty side effects. Why is that? ��Isn't the code that breaks trying to tell us something? That's what I've been trying to point out. ��Why rush to defend numerically unstable code? ��What are we going to preserve, and what will be the example given to others?Being consistent then means either abandonning 1/2 = 0.5 but we saw this
has nasty side effects.
Andres.
��
What apparently breaks Pharo graphics is letting (1 comparisonOp: 1.0) = false in Float>>adaptToInteger:andCompare:(maybe my mistake, I should�� ^ operator = #~= rather than ^false)
At this point, we can't tell that the code is numerically unstable.Maybe the Float are very well formed and sufficiently away from int, or exactly equal to int...Only if we see off-by-one errors can we conclude that there are design mistakes.
Or if we perform a deeper analysis, but it ain't going to be easy.
To know where it happens, we would have to instrument code (no static typing).It's not un-interesting.But it's going to waste a lot of time for a problem we don't yet have...