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

12 posts
• Page **1** of **2** • **1**, 2

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

:-J

August 2015 - I misplaced a lot of links - I will try to find backups and repost. If You find a post that interests please reply to post with @rampackwobble and I will get a nudge!

If you find my posts useful please consider donating something to a local charity or to the http://www.mndassociation.org/

If you find my posts useful please consider donating something to a local charity or to the http://www.mndassociation.org/

**Posts:**1,194**Reputation:**30,832

B

64
S

33
G

47
[QUOTE=liaeb] LOL I get 65! does it round up then?![/QUOTE]

^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?

^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?

**Posts:**5**Reputation:**135

B

1
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?!

im confused

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?!

im confused

**Posts:**112**Reputation:**1,827

B

9
S

3
G

1
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

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

**Posts:**5,274**Reputation:**69,959

B

92
S

32
G

107
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.CakeSpear 2014-01-14 19:39:37

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.

**Posts:**5**Reputation:**135

B

1
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

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

**Posts:**112**Reputation:**1,827

B

9
S

3
G

1
12 posts
• Page **1** of **2** • **1**, 2

## Who is online |

Users browsing this forum: dop2000 and 67 guests |