No correct float calc although multiplied by 1.0 ?

[Tiles]

Again and again i battle with wrong results when working with floats. Rarely a right result. And i think i have found out now why. This :



results in 0.000000

I have to use

3*1.0/4 to get the correct result.

I am a bit frustrated at the moment. I thought you just have to put in 1.0 so that MMF knows to work with floats. This example shows that you also have to care and to test at which position you have to put the 1.0. This makes floating point value calculation in MMF to a gamble. Maybe you are lucky and it is correct. Or you are out of luck, and the result is wrong. Now go figure. You have put in the 1.0. So it should work.

That's not how it should be.

We have a "Float to Integer" command in the special object under conversions. Why not a "Use Float" command to tell the expression that it has to calculate with floats under all circumstances?

[Benicle]

I fought a similar battle earlier today, I had to add *1.0 to the end of each term in the expression to get it to operate in floats.

A little checkbox would surely be nice?

[Dynasoft]

It's not "telling MMF to work with floats" it's turning the number into a float.

Doing (3/4)*1.0 will break down into (3/4) (integer divide) = 0 (int result), then 0*1.0 (int*float multiply) = 0.0 (float result).

Doing (3*1.0)/4 will break down into (3*1.0) (int*float multiply) = 3.0 (float result), then 3.0/4 (float/int divide) = 0.75 (float result).

This is perfectly normal behaviour, and expected, in lower-level languages (like c++), but in MMF it's just confusing, especially when half the time you don't know whether the value in your counter is an int or float.

If clickteam made it so that in MMF int/int division always gave a float answer if the division didn't give an exact int result, it would be a lot less confusing for everybody.

[Sieg]

*Motion seconded

[Yves]

This is probably not possible due to the usual float rounding problems.

[Tiles]

Not possible? Ah, bad news. It would really dramatically decrease the whole floating point confusion when you can be sure that MMF really calculates with floats. Which you cannot always say the way it is now.

Thanks Dynasoft for the closer explanation. This helps me at least to understand why my first calculation resulted in 0.0. And will surely help me to avoid wrong floating point calculations in the future

From what i understand now the most secure way is to multiply every value in an expression by 1.0 to be sure it really calculates with floats. I can see my most annoying limit strike back with a grin at its face here. Expression too complex ... :grin:

[xyzzy]

it's basically just how the order of operations are handled; dynasoft explained some about how it works

since both division and multiplication have the same importance, they'll be calculated from left to right

so yes, 3 / 2 * 1.0 will give you 1.0, since the division is first, so just use parenthesis for 3 / (2 * 1.0) for 1.666...

every fraction in your expression needs to have at least one operand as a float, if you want it to return a float

[The_Alee]

I even asked jeff once why i was having a certain problem with floats. He didn't know

Its all a bit of a grey area. We should get some kind of article to point people to when having these problems.

[James]

Jeff is the US sales manager, not a programmer- I'm not sure if him not knowing is anything to about.

[DavidN]

I have enough difficulty myself - it's not an easy task to predict how floats will behave in most languages.