Velocity Reviews > Solution for Floating-Point Errors

# Solution for Floating-Point Errors

vunet.us@gmail.com
Guest
Posts: n/a

 07-23-2007
Is there a good solution for floating-point errors?
If I got:
0.00831 + 0.000001 = 0.00831109999999999999
can I avoid this by a better method than comparing 2 number length
after decimal point and using toFixed() to match shorter number with
another one?
Thanks.

David Mark
Guest
Posts: n/a

 07-23-2007
On Jul 23, 4:35 pm, (E-Mail Removed) wrote:
> Is there a good solution for floating-point errors?
> If I got:
> 0.00831 + 0.000001 = 0.00831109999999999999
> can I avoid this by a better method than comparing 2 number length
> after decimal point and using toFixed() to match shorter number with
> another one?
> Thanks.

Yes. To make it simpler, multiply each by 1000000 before adding:

8310 + 1 = 8311

vunet.us@gmail.com
Guest
Posts: n/a

 07-23-2007
On Jul 23, 5:28 pm, David Mark <(E-Mail Removed)> wrote:
> On Jul 23, 4:35 pm, (E-Mail Removed) wrote:
>
> > Is there a good solution for floating-point errors?
> > If I got:
> > 0.00831 + 0.000001 = 0.00831109999999999999
> > can I avoid this by a better method than comparing 2 number length
> > after decimal point and using toFixed() to match shorter number with
> > another one?
> > Thanks.

>
> Yes. To make it simpler, multiply each by 1000000 before adding:
>
> 8310 + 1 = 8311

very good. thank you.

David Mark
Guest
Posts: n/a

 07-23-2007
On Jul 23, 6:08 pm, Randy Webb <(E-Mail Removed)> wrote:
> David Mark said the following on 7/23/2007 5:28 PM:
>
> > On Jul 23, 4:35 pm, (E-Mail Removed) wrote:
> >> Is there a good solution for floating-point errors?
> >> If I got:
> >> 0.00831 + 0.000001 = 0.00831109999999999999
> >> can I avoid this by a better method than comparing 2 number length
> >> after decimal point and using toFixed() to match shorter number with
> >> another one?
> >> Thanks.

>
> > Yes. To make it simpler, multiply each by 1000000 before adding:

>
> > 8310 + 1 = 8311

>
> 0.00831 + 0.000001 != 8311

To compare the result, as per my post, you have to multiply both sides
of the equation. I don't know how much more explicit I could have
made this and the OP obviously understood.

Lee
Guest
Posts: n/a

 07-23-2007
David Mark said:
>
>On Jul 23, 6:08 pm, Randy Webb <(E-Mail Removed)> wrote:
>> David Mark said the following on 7/23/2007 5:28 PM:
>>
>> > On Jul 23, 4:35 pm, (E-Mail Removed) wrote:
>> >> Is there a good solution for floating-point errors?
>> >> If I got:
>> >> 0.00831 + 0.000001 = 0.00831109999999999999
>> >> can I avoid this by a better method than comparing 2 number length
>> >> after decimal point and using toFixed() to match shorter number with
>> >> another one?
>> >> Thanks.

>>
>> > Yes. To make it simpler, multiply each by 1000000 before adding:

>>
>> > 8310 + 1 = 8311

>>
>> 0.00831 + 0.000001 != 8311

>
>To compare the result, as per my post, you have to multiply both sides
>of the equation. I don't know how much more explicit I could have
>made this and the OP obviously understood.

Saying "multiply each ... before adding" suggests that the things
referred to by "each" are also the things that you are adding, so
you certainly could have been much more clear about specifying
that you also have to multiply the comparison target.

How is it obvious that the OP understood? For all we know, he's
so simple, doesn't work when implemented.

--

vunet.us@gmail.com
Guest
Posts: n/a

 07-23-2007

> How is it obvious that the OP understood?

Let's see: 0.00831 + 0.000001 = 0.008311

(0.00831*1000000) + (0.000001*1000000) == 0.008311/1000000
8310 + 1 = 8311/1000000

thus ==> 0.008311

What does everyone think? I'd appreciate a better way of handling this
if there is one...
Thanks

David Mark
Guest
Posts: n/a

 07-23-2007
On Jul 23, 6:31 pm, Lee <(E-Mail Removed)> wrote:
> David Mark said:
>
>
>
>
>
>
>
> >On Jul 23, 6:08 pm, Randy Webb <(E-Mail Removed)> wrote:
> >> David Mark said the following on 7/23/2007 5:28 PM:

>
> >> > On Jul 23, 4:35 pm, (E-Mail Removed) wrote:
> >> >> Is there a good solution for floating-point errors?
> >> >> If I got:
> >> >> 0.00831 + 0.000001 = 0.00831109999999999999
> >> >> can I avoid this by a better method than comparing 2 number length
> >> >> after decimal point and using toFixed() to match shorter number with
> >> >> another one?
> >> >> Thanks.

>
> >> > Yes. To make it simpler, multiply each by 1000000 before adding:

>
> >> > 8310 + 1 = 8311

>
> >> 0.00831 + 0.000001 != 8311

>
> >To compare the result, as per my post, you have to multiply both sides
> >of the equation. I don't know how much more explicit I could have
> >made this and the OP obviously understood.

>
> Saying "multiply each ... before adding" suggests that the things
> referred to by "each" are also the things that you are adding, so

Of course they are.

> you certainly could have been much more clear about specifying
> that you also have to multiply the comparison target.

How much more clear could the example be? It explicitly shows the new
equation.

>
> How is it obvious that the OP understood? For all we know, he's

Because he said so. And now two other posters have muddled the issue

> so simple, doesn't work when implemented.

The example equation "works" fine, in that both sides are equal.

David Mark
Guest
Posts: n/a

 07-24-2007
On Jul 23, 7:35 pm, Randy Webb <(E-Mail Removed)> wrote:
> David Mark said the following on 7/23/2007 7:24 PM:
>
>
>
>
>
> > On Jul 23, 6:31 pm, Lee <(E-Mail Removed)> wrote:
> >> David Mark said:

>
> >>> On Jul 23, 6:08 pm, Randy Webb <(E-Mail Removed)> wrote:
> >>>> David Mark said the following on 7/23/2007 5:28 PM:
> >>>>> On Jul 23, 4:35 pm, (E-Mail Removed) wrote:
> >>>>>> Is there a good solution for floating-point errors?
> >>>>>> If I got:
> >>>>>> 0.00831 + 0.000001 = 0.00831109999999999999
> >>>>>> can I avoid this by a better method than comparing 2 number length
> >>>>>> after decimal point and using toFixed() to match shorter number with
> >>>>>> another one?
> >>>>>> Thanks.
> >>>>> Yes. To make it simpler, multiply each by 1000000 before adding:
> >>>>> 8310 + 1 = 8311
> >>>> 0.00831 + 0.000001 != 8311
> >>> To compare the result, as per my post, you have to multiply both sides
> >>> of the equation. I don't know how much more explicit I could have
> >>> made this and the OP obviously understood.
> >> Saying "multiply each ... before adding" suggests that the things
> >> referred to by "each" are also the things that you are adding, so

>
> > Of course they are.

>
> >> you certainly could have been much more clear about specifying
> >> that you also have to multiply the comparison target.

>
> > How much more clear could the example be? It explicitly shows the new
> > equation.

>
>
> Multiply both of your decimals by 100000 (in this case), add them, then
> divide the answer by 100000 to get the decimal back.
>

You've done it again. There are six decimal places to shift (in this
case), not five. 100000 != 1000000.

And what the hell does "get the decimal back" mean anyway? Same for

> You wanted more clear, you got it.

I didn't want anything. The OP wanted an answer and got it and
followed up to say it worked. Now you have made a real mess of
things.

Lee
Guest
Posts: n/a

 07-24-2007
David Mark said:
>
>On Jul 23, 6:31 pm, Lee <(E-Mail Removed)> wrote:
>> David Mark said:
>>
>>
>>
>>
>>
>>
>>
>> >On Jul 23, 6:08 pm, Randy Webb <(E-Mail Removed)> wrote:
>> >> David Mark said the following on 7/23/2007 5:28 PM:

>>
>> >> > On Jul 23, 4:35 pm, (E-Mail Removed) wrote:
>> >> >> Is there a good solution for floating-point errors?
>> >> >> If I got:
>> >> >> 0.00831 + 0.000001 = 0.00831109999999999999
>> >> >> can I avoid this by a better method than comparing 2 number length
>> >> >> after decimal point and using toFixed() to match shorter number with
>> >> >> another one?
>> >> >> Thanks.

>>
>> >> > Yes. To make it simpler, multiply each by 1000000 before adding:

>>
>> >> > 8310 + 1 = 8311

>>
>> >> 0.00831 + 0.000001 != 8311

>>
>> >To compare the result, as per my post, you have to multiply both sides
>> >of the equation. I don't know how much more explicit I could have
>> >made this and the OP obviously understood.

>>
>> Saying "multiply each ... before adding" suggests that the things
>> referred to by "each" are also the things that you are adding, so

>
>Of course they are.
>
>> you certainly could have been much more clear about specifying
>> that you also have to multiply the comparison target.

>
>How much more clear could the example be? It explicitly shows the new
>equation.
>
>>
>> How is it obvious that the OP understood? For all we know, he's

>
>Because he said so. And now two other posters have muddled the issue

You believe that, because a person says he understands your
solution, that he must actually "obviously" understand it?
Clearly you've never been involved in any sort of user support.

Your explanation is incomplete in that it doesn't clearly
before the addition, that you also multiply the value you're
using for comparison. As I said before, "multiply each ...

>
>
>> so simple, doesn't work when implemented.

>
>The example equation "works" fine, in that both sides are equal.

Only if you interpret it as you intended, as opposed to how
you described it.

--

Lee
Guest
Posts: n/a

 07-24-2007
http://www.velocityreviews.com/forums/(E-Mail Removed) said:
>
>
>> How is it obvious that the OP understood?

>
>Let's see: 0.00831 + 0.000001 = 0.008311
>
>(0.00831*1000000) + (0.000001*1000000) == 0.008311/1000000
>8310 + 1 = 8311/1000000
>
>thus ==> 0.008311

You realize, don't you, that whether or not you actually
did understand it has nothing whatsoever to do with the
question of whether or not it was obvious that you did?

--