«

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.

On Jul 23, 4:35 pm, vunet...@gmail.com 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

On Jul 23, 5:28 pm, David Mark <dmark.cins...@gmail.com> wrote:
> On Jul 23, 4:35 pm, vunet...@gmail.com 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.

On Jul 23, 6:08 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
> David Mark said the following on 7/23/2007 5:28 PM:
>
> > On Jul 23, 4:35 pm, vunet...@gmail.com 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.

David Mark said:
>
>On Jul 23, 6:08 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
>> David Mark said the following on 7/23/2007 5:28 PM:
>>
>> > On Jul 23, 4:35 pm, vunet...@gmail.com 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
currently scratching his head because your solution, which seems
so simple, doesn't work when implemented.


--

> 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

On Jul 23, 6:31 pm, Lee <REM0VElbspamt...@cox.net> wrote:
> David Mark said:
>
>
>
>
>
>
>
> >On Jul 23, 6:08 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
> >> David Mark said the following on 7/23/2007 5:28 PM:
>
> >> > On Jul 23, 4:35 pm, vunet...@gmail.com 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
and confused him. How do I know that? Read the thread.

> currently scratching his head because your solution, which seems

No. Read the thread.

> so simple, doesn't work when implemented.

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

On Jul 23, 7:35 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
> David Mark said the following on 7/23/2007 7:24 PM:
>
>
>
>
>
> > On Jul 23, 6:31 pm, Lee <REM0VElbspamt...@cox.net> wrote:
> >> David Mark said:
>
> >>> On Jul 23, 6:08 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
> >>>> David Mark said the following on 7/23/2007 5:28 PM:
> >>>>> On Jul 23, 4:35 pm, vunet...@gmail.com 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.
>
> Answer:
>
> 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
"multiply both of your decimals."

> 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.

David Mark said:
>
>On Jul 23, 6:31 pm, Lee <REM0VElbspamt...@cox.net> wrote:
>> David Mark said:
>>
>>
>>
>>
>>
>>
>>
>> >On Jul 23, 6:08 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
>> >> David Mark said the following on 7/23/2007 5:28 PM:
>>
>> >> > On Jul 23, 4:35 pm, vunet...@gmail.com 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
>and confused him. How do I know that? Read the thread.

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
specify that, in addition to multiplying each of the addends
before the addition, that you also multiply the value you're
using for comparison. As I said before, "multiply each ...
before adding" leads one to believe that you are talking only
about the numbers that you are adding.

>> currently scratching his head because your solution, which seems
>
>No. Read the thread.
>
>> 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.


--

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?


--