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

Quoth Carl Eastlund:
> On Tue, 25 Jan 2005 14:02:34 -0500, Don Blaheta <dblaheta at knox.edu> wrote:
> > Now, there are situations once you know what you're doing, when you know
> > that numeric error can't arise, that you can make use of ==, but Java
> > beginners really shouldn't use those.  The correct way to test equality
> > on doubles is
> > 
> >   > double epsilon = 0.0001;
> >   > Math.abs (x - y) < epsilon
> >   true
> 
> I'm very wary of the claim that this is "correct".  For very very
> large values - the distance in meters between galaxies, for instance -
> this epsilon is woefully small and this might as well be the == test. 
> For very very small values - the distance in meters between electrons,
> for instance - this epsilon is woefully large and this might as well
> be the constant true.

Sorry, I thought it was clear that epsilon is not a universally constant
value; that's why I named it instead of just using 1e-4 directly.  When
I introduce this idea in class, I also include the fact that you need to
pick an appropriate value of epsilon for the sorts of values you'll be
using.

> I think floating-point comparison is a trickier issue than this, and
> not one necessarily solvable by making freshman students declare or
> use a constant epsilon.

Perhaps, but it's certainly not solved by letting students use ==
willy-nilly.

> > It's really the same reason that you can't use == on objects in Beginner
> > ProfJ: it doesn't mean what they might intuitively expect it to mean, so
> > you don't want them using it until they understand its problems.
> 
> That's true.  I just think it's unfortunate that some very natural
> examples become very difficult to test until this issue is addressed.

You're telling me; I had totally forgotten about this when I wrote an
*exam* problem last term that required an equality test.  (It was on
numbers that were not being manipulated, so it was legit, but Beginner
still disallowed it, of course.  That'll teach me to distribute exams
before writing and testing the answer key.)  As with most of the
language level restrictions, there are tradeoffs.  Even having been
burned by it, though, I still think it's the right choice.

> > What "earliest examples" in HtDCH are you referring to?
> 
> I was referring to the incarnation of the HtDCH course being taught
> currently at Northeastern, and not to any particular examples in the
> test.  We've been writing methods like distanceToZero and
> priceWithTax, and we've needed a way to compare double-valued results
> for test cases.  This worked its way into our labs before comparison
> techniques worked its way into our lectures.

It's exactly in writing test cases that this comes up in my course, and
I use a progression of faulty test cases to introduce several related
ideas.  Of course, the test case internals are perfectly happy to use ==
on doubles... you're guaranteed not to have false positives, but you may
get some false negatives, even after you do everything else right to
maximise your precision.  In the end, I tell them that sometimes, the
red X just means "numeric error happened, and you have to visually
confirm that the answer is, in fact, correct."  It's the best I can do
until we move to BlueJ late in the term.

But where are you actually using == ?  Test cases don't require them.

-- 
-=-Don Blaheta-=-dblaheta at knox.edu-=-=-<http://faculty.knox.edu/dblaheta/>-=-
"The making of language and mythology are related functions; your
language construction will breed a mythology."	--J.R.R. Tolkien