Floats again...

[sharma.narender]

Is there any valid reason for
8877.9 * 0.75 = 6658.425
to return false ?

I can see that although both numbers look equal as far as printString is concerned but their bits are different.

Thanks!

[marten]

The valid reason is simple: an "=" compare based on floats may return true or false.

You can not count on the these results in general in all programming languages. Therefore the simple summay is: do NOT compare float values on equality. Even with ">" etc you may get problems.

You have to compare against a delta range - then you are on the right side. Please have a look at DhbNumerics at vastgoodies.com about this topic.

Is there any valid reason for
8877.9 * 0.75 = 6658.425
to return false ?

I can see that although both numbers look equal as far as printString is concerned but their bits are different.

Thanks!

[tc]

Hello,

Here is a good discussion on the subject:

http://groups.google.com/group/ibm.software.vasmalltalk/browse_thread/thread/ef5b3a9be1795a5/ccd1754f098016bf

I tried the example, '8877.9 * 0.75 = 6658.425', in VisualWorks, Pharo, and Java (two equals, ==). They all returned false.

--tc

[PhotonDemon]

Hi Narender,

To take these comments one step farther, you should consider your need for floats. Float arithmetic in hardware is fast but it comes at the cost of not being precise. Converting from strings floats is slow (compared to Smalltalk's ScalledDecimals or Fractions) so, if you are doing a lot of converting from/to strings and not much computing, you loose the speed advantage.

If floats are not what you really need take a look at ScalledDecimals or Fractions:

8877.9s1 * 0.75s2 = 6658.425s3
true

88779/10 * 3/4 = (6658425/1000)
true

For your example they both return true.

If you are working with money ScalledDecimals are good. They are kept as an array of decimal bytes so they take up more memory than floats and Fractions but are very good for keeping things to the penny.

Fractions are kept as two integers, a numerator and denominator (small or large as needed). I haven't tested this but I think they can be very fast. Most math with fractions can be done without doing a divide (which is slow). If you think back to playing with fractions, you will remember that most of the time numerators and denominators got multiplied or added. If a division was asked for the numerator and denominator got flipped and you are back to multiplying.

Anyway, see if you really need floats. If you don't, Smalltalk has other nice alternatives.

Lou

[sharma.narender]

Hi All, Thanks for your inputs this was a good discussion about floats.

[sharma.narender]

DhbNumerics has a cool method "relativelyEqualsTo: aNumber upTo: aSmallNumber". I think this should solve the problem with Equality over a delta range. Thanks Martin

But I could not find a method that could round the Floats in the "DhbNumerics" application. Are you aware of an implementation of "roundTo:" that does rounding correctly? Lets take the original example that I posted

(8877.9 * 0.75) roundTo: 0.01 gives 6658.42
but
6658.425 roundTo: 0.01 gives 6658.43

Form a users prespective 6658.43 is the correct result.

The way we have resolved is to add a delta(at least 0.00000001) to the number that is to be rounded and then convert it to scaled decimal. We also convert the "roundTo:" message to scaled decimal and then call the "roundTo:" method. This gives us correct results. Is there a better way to do this (i.e. without making use of the scaled decimals) ? Martin/PhotoDemon/tc any ideas ?

[sharma.narender]

One more question...
Should I consider that "relativelyEqualsTo: aNumber upTo: aSmallNumber" will be symmetric and transitive for a given delta(aSmallNumber) ?

[PhotonDemon]

Hi,

You are still fighting the same inaccuracy problem of floats. The problem isn't with #roundTo: but with the slightly inaccurate value of a float after doing some math with it. You can play around with ways to round your results but in the end I don't think you will be happy.

Your example requires that you add a small amount to a float so that when you round it you get a value that you like. But, you could just as likely have a float that you have to subtract a small amount from to get a value that you like. Don't ask how you can tell when to add or when to subtract

If you could tell us a little about the source of your floats or what you are trying to do with them, maybe we can make some suggestions.

Lou

[marten]

Could not have said it better - I think, we can see here a structural problem of an application - change the data structure to meet your problems and yes I know, this is easily be said and it will perhaps not be possible.

You are still fighting the same inaccuracy problem of floats. ... You can play around with ways to round your results but in the end I don't think you will be happy.