Zugg Software :: View topic

Posted: Tue Mar 01, 2011 9:14 am

In the below example, skills are represented on a scale of 0.00-100.00.

Is there a reason why $change will not show having a value of 0.01?

Wizard Joined: 26 Mar 2008 Posts: 1547

I noticed something odd where after, say, 4 or so decimal places, it begins to try and store the values in scientific number form, at least in database records, which was extremely aggravating to deal with. I've no idea why it's having issues with two decimal places though.

Wizard Joined: 22 Mar 2007 Posts: 2320

The answer is in the nature of floats. Floats are not exact. You probably already know this. Due to the binary nature of floats in the computer, there is a slight error when translating a decimal float into binary. Then, when doing arithmetic calculations which in decimal appear equivalent, the error in the binary values results in very tiny differences in the result. In your example, %float(11.23-11.22) might result in 0.009999999...99, while %float(23.63-23.62) might result in 0.10000000...01 (examples only--the actual values will be different, and may even be different on different computers!). Comparing these numbers will then show them not to be equal. This is true in all programming languages, and is an inherent limitation on using floats. This is why many languages have an 'approximately equal to' operator for floats.

To solve this, you will have to change them out of floats. Multiply the values by 100, round off, and convert to int for your comparison.

Posted: Tue Mar 01, 2011 2:15 pm

Don't know if this will work, but you could also try putting the %norm() function around your calculation.
I.e:
#SAY %norm(%float(11.23-11.22))
#SAY %norm(%float(23.63-23.62))

Posted: Tue Mar 01, 2011 2:40 pm

Yet calculators get around these limitations on a daily basis...
Finding a kludge for this error is simple enough...
But i don't want to have to have my code doing tricks and flipping the numbers just to show 0.01 - this is BASIC math, CMUDPro should be capable of this

Wizard Joined: 22 Mar 2007 Posts: 2320

Calculators do _not_ get around these limitations. Calculators round things off when they display the results to you. The limitations only show up when you use comparison operators, or other things that calculators do not have. This is basic math in the decimal world, but it is _not_ a trivial problem when dealing with floats in the binary world. As I said, all programming languages have this problem. It is fundamental to binary floats. How do you suggest that the problem be solved?

As an example:

Posted: Tue Mar 01, 2011 5:46 pm

Wizard Joined: 22 Mar 2007 Posts: 2320

I'd forgotten that Cmud automatically norms floats in comparison operations. Puts it one up on a lot of programming languages!

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

Posted: Wed Mar 02, 2011 9:10 pm

Well.. %norm doesn't seem to change the data much at all
%round only returns integers.

Essentially you are telling me there is no way to do this precisely without converting it to integer math?

A calculator may be doing all these tricks inside its (incredibly small and weak) computer mind, but i bet i can punch in 22.33 - 22.32 and get 0.01 regardless of brand or age.

P.S. I did find a way, although I don't see why it needs me to tell it to do this: %format(&3.2f, $change)

P.S.S. Granted, i only program as a hobby... but i always just inherited someone else's math code into my programs, so I never noticed issues with floating point math.. it just never came up.

Wizard Joined: 22 Mar 2007 Posts: 2320

Posted: Wed Mar 02, 2011 9:34 pm

#SAY %norm(%float(11.23-11.22))
0.00999999977648258

#SAY %format(&3.2f, %float(11.23-11.22))
0.01

#SAY %format(&3.9f, %float(11.23-11.22))
0.010000000

Once i format it, regardless of the decimal precision i ask for, it always gives 0.01.
Should not the 9 decimal precision show 0.009999999, given the unformated value?
Granted... i like seeing the true value, but i don't understand why the results are changing.
//Nevermind, it is rounding to the decimal here instead of truncating as &3.13f shows.

Posted: Wed Mar 02, 2011 9:50 pm

After a bit of research I came across this...

The "decimal" data type of the C# and Python (programming language), and the IEEE 754-2008 decimal floating-point standard, are designed to avoid the problems of binary floating-point representations when applied to human-entered exact decimal values, and make the arithmetic always behave as expected when numbers are printed in decimal.

Is there an equivalent in perl that could be added to CMUD?

Posted: Thu Mar 03, 2011 5:15 pm

I have no plans to add a "decimal" type to CMUD, sorry. That would be a huge amount of work.

%norm "fixes" the numbers so that they can be properly compared by ensuring that the last few significant digits are rounded.

I might add an argument to %round in the future to specify the number of decimal places to round to.

Posted: Fri Mar 04, 2011 8:27 am

I actually tried throwing in a ,2 when testing it out, just to see if that was an undocumented feature. That would be a quite useful addition.