Re: numeric precision when raising one numeric to another.

We use Moshier's excellent qfloat numbers.
http://www.moshier.net/qlib.zip
Documentation:
http://www.moshier.net/qlibdoc.html

So, if you do the following query using CONNX:
select convert(pow(9.5,5.9), varchar)
You will get:
586906.97548405202106027547827738573075504470845684721318303336760202394
5916438064873363100477233500417619

select pow(9.5,5.9)
will return
586906.975484052
Since we bind to double by default.

Correct answer is (1000+ digits correct):
586906.97548405202106027547827738573075504470845684721318303336760202394
591643806487336310047723350041762446340060298807517843626920535883745120
986264188881010308125070048988991029963307831015812131852033741567043945
026243178422915290830477381800527219457732229115168020868495354958648414
971711685840852684310130094029132142016389076807514261122763703528030232
527888410105794936941873557344173381053429729906642653004811669321631656
412265025095200907690509153627646726650174318576911125609483654656735531
730688699016039020145753010069585349923506043259767525488453544723589880
427675085429230106535405724821481118286775763085905255396545439080913364
233329975992733986721408870779427889446166143315004295671202526112889352
043403059958082573333911277403826735005243749050919501832287479909523379
145261282152034011112442260653013983173651648948479379642961647792197822
118268619926636309476522424825736766449170308662847527591516245860159270
335785812239686778074630519049627528571047048724459826189283691382474184
22032503387712889

It might seem like overkill, but (for instance) we have customers who
measure every toll on toll roads for large states in the eastern US.

If they want to calculate 5 years of interest on the current balance,
accurate to the penny, at small interest rates, such precision is very
helpful.

His (Moshier's) math stuff is really top-notch.

> -----Original Message-----
> From: pgsql-general-owner@postgresql.org [mailto:pgsql-general-
> owner@postgresql.org] On Behalf Of Martijn van Oosterhout
> Sent: Thursday, May 19, 2005 2:14 AM
> To: Alvaro Herrera
> Cc: John Burger; pgsql-general@postgresql.org
> Subject: Re: [GENERAL] numeric precision when raising one numeric to
> another.
>
> On Wed, May 18, 2005 at 11:32:40PM -0400, Alvaro Herrera wrote:
> > On Wed, May 18, 2005 at 10:46:50PM -0400, John Burger wrote:
> > > For one thing.  For another, I believe the standard C library only
has
> > > floating point exponentiation functions, not that there aren't
plenty
> > > of numeric libraries with integral ones.  Finally, exponentiated
> > > numbers get real big, real fast, and the floating point types can
hold
> > > much larger magnitudes than the integer types, albeit inexactly.
For
> > > example, on the Mac I'm using now, long long ints max out at about
> > > 10^19, while long doubles can represent 10^308.
> >
> > Well, we already have an interesting library of mathematical
functions
> > for NUMERIC (which is an arbitrary precision type, so it wouldn't
matter
> > how big the result would get).  I think the only reason we don't
have a
> > NUMERIC exponentiation function is that nobody has implemented it.
>
> The prerequisites for such a function would be a log() and exp()
> function for numeric. And the real question there would be, what's a
> sufficient accuracy? Numbers people actually use rarely have even
> rational logarithms, so there is no way to store them 100% accurate.
>
> As long as you're using integral exponents you can get away with
> multiplication. BTW, the commandline utility "bc" has arbitrary number
> arithmatic, maybe we can see how they do it? It defaults to 20 digits
> precision, which is obviously not enough for large exponents.
>
> Hmm, it looks like even they don't support raising to fractional
> powers. When calculating 2^100, you need a precision of at least 35
> decimal places to get in the ballpark of the correct figure using
> log/exp, 30 isn't enough. Maybe do exact for integer exponents and
> approx for non-integer?
>
> kleptog@vali:~$ bc -l
> bc 1.06
> Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc.
> > 2^100
> 1267650600228229401496703205376
> > 2^100.1
> Runtime warning (func=(main), adr=11): non-zero scale in exponent
> 1267650600228229401496703205376
> > e(l(2)*100)
> 1267650600228229400579922894637.90158245154400629512
> > scale=30
> > e(l(2)*100)
> 1267650600228229401496703205353.617337311111135194699059124092
> > scale=35
> > e(l(2)*100)
> 1267650600228229401496703205375.99897630874075350752485091801369515
>
> Hope this helps,
> --
> Martijn van Oosterhout   <kleptog@svana.org>
http://svana.org/kleptog/
> > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent
is a
> > tool for doing 5% of the work and then sitting around waiting for
> someone
> > else to do the other 95% so you can sue them.