RE: precision of floor(a/b)

[Tim Rueth]

I see your point about floor(a*(1+eps)/b) not providing the correct answer
in some cases.  In my case, I'm simply trying to determine the number of
times a for-loop gets executed.  More specifically, I have a for-loop:

alpha_min = 0.0;
alpha_max = 0.6;
alpha_step = 0.1;
for alpha = alpha_min : alpha_step : alpha_max
        # <do some stuff with alpha>
endfor;

I want to know, prior to executing the for-loop, how many times it will be
executed, so I do:

num_steps = floor((alpha_max  - alpha_min)  / alpha_st  * (1+eps) + 1);

Without the *(1+eps) term, num_steps = 5 instead of 6.  I agree that the
(1+eps) term is somewhat of a kludge, but in this case I think it's fine,
since I just need to determine the number of times the for-loop is executed,
and the _min, _step, and _max values will never have precision more than
hundredths.

--Tim


> From: Scott Carter [mailto:address@hidden 
> Sent: Monday, April 05, 2010 6:30 PM
> To: John W. Eaton
> Cc: address@hidden; address@hidden
> Subject: Re: precision of floor(a/b)
> 
> Yep, that's why I said that if the OP wants exact decimal 
> arithmetic the easiest (IMHO) approach is to convert 
> everything to integer and input and separately keep track of 
> where the radix point is.
> 
> But I still don't know what the original problem is/was:
> 
> if 0.6 and 0.1 are meant to be exact decimals, then the 
> convert to integer approach works.
> 
> if they are really floating point approximations, then the 
> use of the floor function is basically ill-defined
> 
> since floor((0.6+eps)/(0.1-eps)) != floor ((0.6-eps)/(0.1+eps)) 

> -----Original Message-----
> From: John W. Eaton [mailto:address@hidden 
> Sent: Monday, April 05, 2010 6:23 PM
> To: address@hidden
> Cc: 'Ben Abbott'; address@hidden
> Subject: RE: precision of floor(a/b)
> 
> 
> | Yes, that fixed it, thanks!  Learning something new every day.
> | 
> | --Tim
> | 
> | 
> | > -----Original Message-----
> | > From: Ben Abbott [mailto:address@hidden
> | > Sent: Monday, April 05, 2010 5:01 PM
> | > To: address@hidden
> | > Cc: address@hidden
> | > Subject: Re: precision of floor(a/b)
> | > 
> | > 
> | > On Apr 5, 2010, at 7:52 PM, Tim Rueth wrote:
> | > 
> | > > If I do floor(6/1), I correctly get 6.  If I do
> | > floor(0.6/0.1), I get 5.  If I do floor((0.6/0.1 +
> | > 0.00000001)) I correctly get 6.
> | > >  
> | > > I assume this has to do with the precision of the division? 
> | >  I read in the manual that Octave stores numbers as double 
> | > precision, so this surprises me.  What's the best way to 
> deal with 
> | > this imprecision so I can always get the correct answer, or is 
> | > something else going on here?
> | > 
> | > Will floor(0.6/0.1*(1+eps)) work for you?
> 
> I don't think this is a general solution to the problem.  It 
> will likely do the "right thing" (i.e., what you expect for decimal
> arithmetic) in some cases but not others.  For example, what about
> 
>   floor (0.7999999999999999/0.1*(1+eps))
> 
> which on my system returns 8.  Note that in this case,
> 0.7999999999999999 < 0.8 does evaluate to true, so I guess 
> you would want the result of the division and floor operation 
> to be 7, not 8 if you were doing decimal arithmetic.
> 
> The thing is, you aren't doing decimal arithmetic.  So 
> throwing in factors of eps to get solutions that look right 
> for decimal arithmetic in certain cases is probably not what 
> you want to do.
> 
> jwe
>