Re: precision of floor(a/b)

[Dr.-Ing. Torsten Finke]

Hello Tim, 

> 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);

may I suggest never to do such things using floating point arithemtic. In my
opinion it's always more safe to do:

  alpha = [0:6] / 10; 

now the length of the vector alpha is exactly determined. Also I think it's
better maintainable (at least would it be to me, since stepping about floats
may inpredictable vary over platforms and thus is suspiciuous to me).

Best regards


Torsten


> 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
> > 
> 
> _______________________________________________
> Help-octave mailing list
> address@hidden
> https://www-old.cae.wisc.edu/mailman/listinfo/help-octave

-- 

------------------------------------------------------------------------

Dr.-Ing. Torsten Finke                       Amtsgericht Essen HRB 11500
Ingenieurgemeinschaft IgH                    USt-Id.-Nr.: DE 174 626 722
Ges. für Ingenieurleistungen mbH             Geschäftsführung:
Heinz-Bäcker-Str. 34                         Dr.-Ing. S. Rotthäuser
D-45356 Essen                                Dr.-Ing. T. Finke
Tel.: +49 201 / 360-14-17                    Dr.-Ing. W. Hagemeister
Fax.: +49 201 / 360-14-14                    Tel.: +49 201 / 360-14-0
address@hidden                  http://www.igh-essen.com

------------------------------------------------------------------------