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