Re^5: 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]

Did you compile it from shell, created with portableshell.bat of Strawberry Perl 5.32.1-PDL? If I'm not using this shell, then gsl_spmatrix.exe complains it can't find libgsl-25__.dll, which would be in PATH created with portableshell.bat. I'm confused about this "25", does it mean anything? Should it be "26", i.e. is it "clean and correct" GSL 2.6 which ships with PDL-SP?

Using "gsl-2.7.1 library provided by Alien", there's no such complaint. I can only add, that "v += 1;" is not special. If 1st setter sets at index 2, then "v += 2;" leads to "out of range". They both set the same element. If two setters set different values, and 1st getter gets value after that, then it retrieves value set by 2nd setter. 1st value was overwritten.

I haven't reported yet, would it be better to write to both GSL and Math::GSL queues? (Math::GSL ignores whatever Alien::GSL has built) Or reporting to Math::GSL is enough, they'll see further?

[syphilis]

Did you compile it from shell, created with portableshell.bat of Strawberry Perl 5.32.1-PDL?

Yes.

----------------------------------------------
 Welcome to Strawberry Perl PDL Edition!
 * URL - http://strawberryperl.com + http://pdl.perl.org
 * to launch perl script run:      perl c:\my\scripts\pdl-test.pl
 * to start PDL console run:       pdl2
 * to update PDL run:              cpanm PDL
 * to install extra module run:    cpanm PDL::Any::Module
          or if previous fails:    ppm PDL::Any::Module
 * or you can use dev tools like:  gcc, g++, gfortran, gmake
 * see README.TXT for more info
----------------------------------------------
Perl executable: D:\sp\_64\sp-5.32.1-PDL\perl\bin\perl.exe
Perl version   : 5.32.1 / MSWin32-x64-multi-thread
PDL version    : 2.025

D:\sp\_64\sp-5.32.1-PDL>cd \C

D:\C>gcc -o gsl_spmatrix.exe gsl_spmatrix.c -ID:/sp/_64/sp-5.32.1-PDL/
+c/include -LD:/sp/_64/sp-5.32.1-PDL/c/lib -lgsl -lgslcblas -lm

D:\C>gsl_spmatrix.exe
size of _size_t is 8 bytes
1: got: 1.500000
1: nnz: 1
will be reported as 'out of range'
gsl: getset_source.c:27: ERROR: first index out of range
Default GSL error handler invoked.

D:\C>


I'm confused about this "25", does it mean anything?

I think that's ok. I'm quite used to seeing dll numberings that don't make any sense.
My SP-5.32.1-PDL certainly ships with c/bin/libgsl-25__.dll and I'm not seeing anything unusual happening (apart from the buggy behaviour.)

Using "gsl-2.7.1 library provided by Alien", there's no such complaint.

Are you sure that it's actually using gsl-2.7.1 ? Here's an improved C program that will output that info:

#include <stdio.h>
#include <stdlib.h>
#include <gsl/gsl_spmatrix.h>
#include <gsl/gsl_version.h>

int main(void) {
 size_t v = 1;
 v <<= 32;
 v += 1;
 printf("gsl header version : %s\n", GSL_VERSION);
 printf("gsl library version: %s\n", gsl_version);
 printf("size of _size_t is %d bytes\n", sizeof(size_t));
 if(v == 1) printf("WTF\n");
 gsl_spmatrix *m = gsl_spmatrix_alloc(1,1);
 gsl_spmatrix_set( m, 1, 0, 1.5 );
 printf("1: got: %f\n", gsl_spmatrix_get( m, 1, 0));
 printf("1: nnz: %d\n", gsl_spmatrix_nnz( m ));
 gsl_spmatrix_set( m, v, 0, 1.75 );
 if (v >= m->size1) printf("will be reported as 'out of range'\n");
 printf("2: got: %f\n", gsl_spmatrix_get( m, v, 0 ));
 printf("2: nnz: %d\n", gsl_spmatrix_nnz( m ));
 return 0;
}



If 1st setter sets at index 2, then "v += 2;" leads to "out of range". They both set the same element

I don't understand this.
Are you claiming that v + 2 == 2 ?
While that might be deemed true on a 32-bit system, it's not the case when sizeof(size_t) is 8.
Could you provide the perl -V output of your Strawberry-5.32.1-PDL. (Maybe I've missed something significant.)

D:\C>perl -le "$x = (1 << 32) + 2; print $x; print 'WTF' if $x == 2;"
4294967298


Cheers,
Rob

[Anonymous Monk]

Yes, it was using gsl-2.7.1, and no, what I was claiming was 1st setter sets some value at index e.g. 2; 2nd setter sets some value at index "v" which (index) would be 0x100000002.

+ I'm bad communicator + my bad English :). Sorry. OK, forget the above, I found something which maybe will entertain you. I went as far as to boot 22.04 LTS Ubuntu from USB stick, to confirm that 2.7 "official" Debian GSL demonstrates same behaviour, using very similar, to what you posted, C program. And I mailed a bug report to [e-mail], which their robot bounced back at me couple hours later because of text/html content-type of my letter.

Now I think maybe it was good, because of what I found in meantime. There was significant overhaul of sparse matrix code from version 2.5 to 2.6 of GSL. Actually, NEWS for 2.6 don't mention "no more 64-bit indexing". But maybe it was quite intentional, and NOT documented because "ha, no one is using long long indexes anyway".

We can see size_t type of row/column index (i.e. i and p) in 2.5.

Then they (i and p) were suddenly changed to int in 2.6. Someone went as far as to change %zu to %d format specifier in example file, they were meticulous in what they were doing, how can it be a "bug"? Perhaps it was to optimise speed/space, etc.

This int type is documented in top-level nicely-formatted manual for 2.7. I should have noticed that. Can't call it a "bug" now. If not, it's very sad and messy and not to the level of "GSL is a mature library with a stable API".

So... what's the crust, I'm sorry to have wasted your time, should have done more research? :( Report to Math::GSL queue about "what Alien::GSL compiles is ignored in Windows" seems unimportant if above is correct.

[syphilis]

they were meticulous in what they were doing, how can it be a "bug"?

I keep hitting behaviour that is very weird.
Having compiled the following program into an executable

#include <stdio.h>
#include <stdlib.h>
#include <gsl/gsl_spmatrix.h>
#include <gsl/gsl_version.h>

int main(int argc, char * argv[]) {
 long t, initial_value,left_shift, addon;
 initial_value = strtol(argv[1], NULL, 10);
 left_shift    = strtol(argv[2], NULL, 10);
 addon         = strtol(argv[3], NULL, 10);
 size_t v = (size_t)initial_value;
 v <<= (size_t)left_shift;
 v += (size_t)addon;
 printf("gsl header version : %s\n", GSL_VERSION);
 printf("gsl library version: %s\n", gsl_version);
 printf("size of _size_t is %d bytes\n", sizeof(size_t));
 printf("initial value: %d\nleft shift: %d\naddon: %d\n", initial_valu
+e, left_shift, addon);

 gsl_spmatrix *m = gsl_spmatrix_alloc(v,v);
 printf("size1: %lu\nsize2: %lu\nnz: %lu\n", m->size1, m->size2, m->nz
+);

 return 0;
}

I then execute it 4 times with different input arguments:

D:\C>gsl_spm.exe 1 16 28000
gsl header version : 2.7.1
gsl library version: 2.7.1
size of _size_t is 8 bytes
initial value: 1
left shift: 16
addon: 28000
size1: 93536
size2: 93536
nz: 0

D:\C>gsl_spm.exe 1 16 28001
gsl header version : 2.7.1
gsl library version: 2.7.1
size of _size_t is 8 bytes
initial value: 1
left shift: 16
addon: 28001
size1: 93537
size2: 93537
nz: 0

D:\C>gsl_spm.exe 1 16 28002
gsl header version : 2.7.1
gsl library version: 2.7.1
size of _size_t is 8 bytes
initial value: 1
left shift: 16
addon: 28002
size1: 93538
size2: 93538
nz: 0

D:\C>gsl_spm.exe 1 16 29002
gsl header version : 2.7.1
gsl library version: 2.7.1
size of _size_t is 8 bytes
initial value: 1
left shift: 16
addon: 29002
gsl: init_source.c:144: ERROR: failed to allocate space for data
Default GSL error handler invoked.

The first three runs seem quite sane to me, but I don't see a good reason that the 4th run should blow up like that just because the third command line argument has been raised by 1000.
Maybe it's optimization at the expense of correctness ?
Or maybe there are some mysterious rules of usage that I am overlooking. (I don't normally use the GSL library at all.)
I get the same results with gsl-2.6.1.

Cheers,
Rob