Math::GSL::SparseMatrix is broken if installed on latest 5.32.1.1 "Strawberry Perl PDL edition", whom to report this issue to?

[Anonymous Monk]

The intent was to use sparse matrix (vector) with very large indices, expressed as 64-bit integers.

use strict;
use warnings;
use feature 'say';

use Math::GSL::SparseMatrix ':all';

my $m = gsl_spmatrix_alloc( 1, 1 );

die if gsl_spmatrix_set( $m, 0, 0, 1 );
say gsl_spmatrix_nnz( $m );
die if gsl_spmatrix_set( $m, 123 + 1 << 32, 0, 1 );
say gsl_spmatrix_nnz( $m );
die if gsl_spmatrix_set( $m, 456 + 1 << 32, 0, 1 );
say gsl_spmatrix_nnz( $m );

The "OK" output is "1 2 3" (newlines instead of spaces), failure, as observed, is "1 1 1".

I used to be able to do "OK" with 5.26 "Strawberry Perl PDL Edition", with relevant PDL, Math::GSL, Alien::GSL, etc., of a few years ago. Now (hours of tests and frustration skipped), output is "OK" with

• (1) portable 5.32.1.1 Strawberry Perl freshly unpacked and latest Math::GSL installed,
• (2) portable 5.32.1.1 Strawberry Perl freshly unpacked, latest PDL installed, and Math::GSL installed.

Failure is with

• (3) portable 5.32.1.1 Strawberry Perl PDL Edition freshly unpacked, and latest Math::GSL installed,
• (4) same as above, but PDL upgraded either before or after installing Math::GSL.

I don't know whose bug is that. Only issue with Math::GSL, in my view, is it doesn't test against such failure, can't anticipate everything, maybe they'll add it in retrospect. Issue with PDL is it's in title of Perl distribution that fails, can't blame them. If it's issue with "Strawberry" pack, don't know how to prove it's their issue, besides unfortunately looks like it's nobody to prove it to anymore. Whew, at least it's documented here now and could save some poor soul hours of bug hunting.

[swl]

The metadata for Math::GSL lists its issue tracker as RT: https://rt.cpan.org/Public/Dist/Display.html?Name=Math-GSL

Perhaps report there first?

Edit: Although there are also issues on the github repo: https://github.com/leto/math--gsl/issues.

[swl]

It would also help to know the various versions you are running. e.g.:

(Edit: 5.30.0 passes, updated comment below)

perl -MPDL -MAlien::GSL -E "say join ' ', Alien::GSL->version, Alien::
+GSL->install_type; say $PDL::VERSION"

On my SP portable 5.28.0 (which passes) this returns

2.3 system
2.077

On 5.30.0 (passes):

2.5 system
2.060

On 5.32.1 (fails):

2.6 system
2.077

[Anonymous Monk]

Thanks for looking into this. For my case (2) (non-PDL SP 5.32.1.1, then PDL installed, then Math::GSL), which passes:

2.7.1 share
2.081

For my case (4) (PDL SP 5.32.1.1, then PDL upgraded, then Math::GSL installed), which fails:

2.6 system
2.081

[syphilis]

Hi,

Strawberry's PDL build ships with gsl-2.6. (The non-PDL build does not include a gsl library, and I'm guessing that installing PDL into the non-PDL build will not, of itself, install a locatable gsl library.)
It seems that both "(3)" and "(4)" are using gsl-2.6, whereas both "(1)" and "(2)" are avoiding the issue by installing and using gsl-2.7.1.

It could be that "(3)" and/or "(4)" did install 2.7.1 (I don't know) but they still find and use the buggy 2.6 version that shipped with Strawberry Perl-5.32.1.1-PDL.
You just need to ensure that the non-buggy 2.7.1 gets loaded and used.
At least, that's how it looks to me.

Cheers,
Rob

[swl]

Maybe it's a GSL version issue? What happens if you force a share install in your case 4 to ensure it upgrades?

set ALIEN_INSTALL_TYPE=share
cpanm Alien::GSL

You might need to then reinstall Math::GSL:

cpanm --reinstall Math::GSL

[syphilis]

The "OK" output is "1 2 3" (newlines instead of spaces), failure, as observed, is "1 1 1"

Hmmm ... if, in the script procided by the OP, I replace:

123 + 1 << 32
with
123 + (1 << 32)

and I replace:

456 + 1 << 32
with
456 + (1 << 32)

then I get the "OK" output of "1 2 3".

I wonder if that's what the OP meant to do ?
Given that "123 + 1 << 32" evaluates to exactly the same as "124 << 32", it seems strange to choose the former expression in preference to the latter.
Similarly "456 + 1 << 32" evaluates to exactly the same as "457 << 32".
Is the OP's problem no more than a typo ?

On a perl whose ivsize is 8 (bytes):

D:\>perl -le "print 'ok' if 123 + 1 << 32 == 124 << 32 && 456 + 1 << 3
+2 == 457 << 32;"
ok


Cheers,
Rob

[Anonymous Monk]

Thanks, Rob, this was really bad choice, on my part, of example data, and I appreciate you pointed this out.

With real script, I'm observing smaller matrix population (non-zero elements count) after feeding 64-bit data in, than expected, when running with 5.32 PDL-SP (2.6 GSL), compared to correct count (population equals items fed in) running with 5.26 PDL-SP (2.3 GSL).

Then I tried to present exaggerated examples, and, yes, you are right, I messed operator precedence, and so result looks silly and not trustworthy.

There's still wrong output of "1 1" with:

die if gsl_spmatrix_set( $m, 1, 0, 1 );
say gsl_spmatrix_nnz( $m );
die if gsl_spmatrix_set( $m, 1 + (1 << 32), 0, 1 );
say gsl_spmatrix_nnz( $m );

or similar. I mean, my blunder doesn't cancel out Math::GSL (and perhaps GSL) issues.

[syphilis]

I messed operator precedence, and so result looks silly and not trustworthy

Oh, no worries - that happens. (I know ;-)
For me, irrespective of the values assigned in the script, both gsl-2.6 and gsl-2.7.1 produce the same results.
That would suggest that the problem lies with the recent versions of the gsl library.
But, of course, the way I built Math-GSL-0.43 against gsl-2.7.1 (along with the test failures) doesn't inspire complete confidence in it ;-(

Playing around with it a bit, I find there's something (very strangely) buggy for the index 1 + (1 << 32), with both gsl-2.6 and gsl-2.7.1.
Have a fiddle with this, and you'll see what I mean:

use strict;
use warnings;
use feature 'say';
use Alien::GSL;
use Math::GSL;
use Math::GSL::SparseMatrix ':all';

my $m = gsl_spmatrix_alloc( 1, 1 );

my $v;

#$v = 3 + (1 << 32); # no problem with this value
#$v = 2 + (1 << 32); # no problem with this value
#$v = 0 + (1 << 32); # no problem with this value
$v = 1 + (1 << 32); # blows up, but only if
                    # gsl_spmatrix_get($m, $v, 0)
                    # is called. 

die if gsl_spmatrix_set( $m, 1, 0, 1.5 );
say gsl_spmatrix_get($m, 1, 0);
say gsl_spmatrix_nnz( $m );
die if gsl_spmatrix_set( $m, $v, 0, 1.75 );
say gsl_spmatrix_get($m, $v, 0); # comment out to avoid blow up
                                  # when $v is 1 + (1 << 32).
                                  # But still gives wrong result
                                  # (for that value only).
say gsl_spmatrix_nnz( $m );

The first thing to try is to run that as a C program and see if the same issue arises.
If not, then it's an issue with Math::GSL.
It's getting late over here ... something for tomorrow.

Cheers,
Rob