From: Jules Bean <jmlb2@stripped>
>On Tue, 20 Apr 1999 jkraai@stripped wrote:
>> Has anyone implemented bc math support?
>> I'm diving into the docs now to do this and would hate
>> to carve out a wheel that already exists.
>> Anybody think this is a really bad idea? Let me know.
>I think it's a idea with problems - I always get upset when people, not
>understanding the nature of computer mathematics, complain that a database
>is 'broken' because the floating point data type is not precise.
>The '=' operator is not useful for floating point. I sometimes wish that
>C didn't define an '=' operator, to ram this point home.
Couldn't agree with you more, ran into this on my Apple II. Learned
that thou shalt check that the difference is less than some defined
epsilon, rather than for equality.
>If you need accuracy, then you need fixed point, not floating point. If
>you want 'base 10' accuracy, then you want a fixed point format with a
>denominator of the form 10^x.
What I need is this statement:
decimal_parameter - bc-ish_field as guage
I think BC would be a very cheap way to do this.
I don't need huge accuracy, but I do need huge
precision--I don't care what's there, but I do care
about how the values differ with _very_ fine
>A neater approach than BCD (which is just silly) would be a data type
>which is fixed point, you specify the denominator. So, if you are dealing
>with currency, you might want 4 decimal places, so set the denominator to
Native rational number support would be nice.
Hm, does PgSQL have this? :-) (I tried Pg, moved to MySQL, no
>Essentially, this should be implemented simply as an integer, with an
>automatic scale on the IO routines.
If I didn't want 100 digits of accuracy, this would be great.
>Alternatively, simply use an integer, and do the scaling in your
I don't want my middleware to go through a million result rows
to find the two with values closest to a given value. Yucky!