[Newbies] Re: [BUG] Inconsistent float soustraction

Sun Feb 17 21:41:24 UTC 2008

I don't know which university you went to, but I certainly never observed
any serious attempt to enforce such a rule at university. That said, it's a
good one for all of us to learn if we don't apply it already.

On Feb 17, 2008 8:56 PM, <johnps11 at bigpond.com> wrote:

> Cedric,
>
> Part of the issue is that different architectures will have different
> values for machine epsilon (1e-09 in your post).  Machine epsilon is
> defined to be the largest float such that
>
> 0.0 + epsilon = 0.0
>
> Its value varies according to your machine though - typically a machine
> with a much larger machine word size in its floating point processor will
> have a much smaller machine epsilon. (The following is an example of a
> Simple Lie, for an introduction to the Complicated Truth I suggest you get
> hold of a book on Numerical Computation, which is an important study in
> Computer Science).
>
> Things are complicated further in that in any radix based number system
> there are very simple numbers that cannot be written exactly.  In the
> decimal number system any fraction with a denominator relatively prime to
> the radix tends to be an infinitely repeating fraction. 1/3 or 3/7 are
> examples.
>
> Computers use binary numbers inside. 1/10 is not expressible as a
> nonrecurring binary fraction, nor is 1/3, 3/10, 2/5 or 1/20.
>
> Squeak does a good job of trying to promote numbers to ScaledDecimals, but
> they are much more expensive to calculate than IEEE floats or Integers.
>
> If we repeat your examples using Fractions we get
>
> 1 - (2/10) - (5/100) - ( 3/10) - (1/10) -(1/10) = (1/4) true
>
> because Fractions are exact - in fact the definition of equality for
> fractions is defined to be
>
> ( a/b ) = ( c/d ) if and only if ( a * d ) = (b * c)
>
> which only uses Integer and BigNum arithmetic and allows arbitrary
> precision (unless the numbers are so big you run out of memory).
>
> Your idea of redefining equality for floats is a very bad idea because (1)
> it assumes all hardware has the same value for machine epsilon and (2)
> will break 50 years worth of programs that do numerical computation.
>
> The simplest rule is any attempt to test floats (or doubles, or IEEE
> decwords) for equality is a bug.  If there's a decimal point in your
> calculations (or if there could be) then don't test for equality.  This is
> taught to computing students at University in the first few weeks.  Any
> work done by a Uni student who breaks this rule gets marked down very
> severely!
>
> I commend you on discovering this on your own by the way - it shows an
> inquiring mind.  It's not everyone who hits one of the key issues in
> Computer Science by themselves, and then thinks about it.
>
> Yours,
>
> John.
>
> >> > Hi,
> >> >
> >> > I noticed in my image (damien last beta so 3.10 - windows XP and
> >> > Vista) that I have a strange bug when soustracting floats
> >> > successively. Here is how I reproduce it in a workspace:
> >> >
> >> > 1 - 0.2 -0.05 -0.3 = 0.45 "true"
> >> > 1 - 0.2 -0.05 -0.3 -0.1= 0.35  "true"
> >> > 1 - 0.2 -0.05 -0.3 -0.1 - 0.10= 0.25  "*****false*****"
> >> > 1 - 0.2 -0.05 -0.3 -0.1 - 0.10= 0.24999999999999995   true
> >> >
> >> > or again:
> >> > 1 - 0.1 = 0.9  true
> >> > 1 - 0.1 - 0.1 = 0.8 true
> >> > 1 - 0.1 - 0.1 - 0.1 = 0.7 false
> >> >
> >> >
> >> > Can somebody explain that or is it a bug ? I don't know yet if it's
> >> > specific to my image, so does other have the same behavior?
> >> > I can force the rounding of the result but find it strange.
> >> >
> >> > Cédrick
> >
> > 2008/2/17, danil osipchuk <danil.osipchuk at gmail.com>:
> >> This is not even squeak specific. Decimal floats not always can be
> >> represented precisely in binary form:
> >>
> >> http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems
> >>
> >
> >
> >> Hi Cédrick,
> >>
> >>         if you need to operate with exact precision just don't trust
> >> floats. Use ScaledDecimals instead. In Squeak ScaledDecimals are
> >> implemented with the fraction so it's matematically stronger
> >> than floats. Use floats at presentation or user interface time
> >> and evade them at domain model.
> >>
> >>         cheers,
> >>
> >> Sebastian Sastre
> >
> > uhm ok, good to know.
> > Actually, it was just a test that failed so I was surprised.
> >
> > I still find the result odd.
> >
> > Seeing ScaledDecimal>>testConvertFromFloat, I'm wandering if it would
> > be better to have Float>>=   considering egality if the difference is
> > less than 1.0e-9.
> >
> > <primitive: 47>
> > aNumber isNumber ifFalse: [^ false].
> > ^ (aNumber asFloat - self) abs  <  1.0e-9
> >
> > I would prefer having = working as I expect, even if it would be wrong
> > for smaller values than 1.0e-9. For strict egality, == can be used.
> >
> > Is it possible to disable a primitive call like here (it's optimized no
> ?)
> > ?
> >
> > Anyway, thanks for your answers.
> >
> > Cédrick
> > _______________________________________________
> > Beginners mailing list
> > Beginners at lists.squeakfoundation.org
> > http://lists.squeakfoundation.org/mailman/listinfo/beginners
> >
>
>
> _______________________________________________
> Beginners mailing list
> Beginners at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/beginners
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/beginners/attachments/20080217/95a1d09b/attachment-0001.htm