Re: Getting greatest decimal accuracy out of G_PI

[zentara <zentara1 sbcglobal net>]

On Sat, 3 Feb 2007 21:44:12 +0100
David Nečas (Yeti) <yeti physics muni cz> wrote:

>On Sat, Feb 03, 2007 at 12:34:24PM -0500, zentara wrote:
>> 
>> I'll post this in case anyone in the future searches the archives
>> for an answer.
>
>For the case anyone finds this, a correction...
>
>You can't fool C.  The literal without an `l' suffix is
>a double literal.  The compiler creates a floating point
>constant represented by a double from it.  Passing it as an
>argument to a function that takes long double results in
>an automatic conversion to long double according to the
>rules, but since it was double constant, is has still only
>the preision of a double.  As your own example clearly
>demonstrates.
>
>> Output:
>> PI is   3.1415926535897931159979634685441851615905761718750000000000000
>> G_PI is 3.1415926535897931159979634685441851615905761718750000000000000
>
>Input was 3.1415926535897932384626433832795028841971693993751
>Counting matching digits:
>          1 234567890123456X
>
>So, the precision is 16 digits, in other words, the precision
>of normal IEEE double.
>
>> One other point though, g_print won't accept the mpfr_t as a long double,
>> so the "%Lf" format won't work.
>And why on Jupiter it should?  mpfr_t is not long double.
>Yeti

If you use the  mpfr_mul  function to use the G_PI in a mpfr_t,  you
will be able to use it. 

The Jupiter comment needs some clarification.  I was talking about
observing something (or hitting a target the size of a quarter ) on Jupiter,
(or even Pluto) from earth.  At those distances like the moon,
the angular resolution provided by c is still good( that is the arc
created by multiplying the radial distance times the angular resolution
is still quite small. But as the radial distance grows, the arc grows.
So the accuracy difference between 
.000000000000001 radians
and 
.00000000000000000000000000000000000000000001 radians
becomes large enough to be noticable. (Large enough to miss the quarter)
################################################################

Regardless of all this OT astronomical stuff, it brings up the question
of could a future GLib incorporate the mpfr and gmp libraires, to create a 
new special precision type, that would be seamless, so that when
that data type is used, all the associated math functions would automatically
be called.  So that g_print would accept something like "%LLf" and accept 
the mpfr_t and print it to all it's accuracy?

Maybe have a configure option for GLib, to include extra precision floats?
The mpfr and gmp libs are open source and free to use.

zentara

-- 
I'm not really a human, but I play one on earth.
http://zentara.net/japh.html