Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Message-ID: <01b501c1c33a$96908e20$0300000a@FSHPXP>
From: "Chuck Allison" <cda@freshsources.com>
To: "Richard R. Malloy" <rrmalloy@attbi.com>,
   "Randall R Schulz" <rrschulz@cris.com>
Cc: "Ross Smith" <rosss@pharos.co.nz>, <cygwin@cygwin.com>
References: <5.1.0.14.2.20020303181544.02707180@pop3.cris.com> <3C82FC59.2080700@attbi.com>
Subject: Re: Strange behavior
Date: Sun, 3 Mar 2002 22:08:13 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

That's the point. They're always redued, so in both cases, the expression
2.0/3.0 is evaluated. How can that be non-deterministic?

----- Original Message -----
From: "Richard R. Malloy" <rrmalloy@attbi.com>
To: "Randall R Schulz" <rrschulz@cris.com>
Cc: "Ross Smith" <rosss@pharos.co.nz>; "'Chuck Allison'"
<cda@freshsources.com>; <cygwin@cygwin.com>
Sent: Sunday, March 03, 2002 9:47 PM
Subject: Re: Strange behavior


> OK. I'm no IA32 expert can someone explain the following results.  (Do
> the floating point registers
> use guard bits, randomly initialized perhaps?)
>
> bool operator==(const Rational& r1, const Rational& r2)
> {
>   double a=r1.toDouble(), b=r2.toDouble();
>   cout << ?== a " << a << " " << ?== b " << b << endl;
>   return a == b;
>   //  return r1.toDouble() == r2.toDouble();
>   /*  return ( r1.numerator == r2.numerator && r1.denominator ==
> r2.denominator ); */
> }
>
> 5/4
> == a 1.25 == b 1.25
> 1
> -1/4
> == a -0.25 == b -0.25
> 1
> 3/8
> == a 0.375 == b 0.375
> 1
> 2/3
> == a 0.666667 == b 0.666667
> 0                                                  //  return
> r1.toDouble() == r2.toDouble();
>
> 5/4
> == a 1.25 == b 1.25
> 1
> -1/4
> == a -0.25 == b -0.25
> 1
> 3/8
> == a 0.375 == b 0.375
> 1
> 2/3
> == a 0.666667 == b 0.666667
> 1                                                        return a == b;
>
>
> But since the Rational are always reduced the "right" answer is
>
>           return ( r1.numerator == r2.numerator && r1.denominator ==
> r2.denominator );
>
>     No?
>
> Rich.
>
> Randall R Schulz wrote:
>
> > Ross,
> >
> > To call that result "pure luck" denies the fact that digital
> > computers, when properly functioning, are 100% deterministic.
> >
> > Of course, it's not proper floating-point programming, but that
> > doesn't mean "luck" is involved.
> >
> > Randall Schulz
> > Mountain View, CA USA
> >
> >
> > At 18:04 2002-03-03, Ross Smith wrote:
> >
> >> > From: Chuck Allison [mailto:cda@freshsources.com]
> >> >
> >> > I have a simple Rational number class and have discovered
> >> > weird behavior
> >> > with Cygwin's g++. If you look at the very short main program in file
> >> > rtest2.cpp, you will see by the output that g++ get's the
> >> > wrong answer for
> >> >
> >> > r1 / r2 == Rational(2,3); // should be true
> >> >
> >> > even though it prints as 2/3! Borland and Microsoft get it
> >> > right. Any ideas?
> >> > All code atached.
> >>
> >> [relevant bit of code]
> >>
> >> inline bool operator==(const Rational& r1, const Rational& r2)
> >> {
> >>    return r1.toDouble() == r2.toDouble();
> >> }
> >>
> >> This is nothing to do with Cygwin, or g++ for that matter. You're
> >> comparing floating point numbers. Of course it's not reliable! If
> >> other compilers happened to give you an exact equality on that
> >> particular combination of arguments, it was pure luck.
> >
> >
> >
> > --
> > Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> > Bug reporting:         http://cygwin.com/bugs.html
> > Documentation:         http://cygwin.com/docs.html
> > FAQ:                   http://cygwin.com/faq/
> >
> >
>
>
>


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/