[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: precision of floor(a/b)
From: |
Dr.-Ing. Torsten Finke |
Subject: |
Re: precision of floor(a/b) |
Date: |
Tue, 6 Apr 2010 12:55:59 +0200 |
User-agent: |
Mutt/1.5.16 (2007-06-09) |
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
------------------------------------------------------------------------
- precision of floor(a/b), Tim Rueth, 2010/04/05
- Re: precision of floor(a/b), Ben Abbott, 2010/04/05
- RE: precision of floor(a/b), Tim Rueth, 2010/04/05
- RE: precision of floor(a/b), John W. Eaton, 2010/04/05
- Re: precision of floor(a/b), Scott Carter, 2010/04/05
- RE: precision of floor(a/b), Tim Rueth, 2010/04/06
- RE: precision of floor(a/b), CdeMills, 2010/04/06
- Re: precision of floor(a/b), Martin Helm, 2010/04/06
- Re: precision of floor(a/b),
Dr.-Ing. Torsten Finke <=
- Re: precision of floor(a/b), Jaroslav Hajek, 2010/04/06
- RE: precision of floor(a/b), Tim Rueth, 2010/04/07
Re: precision of floor(a/b), Scott Carter, 2010/04/05