Zero point zero isn't zero

[TheLogFather]

Try subtracting zero from 0.0 (e.g. put into a say block).
Or try ceiling of (0.0). :/

See this topic: http://scratch.mit.edu/discuss/topic/79402/

Also, see this project: http://scratch.mit.edu/projects/36859670/

[cpseager]

This ia common issue in any computer language - it's a floating point versus integer thing.

The 0 is a Number type, but is internally stored as an Integer because there is no decimal point.

The 0.0 is also Number type, but due to the decimal point is now internally stored as a floating point instead, and as with all floating point numbers gets rounded a little bit, in this case to:

2.3283064E-010
(0.00000000023283064)

The solution is for Scratch to round the floating point numbers to less decimal places before using them:

 var setPrecision:Function = function(number:Number, precision:int) {
   precision = Math.pow(10, precision);
  return Math.round(number * precision)/precision;
 }

[TheLogFather]

Oh, I see where it's happening:

http://github.com/LLK/scratch-flash/blob/master/src/blocks/BlockArg.as#L231

Hmmm...

Maybe another way to 'signal' that it's a float rather than int might be to extend "isNumber" so it's no longer just true/false? E.g. zero, one, two mean, respectively, non-numerical, integer, float? Or add a new boolean "isFloat"?

[cpseager]

Yes, seems very strange that the Scratch code is deliberately introducing a mathematical error to workaround that Flash is (correctly) deciding that 4.0 is the same as 4 and so defining it as an integer!

[kaschm]

@cpseager, @TheLogFather - thanks for submitting this issue. We're looking into why this was set up in this way; the code predates most of the team :) Stay tuned for an update.

[cpseager]

See
https://github.com/LLK/scratch-flash/blob/master/src/primitives/Primitives.as#L99

I guess it was assumed that if you wrote something like 4.0 you wanted to work to 1 decimal place rather than as an integer - but this particular routine checks both parameters to see if they are both integers and then gives a different result then if they were floats.

However deliberately introducing a mathematical error for everything to workaround this particular 'random' command result is probably not the correct way to handle this!

[TheLogFather]

And I guess https://github.com/LLK/scratch-flash/blob/master/src/blocks/BlockArg.as#L164 is why large integer args typed into some blocks will quite often get ".0" appended to them for no apparent reason. I've wondered about that for quite a while...

It'd be nice to iron out these idiosyncrasies.

Does anyone know of another block (i.e. apart from "pick random") that behaves in a different way depending upon its args being int vs decimal?