We should probably detect numbers whose printform has a long string of 0s or of 9s followed by one or two other digits and round them internally. Doing that sort of rounding is Officially Incorrect but nobody's going to run actual moon shots (as opposed to simulated ones) from programs.
PS It's not really JS's fault either. It's the fault of the denseness of rational numbers, so any floating point bit pattern represents an infinite range of possible values, even not counting irrational values within that range. I believe that standard algorithms print the median value in that range; instead we should print the simplest (lowest denominator) rational in the range. But I'm not a floating point expert.
No, the idea isn't to round what the reporter reports. You want to change two things: (1) the conversion to print form, for watchers and speech balloons, and I guess JOIN too, to look for consecutive zeros as I suggested above; (2) the comparison predicates, allowing some fuzz. I think it would be okay to take the two floating point values, zero the rightmost two or (living dangerously) three bits of both, and then do the equality comparison. Well, a little smarter than that so if the three rightmost bits are 111 then you add one to the next higher bit. For less or greater comparisons, first do a rounded equality comparison, and only if that says false, compare the unrounded values to see which is greater.
Hmm. I think that for most purposes, a modest (two-bit) floating point rounding (as opposed to a fixed fuzz amount) would make kids happier. Not if they're trying to add infinite series or something, maybe.
I've long thought that for text strings the IS IDENTICAL TO block should do case-sensitive comparison, so people can choose which they want, while making the right thing be the thing you get without thinking about it. Maybe we should do something similar for numeric comparison? The = block would round a little, and the IDENTICAL block wouldn't?
I thought at first that this could be misleading, but after a split second I realized that no one is going to compare 76.000000009 and 76.000000123 with "=" to see if they are identical. When you handle numbers like this ones in a computer it is obvious that they are subject to internal approximation, so a perfect comparison is something that I think no one is going to ask for. The usage of IDENTICAL can then be a good compromise if you really are willing to make a perfect comparison.
How about having both versions (of the ">" and the "<") reporters, as well? The vanilla flavor of the reporters could then do the rounding before comparing the values, while the spicy (i.e. the precision / unrounded) version of the reporters would not do the rounding before comparing them?
You can't have an "exactify" option like that unless you invent a visible modification to the block; for example if you click "ringify" the block gets a ring around it!
There are too many cases like this in the language. Consider the trig functions; what if you want radians? The Logo solution is to have RADSIN, RADCOS, RADATAN. But you could imagine a global use-radians flag, or you could imagine a "radians" option like your "exactify" option.
I think we need to think of a beautiful elegant way to handle all such cases. :~)
I agree that a general solution is needed. In the meantime, if I move a sprite to a specific pair of coordinates and then I immediately check if the sprite's coordinates are the ones I moved it to just, the "=" operator MUST be true. Otherwise the language would seem inconsistent. I can accept that the test is false only when I'm moving the sprite by using the MOVE STEPS block and directions other than 0,90,180,270
Sure, I could, but I don't agree. If the script "GO TO 10 10; SAY X POSITION" doesn't give 10 as a result, the user will think that Snap is not working. This is what I thought, even being in CS since 1979.