Path: news.mathworks.com!not-for-mail
From: <HIDDEN>
Newsgroups: comp.soft-sys.matlab
Subject: Re: Trouble - floor() BUG? or.... merely my faults?
Date: Wed, 18 Jun 2008 10:01:03 +0000 (UTC)
Organization: The MathWorks, Inc.
Lines: 98
Message-ID: <g3amcv$ap4$1@fred.mathworks.com>
References: <g37urn$4eh$1@fred.mathworks.com> <g3820v$slj$1@fred.mathworks.com> <g3aa8p$9f4$1@fred.mathworks.com>
Reply-To: <HIDDEN>
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 1213783263 11044 172.30.248.37 (18 Jun 2008 10:01:03 GMT)
X-Complaints-To: news@mathworks.com
NNTP-Posting-Date: Wed, 18 Jun 2008 10:01:03 +0000 (UTC)
X-Newsreader: MATLAB Central Newsreader 791003
Xref: news.mathworks.com comp.soft-sys.matlab:474407



"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.