Simple question

Hi

I have a simple question

If you in Constructdo this calculation

64999966 / 1000000

What is the output?

( I know what the anwer aught to be, but im wondering what the actuall output is in Construct )

Thanks

Create a text-object and make this event:

system on start of layout- set text: 64999966 / 1000000

and see for yourself.

Well I must be doing something wrong - I keep getting "42" as the answer (but then again I am not sure of the question...)

:-J

LOL I get 65! does it round up then?!

LOL I get 65! does it round up then?!

^This is my point exacly

Other similar software return the same, slightly, "faulty" result ( for this particulr calculation, and maybe other calculations as well ).

Game Maker ( another creation software ) however, returns correctlt 64,9999660000

Im trying to create a relatively delicate system, and slight inaccuracies like this result in my objects being a pixel off in certain situations ( which in my particular case is quite bad ).

What im more interested in knowing is:

• Whats the reason for this inacurracy?
• Is it related to computers general inability to handle certain numbers accuuratly?
• Is there any way i can fix or work around this ( in Construct or in general )?
• Is there an 'efficient' way i can move the decimal point of a set number, without doing a divisio?

well i'm rubbish at math but its seems to be defaulting the Round expression?!

I've got you a bit closer 64.9999999996 but that has issues of its own, the global var number can't even handle beyond the 9 decminal places in the pi expression its seems to be rounding too?!

<img src="https://dl.dropboxusercontent.com/u/5480026/Capture.PNG" border="0" />

im confused <img src="smileys/smiley11.gif" border="0" align="middle" />

TBH I think your "relatively delicate system" is actually a "REEEALLY delicate system" what are you even planning to do with that level of accuracy?!

It appears to be a bug that probably should be reported. This is what CC did which I'm pretty sure C2 does as well: When the events are processed to be usable by the runtime constants in expressions are collapsed. So "64999966 / 1000000" is evaluated and the result is used in place. I suspect some lower precision math is used there. Once past that there is no issue with math in JavaScript because numbers are represented by 64bit floating point values to the best of my knowledge.

You can also prevent constants from being combined when exporting and previewing by making a global number called "one" with a value of one and use that global in between constants. So your expression would look like:

64999966*one / 1000000

Thank you very much for your insight in this R0J0hound!

However i dont quite understand your every word.

"When the events are processed to be usable by the runtime constants in expressions are collapsed. So "64999966 / 1000000" is evaluated and the result is used in place."

What are the runtime constants?

What does it mean that expressions are collapsed?

...

"You can also prevent constants from being combined when exporting and previewing by making a global number called "one" with a value of one and use that global in between constants. So your expression would look like:

64999966*one / 1000000"

Im not very good at construct.

Does this solution provide an accurate correct output?

...

Is there no other way around this, say for example an efficient way of just moving the decimal point to the left for example?

Thanks again, i really want to try and understand this.

I'd like to understand this too!

Like I previously mentioned before math isn't my strong point but my assumptions normally get me a starting point :)

Therefore I'm assuming runtime constants are just "constants" in the mathematical context that there static values, i.e. they don't change?!

Not sure what the collapsing of expressions are maybe there the result values enumerated from the expression?!

In answer you your question tho CakeSpear yes the 64999966*one / 1000000 (one equalling 1) does seem to provide a more accurate result in 64.999966

I missed a comma there between "runtime" and "constants". 64999966 and 1000000 are constants. By collapsing I mean that 64999966/1000000 is replaced by 64.999966 to avoid needless calculations. The thing to note is the calculation is done before runtime, which is where the issue seems to lie.

By using a variable between two constants the calculation is all done at runtime.

And yes by doing the second bit it does give the correct output.

See the bug report for a capx:

http://www.scirra.com/forum/constant-folding-percision-issue_topic84055.html