From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4703 invoked by alias); 4 Mar 2002 05:08:09 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Received: (qmail 4645 invoked from network); 4 Mar 2002 05:08:06 -0000 Received: from unknown (HELO mgr1.xmission.com) (198.60.22.201) by sources.redhat.com with SMTP; 4 Mar 2002 05:08:06 -0000 Received: from [198.60.22.22] (helo=mail.xmission.com) by mgr1.xmission.com with esmtp (Exim 3.22 #1) id 16hkhg-0000zV-00; Sun, 03 Mar 2002 22:08:04 -0700 Received: from [166.70.15.235] (helo=FSHPXP) by mail.xmission.com with smtp (Exim 3.22 #1) id 16hkhg-0006Hf-00; Sun, 03 Mar 2002 22:08:04 -0700 Message-ID: <01b501c1c33a$96908e20$0300000a@FSHPXP> From: "Chuck Allison" To: "Richard R. Malloy" , "Randall R Schulz" Cc: "Ross Smith" , References: <5.1.0.14.2.20020303181544.02707180@pop3.cris.com> <3C82FC59.2080700@attbi.com> Subject: Re: Strange behavior Date: Sun, 03 Mar 2002 21:08:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-SW-Source: 2002-03/txt/msg00153.txt.bz2 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" To: "Randall R Schulz" Cc: "Ross Smith" ; "'Chuck Allison'" ; 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/