[plt-scheme] ProfessorJ, ==, and double

We're pragmatic here, not dogmatic. It's nearly impossible to avoid 
operations that create numerical errors; so the next best thing we can 
do is point students to it. That's critical. Too many BS grads don't 
know anything about this material. And I mean anything

-- Matthias

P.S. We also spent a 1.5 hours lab in 211 discussing this problem. But 
I think we should repeat it in every course for 10 semesters.

On Jan 26, 2005, at 9:43 AM, Joe Marshall wrote:

>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>
> Don Blaheta <dblaheta at knox.edu> writes:
>
>>   For list-related administrative tasks:
>>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>>
>> Quoth Carl Eastlund:
>>> The == operator doesn't operate on type double in ProfessorJ: 
>>> Beginner
>>> in DrScheme v209.  It works fine in ProfessorJ: Advanced, but we've
>>> needed it in our earliest examples in the HtDCH class.  We can work
>>> around it with new Double(x).equals(new Double(y)), but yuck.  Is
>>> there any reason for this being left out of the Beginner level?
>>
>> Because floating point numbers shouldn't be tested for equality, due 
>> to
>> numeric error.  Consider:
>>
>>> double x = (1.0 / 6) * 10000;
>>> double y = 10000.0 / 6;
>>> x
>>   1666.6666666666665
>>> y
>>   1666.6666666666667
>
> I understand the rationale here, but I disagree with the phrasing, and
> perhaps the conclusion.  In floating point, equality comparison is
> never a source of error.  In the example above, the division and
> multiplication operations are the sources of error because the
> mathematically correct results are not representable.
>
> It seems a little odd to cite rounding errors as the rationale for
> avoiding equality testing when
>    a) operations that cause rounding errors aren't discouraged
>    b) equality testing is one of the few operations that don't round
>
>
>
>