Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!husc6!seismo!cmcl2!philabs!micomvax!musocs!mcgill-vision!mouse
From: mouse@mcgill-vision.UUCP
Newsgroups: comp.lang.c
Subject: Re: Comments on ANSI public Oct 86 Public review draft.
Message-ID: <704@mcgill-vision.UUCP>
Date: Mon, 23-Mar-87 22:09:46 EST
Article-I.D.: mcgill-v.704
Posted: Mon Mar 23 22:09:46 1987
Date-Received: Fri, 27-Mar-87 05:42:15 EST
References: <4804@brl-adm.ARPA> <365@bms-at.UUCP>
Organization: McGill University, Montreal
Lines: 30

In article <365@bms-at.UUCP>, stuart@bms-at.UUCP (Stuart D. Gathman) writes:
> A straight == comparison for float is useless on almost *any*
> machine.  A better approach would be to define == to be a higher
> level contruct, i.e. equal within a certain "fuzz" factor.

As long as you provide some way to test for real equality.  I mean the
sort that I'd use in

if (...) x = y; else x = z;
......
if (x == y) ....

> This is where operator redefinition would be handy; everyone could
> pick his own floating equality operator.

Wonderful.  Just what the world needs.  "Now let me see, this is Fred's
program, so == means within 1e-10....but this part is some of Alice's
code, so == really means within one part in 1000000...."  It's bad
enough when people start writing their own functions to replace the
supplied library functions.

Still, I suppose it's as good as any other way of settling the matter.
It *is* an unpleasant situation.

					der Mouse

Smart mailers: mouse@mcgill-vision.uucp
USA: {ihnp4,decvax,akgua,utzoo,etc}!utcsri!musocs!mcgill-vision!mouse
     think!mosart!mcgill-vision!mouse
ARPAnet: think!mosart!mcgill-vision!mouse@harvard.harvard.edu