Prev: Reading from very large file
Next: Is the UNNEST function standard and/or widespread?
From: Andreas Leitgeb on 10 May 2010 08:38
Jim Janney <jjanney(a)shell.xmission.com> wrote:
> Use BigDecimal for anything involving money. I've heard the excuses
> for using double and they're all lame. And whatever you do, don't write
> new BigDecimal(0.06)

nor (of course) new BigDecimal(1./100) which is the same bad.

No matter how much the lack of overloaded operators for BigDecimal
may tempt one to do such things...

From: Jeffrey H. Coffield on 10 May 2010 09:56


Arne Vajh�j wrote:
> On 08-05-2010 17:42, Roedy Green wrote:
>> If you use double to compute sales taxes, and round to the nearest
>> penny, there is a gotcha. You are supposed to round a precise half
>> penny up. This won't work properly for percentage like 6% (0.06) (of
>> $0.75) which is not precise in binary.
>>
>> There a number of ways to avoid problem. Which would you use?
>
> BigDecimal should be able to mimic the rules out of the box.
>
> Integers (long or int) could be made to mimic the rules.
>
> And as a general rule there is death penalty for using
> floating point for amounts.
>
> Arne
>

There are systems that I maintain that were developed on 16 bit
minicomputers (DEC PDP-11/70) that used doubles for amounts but the
amounts were always in pennies, not dollars, so every amount was always
a whole number.

Jeff Coffield
From: Roedy Green on 10 May 2010 18:25
On Sun, 09 May 2010 12:56:01 GMT, Arved Sandstrom
<dcest61(a)hotmail.com> wrote, quoted or indirectly quoted someone who
said :

>I'm the other way - I'd go to BigDecimal right away. Like I said
>already, I wouldn't tackle this problem at all, because presumably
>thousands of North American vendors already have.

I already tackled it, released the program years ago but only
recently discovered this failing. To my knowledge, my solution is the
only free one.

It is a horrible sort of app to write. I wish I had never started it.
It requires collecting data that hard to find, badly formatted, not
designed to be computer readable, constantly changing.

Collecting data is enough to make one vote for the Tea Party. Yet
American law theoretically requires every vendor to know it all.
It is insane. There are so many simpler ways to collect taxes.

--
Roedy Green Canadian Mind Products
http://mindprod.com

What is the point of a surveillance camera with insufficient resolution to identify culprits?
From: Arne Vajhøj on 12 May 2010 22:10
On 10-05-2010 09:56, Jeffrey H. Coffield wrote:
> Arne Vajh�j wrote:
>> On 08-05-2010 17:42, Roedy Green wrote:
>>> If you use double to compute sales taxes, and round to the nearest
>>> penny, there is a gotcha. You are supposed to round a precise half
>>> penny up. This won't work properly for percentage like 6% (0.06) (of
>>> $0.75) which is not precise in binary.
>>>
>>> There a number of ways to avoid problem. Which would you use?
>>
>> BigDecimal should be able to mimic the rules out of the box.
>>
>> Integers (long or int) could be made to mimic the rules.
>>
>> And as a general rule there is death penalty for using
>> floating point for amounts.
>
> There are systems that I maintain that were developed on 16 bit
> minicomputers (DEC PDP-11/70) that used doubles for amounts but the
> amounts were always in pennies, not dollars, so every amount was always
> a whole number.

Don't worry I will not go and find my executioners axe.

:-)

Two notes:
- this sound not really as being floating point but using
floating point as integers because no sufficiently big
integer were available
- I believe that some PDP-11's had a socalled "Commercial
Instruction Set" to handle this better

Arne

From: Arne Vajhøj on 12 May 2010 22:11
On 10-05-2010 18:25, Roedy Green wrote:
> On Sun, 09 May 2010 12:56:01 GMT, Arved Sandstrom
> <dcest61(a)hotmail.com> wrote, quoted or indirectly quoted someone who
> said :
>> I'm the other way - I'd go to BigDecimal right away. Like I said
>> already, I wouldn't tackle this problem at all, because presumably
>> thousands of North American vendors already have.
>
> I already tackled it, released the program years ago but only
> recently discovered this failing. To my knowledge, my solution is the
> only free one.

I am surprised that you have not gotten into trouble with
floating point earlier.

And using BigDecimal instead of double is free (for license fees).

Arne

First  |  Prev  | 
Pages: 1 2 3
Prev: Reading from very large file
Next: Is the UNNEST function standard and/or widespread?