RE: precision of floor(a/b)

[Tim Rueth]

Thanks guys, I'll check these out.  I'm slowly getting vectorized.

--Tim 

> -----Original Message-----
> From: Jaroslav Hajek [mailto:address@hidden 
> Sent: Tuesday, April 06, 2010 4:27 AM
> To: address@hidden
> Cc: John W. Eaton; Scott Carter; address@hidden
> Subject: Re: precision of floor(a/b)
> 
> On Tue, Apr 6, 2010 at 8:17 AM, Tim Rueth <address@hidden> wrote:
> > 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);
> >
> 
> Here you can use:
> 
> alpha_min = 0.0;
> alpha_max = 0.6;
> alpha_step = 0.1;
> alpha_range = alpha_min : alpha_step : alpha_max; for alpha = 
> alpha_range
>        # <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 = length (alpha_range);
> 
> Using ranges with non-integer increments is generally not a 
> good idea, precisely because of floating point issues.
> Instead of 0.0:0.1:0.6, you can either use
> (0:1:6) / 10
> or
> linspace (0.0, 0.6, 7)
> 
> both expressions can be tested for their length using 
> length(). It's no good to try to compute the length yourself, 
> when Octave can do it for you.
> 
> the first result will still be a range (i.e. an array in 
> packed form), but will ensure correct length because Octave's 
> range arithmetics always preserves the length of the range. 
> In the second case, you will get a regular array.
> 
> In any case, whenever you use non-integer values, try to 
> avoid exact equality tests as hard as possible.
> Always bear in mind that floating point numbers are, in 
> general, approximations, and the results you get from Octave 
> are approximations to mathematically true results, and that 
> Octave may happen to compute these approximations in a 
> different manner than you think.
> 
> 
> --
> RNDr. Jaroslav Hajek, PhD
> computing expert & GNU Octave developer
> Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic
> url: www.highegg.matfyz.cz
>