public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
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>
Subject: Re: Strange behavior
Date: Sun, 03 Mar 2002 21:08:00 -0000	[thread overview]
Message-ID: <01b501c1c33a$96908e20$0300000a@FSHPXP> (raw)
In-Reply-To: <3C82FC59.2080700@attbi.com>

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/

  reply	other threads:[~2002-03-04  5:08 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-03-03 18:05 Ross Smith
2002-03-03 18:32 ` Randall R Schulz
2002-03-03 20:49   ` Richard R. Malloy
2002-03-03 21:08     ` Chuck Allison [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-03-03 21:42 Gareth Pearce
2002-03-03 21:26 Robert Collins
2002-03-02 13:18 Chuck Allison
2002-03-02 15:09 ` David Means

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='01b501c1c33a$96908e20$0300000a@FSHPXP' \
    --to=cda@freshsources.com \
    --cc=cygwin@cygwin.com \
    --cc=rosss@pharos.co.nz \
    --cc=rrmalloy@attbi.com \
    --cc=rrschulz@cris.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).