help-octave
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: precision of floor(a/b)


From: Jaroslav Hajek
Subject: Re: precision of floor(a/b)
Date: Tue, 6 Apr 2010 13:26:36 +0200

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]