Is this a floating point thing?

[clepsydrae]

Considering this:

slider1:25<0,100,1>

@slider

var_a = (slider1/1000)*srate+.5;        //debugger shows 1103
var_b = floor((slider1/1000)*srate+.5); //debugger shows 1102
var_c = floor((25/1000)*srate+.5);      //debugger shows 1103

Should I assume this is a floating point math thing? I.e. the 25 coming from the slider is infinitesimally smaller so the "1103" the debugger shows is actually just shy, hence the floor() to 1102?

[geraintluff]

Yes, that's a floating-point thing. Dividing by any number apart from a power of 2 is going to be a little bit approximate.

The debugger rounds the values for display - you can get a more detailed output using @gfx:

@gfx

gfx_x = gfx_y = 10;
gfx_r = gfx_g = gfx_b = 1;
gfx_printf("var_a: %.15f\nvar_b: %.15f\nvar_c: %.15f", var_a, var_b, var_c);

You need 15 decimal places of display to see that, though.

This means that if (as in your example) you round to the nearest integer using "floor(x + 0.5)", then values of x exactly halfway between two integers can go either way, depending what calculations you took to get there.

[mschnell]

That is why in eel a compare with "a == b" is done with a reasonable approximation, while to do an exact compare you do "a === b".

The short way of forcing (not too large) integer is "a |= 0;"

-Michael

[Justin]

I'm guessing that the reason this differs:

floor((25/1000)*srate+.5)

Is because 25/1000 is pre-calculated and stored in 64-bits, vs

floor((slider1/1000)*srate+.5);

slider1/1000 preserves the full results (80 bits in the FPU), then multiplies it by srate.

To test this theory, you can either rewrite it as:

floor((slider1*srate)/1000+.5);

Or you can try adding this near the top of your script (not recommended for production code though!)

//#eel-no-optimize:1

(This will remove all kinds of optimizations including value pre-calculation).

[clepsydrae]

Originally Posted by Justin

I'm guessing that the reason this differs:

Thanks! -- reordering the computation confirmed your theory. //#eel-no-optimize:1 had no effect, though.