 1. ## Inacurate calculations?

Hi
Why, in MMF, does this calculation:
-64999966.0/1000000.0
equal
65

While:
7.0/2.0 = 3.5

???  Reply With Quote

2. Unsure if this is the kind of thing i should post in the Bug Tracker, or if i should wait for someone to confirm some sort of Limitation.
Will try to isolate the problem further, later today  Reply With Quote

3. WINDOWS CALCULATOR
64999966.0 / 1000000.0 = 64.999966
6499996.0 / 1000000.0 = 6.499996
649999.0 / 1000000.0 = 0.649999

MMF2 CALCULATION
64999966.0 / 1000000.0 = 65
6499996.0 / 1000000.0 = 6.5
649999.0 / 1000000.0 = 0.649999

...
I figured it out.
MMF2 can only handle 6 decimal digits.
Any digit after the 6th will 'round' the previous digit up or down, and then remove itself.

Example:
0.999999 = 0.999999 ( 6 digits )
0.9999991 =0.999999 ( rounds down )
0.9999999 = 1 ( rounds up )
0.9999995 = 1 ( a 5 rounds up )

Is it possible to make MMF2 have greater precission then 6 digits somehow?  Reply With Quote

4. 1. You could try multiplying the number by 1000 or similar, then doing the calculation.
2. You could use the Developer-only "Double Precision Calculator" object which does calculations to 16 significant digits.  Reply With Quote

5. Im sorry, i seem to have been wrong about my previous post.

My previous post holds true when trying to set a value in MMF2.
MMF2 can display 6 decimal digits.
Digits after the 6th only rounds the previous digit up or down, it is then removed.

Example:
Set value to...
0.999999 = 0.999999 ( 6 digits, no change )
0.9999991 =0.999999 ( rounds down )
0.9999999 = 1 ( rounds up )
0.9999995 = 1 ( a 5 rounds up )

...
However, unless im mistaken, calculations seem to handle in a different manner in MMF2.

EXAMPLE A
64999966.0 / 1000000.0 = 64.999966 ( 6 decimal digits )

MMF2
...Should be able to handle 6 decimal digits right?
64999966.0 / 1000000.0 = 65 ( MMF2 rounds up, why? )

EXAMPLE B
Lets look at a smaller calculation

64999966.0 / 10.0 = 6499996.6 ( 1 decimal digits )

MMF2
64999966.0 / 10.0 = 6.5e+006 = 6500000 ( MMF2 rounds up, why? )

...
Im trying to create quite a delicate system which needs to be as accurate as possible, at the very least consistent.
If i do not understand the way MMF2 handles numbers and calculations its gonna be hard for me to create what i want, and even troubble shooting my results becomes hard.

Why does MMF2 round the ressults i the examples above ( Example A and B )?
An explanation as to how MMF2 handles such calculations would be most welcome, so that i may better create systems with consistent results.
Thanks  Reply With Quote

6. At first i thought this inaccuracy was attributed to computers general inability to handle some types of numbers ( like 0.1 for example )
But when i asked someone to test this calculation ( 64999966.0/1000000.0 ) in Game Maker ( another game making program ), the output was 61.9999660000

So...Is this a MMF2 bug then?
Or is there another explanation for this?  Reply With Quote

7. In MMF2 and MMF2.5
649999666.0 / 1000000.0 = 65
It should equal 64.999966

DISPLAY VS ACTUAL VALUE

- I set a Counter, an Expression and an AltValue to 649999666.0 / 1000000.0
- In either case, the display is 65 which is wrong ( displayed through Counter or String )

- However, if i make an Event that compairs either one ( Counter, Expression, or AltValue ) to 64.999966, the Event triggers, meaning the actual value IS 64.999966

STRANGE RESULTS

- I have an Object
- AltValue A = 64999966.0 / 1000000.0
- AltValue B = 0

When pressing SPACE, 'AltVal A' is added to 'AltVal B'

- Displayed through either a Counter or a String, 'AltVal B' is increased by a flat 65 for each SPACE press

However, there are exceptions/ unexpected results:
- At the 15th SPACE press, AltVal B displays as 974.999 ( when it should display as 974.99949 )
- After the 15th press, 'AltValB' continues as normal for a while ( 1040, 1105, 1170 etc )

- Then again at the 148th, 149th, 150th, 151st, 152nd, 153rd SPACE press, 'AltValB' displays as:
9619.99 , 9684.99 , 9749.99 , 9814.99 , 9879.99 , 9944.99
When the correct output/ display should be:
9619.994968 , 9684.994934 , 9749.9949 , 9814.994866 , 9879.994832 , 9944.994798
- After the 153rd press, 'AltValB' continues as normal for a long while ( 10010, 10075, 10140 etc )

I dont really know what is actually happening here, but i would expect correct outputs/ results from a creative software like this for such basic calculations.
Think about what this could mean for physics simulations, educational software or advanced systems.

MMF2 Build 257.24 ( limited test done in MMF2.5 )  Reply With Quote

8. 1. Dealing with large floating-point numbers is hard for computers. Increased accuracy comes at the cost of processing time and memory usage, and it is usually not needed or worth the 'cost'. In some sense there is no such thing as a 'basic' calculation when dealing with floating point numbers. As http://www.opto22.com/documents/1755...nical_Note.pdf puts it: "Squeezing infinitely many real numbers into a finite number of bits requires an approximate representation. Most floats cannot be exactly represented using this fixed number of bits in a 32-bit IEEE float. Because of this, rounding error is inherent in floating-point computation".

2. I don't think comparing 64.999966 with another number tests whether they are both 64.999966 if they both round to make 65. I think comparing 64.999966 to 64.999966 may in effect be comparing 65 to 65.

3. For calculating with extra precision try the Double-Precision Calculator object.

4. For storing precise floating-point numbers I think the best option would be to store them as text (which is what the Double-Precision Calculator deals with), e.g. in an Alterable String rather than an Alterable Value.  Reply With Quote

9. As i mentioned earlier GM handles the calculation acurractly, same as the windows calculator.
Maybe they have some internal way of fixing this inconsistency then...

I tried using the Doubble precission Calc:
Val(Div\$( "Double-Precision Calculator", "64999966.0", "1000000.0"))

But i still get 65 as a result...
Is there no way around this?  Reply With Quote

10. A partial fix is not to use "Val". If you keep it as a string then Div\$( "Double-Precision Calculator", "64999966.0", "1000000.0") equals "64.999969482421875" (which is an improvement over 65).  Reply With Quote

#### Posting Permissions

• You may not post new threads
• You may not post replies
• You may not post attachments
• You may not edit your posts
•