Hi zentara

The core of PDL is written in the C programming language (see PDL::Internals). Fortran is only used in some libraries such as PGPLOT (used for plotting) and Slatec (used for manipulating matrices, calculate Fast Fourier Transforms, fit data using polynomials, interpolate data, etc.). About the piddles' data types, here is a table that will show you the data types already defined (in the file Basic/Core/Types.pm.PL):

PDL Type      Real C Type
----------    --------------
byte           unsigned char
short          short
ushort         unsigned short
long           long int
longlong       long long int
float          float
double         double
[download]

Note that you can add new types as explained in the PDL documentation. You might also want to read the documentation on PDL::PP to learn how to add your own routines.

In short, I believe the computational accuracy of PDL to be closer to that of C than to the computational accuracy of Fortran.

Cheers,

Dare i ask why they decided to change the data type names? I'm assuming it has to do something with how the data type is represented in perl?

meh.

I'm not a c compiler expert, but have a look at double precision pi It may be the difference between computational precision and "%Lf" display precision. I started looking into it, when I questioned the way GLib defined pi as a constant. They defined it out to 50 decimal places, but any use of it in it's long double is limited to 15 decimal places.

One of the c gurus in that thread said that c's precision is only gauranteed to 10 decimal places, but with IEEE standards, it's common to see 15. I see 15.

Eventually, I found mpfr which lets you set how many digits of precision you want to use.

If you can show me a simple c program that computes and displays values out to 50 decimal places, with normal c, I would be greatful. Everything I see truncates it (pi) to 3.(15 decimal places).

For example, in this code, the value of pi is correctly printed as a string on the first line of output, but the subsequent lines all have garbage after the 15th decimal place.

#include <gtk/gtk.h>
/* gcc -o test test.c `pkg-config --cflags --libs gtk+-2.0` */

int  main (){ 
/* how the headers define G_PI */
/* #define G_PI   3.1415926535897932384626433832795028841971693993751 
+ 
*/

 long double PI = G_PI;

g_print("3.1415926535897932384626433832795028841971693993751\n");
g_print("%0.50e\n",G_PI);
g_print("%0.50Lf\n",G_PI);
g_print("%0.50Lf\n",PI);
g_print("%0.50Lg\n",PI);
g_print("%0.50Le\n",PI);
  
return 0; 
}
[download]

Output:

                                 ^^^^^^^^^^^ ->  unstable after 15 dec
+imal 
3.1415926535897932384626433832795028841971693993751
3.14159265358979311599796346854418516159057617187500e+00
-0.00000000000000000000000000000000000000000000000000
3.14159265358979311599796346854418516159057617187500
3.141592653589793115997963468544185161590576171875
3.14159265358979311599796346854418516159057617187500e+00
                                 ^^^^^^^^^^^^ -> unstable after 15 dec
+imal
[download]

---

I'm not really a human, but I play one on earth. Cogito ergo sum a bum

Eventually, I found mpfr which lets you set how many digits of precision you want to use.

Then there's really no need to look further - it's an excellent library. Incidentally, I placed a module (Math::MPFR) on CPAN that wraps the documented mpfr functions. I think I'm the only person that uses it. If you ever take a look at it, I'd be interested on any feedback. I believe it functions well, but there are aspects which bother me - eg, the documentation, the naming of the functions, and the fact that I wrote all of the XS functions "longhand" (as opposed to using a typemap).

Anyway ... back to the consideration of long doubles. Recent versions of mpfr allow you to convert directly from an mpfr_t to a long double, so one could do something like the following:

mpfr_t mpfr_pi;
long double ld_pi;

mpfr_set_default_prec(sizeof(long double) * 8);

mpfr_init(mpfr_pi);
mpfr_const_pi(mpfr_pi, GMP_RNDN);

ld_pi = mpfr_get_ld(mpfr_pi, GMP_RNDN);
[download]

I would expect that ld_pi and mpfr_pi would contain the same value, though there's no guarantee that I'm correct. I was actually hoping to have a bit of a play with this at work tonight, but a last minute breakdown made a complete mess of that plan. (I may yet take a closer look and send you an /msg, as it's not really on-topic for either this forum or this particular thread).

Perhaps long doubles don't provide the precision that I expect - I've never checked. Or perhaps it's just an issue with printf or a general problem with C (as you suggested). Or perhaps it's just an issue with Glib. It would be interesting to know ....

Cheers,
Rob