PDL::string() should be documented/recommended, and/or stringification improved

[vadim-160102]

(All of what follows is fixed with call to (undocumented?) PDL::string("required template") instead of default stringification)

This is just cosmetic annoyance, not "bug" as such, but close to it. These are supposed to control stringification, with their defaults:

$PDL::floatformat  = "%7g";
$PDL::doubleformat = "%10.8g";
$PDL::indxformat   = "%12d";

Is "%7g" the same as "%7.6g"? Then why not to be explicit, and why 7/6 vs. 10/8, i.e. "1" vs "2" difference, any reason? The above vars are of limited use only; format of no integral type is controlled in any way, "indx" is not really for integers. Consider:

pdl> $x = sequence( 3 + 1e7 )
pdl> p which( $x > 1e7 - 4 )
[9999997 9999998 9999999     10000000     10000001     10000002]
pdl> p where( $x, $x > 1e7 - 4 )
[9999997 9999998 9999999 10000000   10000001   10000002]
pdl> p where( long($x), $x > 1e7 - 4 )
[9999997 9999998 9999999 10000000 10000001 10000002]

This default formatting of 3 ndarrays is weird. While their contents appear to be the same, I of course understand they are not, but then magick "7" (see

pdl/Basic/Core/Core.pm

Line 3405 in d144131

if ($dformat && length($t)>7) { # Try smaller

) constant should be eliminated.

Another illustration:

pdl> $PDL::doubleformat = '%.2g'
pdl> p pdl map $_/16, 0..8
[0 0.0625 0.125 0.1875 0.25 0.3125 0.375 0.4375 0.5]

I see it doesn't work, but then remember uniform nice gaps are also required for my presentation, and try:

pdl> $PDL::doubleformat = '%8.2g'
pdl> p pdl map $_/16, 0..8
[0 0.0625 0.125 0.1875 0.25 0.3125 0.375 0.4375 0.5]

No, same result.

[mohawk2]

Thanks for the report. The string method is now documented. I've removed the special case for a 1-D ndarray per element, and now for 1-D it uses the format if given, or just stringifies, so it's more consistent. More changes than that are sadly impossible, because a lot of tests depend on the behaviour of string as it is now.