Re^2: PDL datatype

Hmmmm... thats interesting moklevat.... When I do what you did I get a non truncated numbers! I did a few tests and take a look at this:

[njs@localhost Shu_Hardness_Ratios]$ perldl
perlDL shell v1.33
 PDL comes with ABSOLUTELY NO WARRANTY. For details, see the file
 'COPYING' in the PDL distribution. This is free software and you
 are welcome to redistribute it under certain conditions, see
 the same file for details.
ReadLines, NiceSlice, MultiLines  enabled
Reading PDL/default.perldlrc...
Found docs database /usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thre
+ad-multi/PDL/pdldoc.db
Type 'help' for online help
Type 'demo' for online demos
Loaded PDL v2.4.3

Note: AutoLoader not enabled ('use PDL::AutoLoader' recommended)

perldl> $x=50137.685706
perldl> print $x
50137.685706

perldl> $x=pdl(50137.685706)
perldl> print $x
50137.685706

perldl> $x=zeroes(1)
perldl> use PDL::NiceSlice
perldl> $x(0) .= 50137.685706
perldl> print $x
[ 50137.686]

perldl> $x = rcols "bursts.txt"
Reading data into piddles of type: [ Double ]
Read in  33  elements.
perldl> print $x
[ 50093.199  50094.308  50954.953  51767.383  51958.219  52005.696  52
+005.763  52142.188  52422.043  52459.414  52482.509  52693.953  52752
+.918  52836.803  52837.198  53107.974  53125.429   53141.53  53198.49
+5  53243.578  53489.381  53603.709   53661.37  53724.982  53724.983  
+53864.724  53882.002  53969.248  54224.674  54225.636  54304.474  543
+04.539  54366.513]
[download]

So if you type the number in straight its no problem, but if you read it from a file using rcols, or if you define a piddle and then put the number into the pre-existing piddle, then it truncates the number! I wonder why it does this?
In the PDL manual 'double' is the biggest data type listed so I on;y really understand why creating a piddle with this number in works one way and not another - or how to fix it.
I'd love to give you an example of the previous code it was failing in but I've re-written that with my aforementioned inelegant work around.

Comment on Re^2: PDL datatype Download Code

Replies are listed 'Best First'.
Re^3: PDL datatype by etj (Priest) on Jun 07, 2022 at 03:45 UTC
PDL::Core (which stringifies ndarrays) uses these variables: `$PDL::floatformat = "%7g"; # Default print format for long numbers $PDL::doubleformat = "%10.8g";` [download] And when it is stringifying, as you asked it to do, it uses the values of those. The above is the current (2.080) values, but those have been the same since 2.002 back in 1999. However, `printf`'s `g` format treats the precision (the number after the ".", here 8) like so: The precision specifies the number of significant digits. 50137.686 has 8 significant digits. To change this behaviour, just assign a different value to e.g. `$PDL::doubleformat`. The way I checked the above was my usual technique: use `git log -p -w` and text-search for a relevant string, here "floatformat".	[reply] [d/l] [select]
Re^3: PDL datatype by moklevat (Priest) on Nov 29, 2007 at 21:12 UTC
It turns out it may not be so interesting now that my head is on a bit straighter. Assigning `$x=50137.585706` does not create a piddle, as I would have known if I had bothered to `print info($x)`. I previously looked into adding a new types when the topic of using BigInts in piddles came up a while back, but I had to get back to my actual work. It may be that creating a new type would get you where you want to go.	[reply] [d/l] [select]
Re^4: PDL datatype by etj (Priest) on Jun 07, 2022 at 04:14 UTC
Adding a new type, as linked above, is a matter of creating extra options in the various places where PDL types live: conversion functions in Perl-land, type-specifiers for various PDL functions in Perl-land, type-qualifiers in PP function signatures, etc. Until about 2.035, it took extra manual stuff to hook up further types, including the (it turned out unnecessary) manually-hardcoded casting between various C types (it turned out the C standard and compiler can handle that all 100% fine). With the changes there, those manual activities became minimal, which made it easy(ish) to add further C types like C99 complex numbers, the rest of the integer types, and long doubles. However, and this is quite important, PP only provides text-expansion of provided `Code` (etc) chunks into parts of `switch` statements inside the various functions that make up the API of a PDL operation. The expanded text still needs to compile as C. This would mean that to support big ints, or MPFR, something would need to turn atomic C operations on C atomic-type (as I am calling them here) numbers (+,-,*,/,etc) into the appropriate version for those non-atomic types. That would involve parsing the actual C and making substitutions. This is not impossible, and using e.g. Pegex would make it manageable, but it would be significant work. On the plus side, it might facilitate moving to using e.g. OpenCL. See https://github.com/PDLPorters/pdl/issues/349 for more and/or to contribute!	[reply] [d/l] [select]
Re^4: PDL datatype by nickschurch (Acolyte) on Dec 03, 2007 at 01:59 UTC
but `$x=pdl(50137.685706)` should create a piddle and, as I showed in my previous post, this works and sucessfully hold the whole number?!	[reply] [d/l]