Path: news.mathworks.com!not-for-mail
From: "ken " <ken4aver@yahoo.com.tw>
Newsgroups: comp.soft-sys.matlab
Subject: Re: Trouble - floor() BUG? or.... merely my faults?
Date: Wed, 18 Jun 2008 13:00:05 +0000 (UTC)
Organization: The MathWorks, Inc.
Lines: 135
Message-ID: <g3b0sl$fro$1@fred.mathworks.com>
References: <g37urn$4eh$1@fred.mathworks.com> <g3820v$slj$1@fred.mathworks.com> <g3aa8p$9f4$1@fred.mathworks.com> <g3amcv$ap4$1@fred.mathworks.com>
Reply-To: "ken " <ken4aver@yahoo.com.tw>
NNTP-Posting-Host: webapp-02-blr.mathworks.com
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Trace: fred.mathworks.com 1213794005 16248 172.30.248.37 (18 Jun 2008 13:00:05 GMT)
X-Complaints-To: news@mathworks.com
NNTP-Posting-Date: Wed, 18 Jun 2008 13:00:05 +0000 (UTC)
X-Newsreader: MATLAB Central Newsreader 1223870
Xref: news.mathworks.com comp.soft-sys.matlab:474431



"David " <dave@bigcompany.com> wrote in message <g3amcv$ap4
$1@fred.mathworks.com>...
> "ken " <ken4aver@yahoo.com.tw> wrote in message 
<g3aa8p$9f4
> $1@fred.mathworks.com>...
> > "Jos " <DELjos@jasenDEL.nl> wrote in message 
> > <g3820v$slj$1@fred.mathworks.com>...
> > > "ken " <ken4aver@yahoo.com.tw> wrote in message
> > > <g37urn$4eh$1@fred.mathworks.com>...
> > 
> > 
> > 
> > 
> > Anyway however, I have an additional vague thinking as 
> to 
> > argue.
> > 
> > x=3.79999999e+001, such sorts of value would ever be 
> > obtained from some kind of calculation. It certainly is 
> a 
> > bit of difference between 37.9999 and 38.0000 and hence 
> > allowable in scientific arithmetic.
> > 
> > BUT it stored in 37.9999 double, revealed 38.0000 on 
> some 
> > situations(like printout, some arithmetic, ...) and 
ALSO 
> > 37.9999 on others(here - floor()).
> > 
> > It manifests that the occasions for which floating 
> points 
> > evaluations are INCONSISTENCY!?
> > At least here, it is the conclusion that results of 
> > floating points arithmetic are not PROPER to be in 
> > corresponding to floor evaluations, right?
> > 
> > Please trace the above code I posted beginning at 
> > x==16.0000 and starting monitoring either at program 
> showed-
> > out or at commandline evaluations, evidence there.
> > 
> > 
> > and I list the trace results
> > 
> > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> > In prog:
> > 
> > x=(y_prime+1)/m+param1x;
> > 
> > they are internally
> > 15.99999999999997=(37+1)/0.26086956521739+ -
> > 1.296666666666667e+002
> > 
> > 
> > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> > But in commandline:
> > 
> > 
> > 
> > 38/0.26086956521739
> > 
> > ans =
> > 
> >     1.456666666666674e+002
> > 
> > K>> ans-1.296666666666667e+002
> > 
> > ans =
> > 
> >   16.00000000000068
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > So... floor dead... Any comments?
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> 
> not dead, just being applied in an unsafe manner.  go 
back 
> and read the hundred or so other threads on floating 
point 
> calculations over the last year or so.  this is well 
known 
> and documented and any time you program with floating 
> point variables you are going to see this.  this is why 
> you will commonly see things like int(x+.5) or floor
(x+.5) 
> when converting from floats to ints just to be sure that 
> single bit differences are masked.  as far as displaying 
> different values in different places, this is just a 
> display issue, the underlying value hasn't changed, its 
> just the way it gets printed changes.  change your 
display 
> preferences to long e or g and see what you get, all 
those 
> little bit differences suddenly start to make your 
numbers 
> look not so precise... but that is the world of floating 
> point calculations.
> 


Thank you, David.
I learn it.

And I took a trial of the following statements.
Trouble slips away!!! (to somewhere :) )

y=m*x_prime+m*1+param1y;
x=y_prime/m+1/m+param1x;
y=m*x_prime+m*1+param1y;
x=y_prime/m-1/m+param1x;

Some sense of "make a room for it".
(and such idea inform other people if you someday also...)



Regards and appreciate

Ken