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

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 bug-gsl@gnu.org, 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.

Comment on Re^7: Math::GSL::SparseMatrix is broken if installed on latest 5.32.1.1 "Strawberry Perl PDL edition", whom to report this issue to? Select or Download Code

Replies are listed 'Best First'.
Re^8: Math::GSL::SparseMatrix is broken if installed on latest 5.32.1.1 "Strawberry Perl PDL edition", whom to report this issue to? by syphilis (Archbishop) on Nov 13, 2022 at 12:58 UTC
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; } [download] 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. [download] 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	[reply] [d/l] [select]
Re^9: Math::GSL::SparseMatrix is broken if installed on latest 5.32.1.1 "Strawberry Perl PDL edition", whom to report this issue to? [OT] by Anonymous Monk on Nov 15, 2022 at 22:34 UTC
I don't see a good reason that the 4th run should blow up No more virtual memory? 10% non-zero elements are assumed by default. Auto managed PF is 3 x RAM max. I see "Commit size" close to 30 GB for process when `gsl_spmatrix_alloc(80000,80000)`, can go no further. My 8 GB RAM (less than 6 is free) + 24 GB PF sums up OK to this "30". My guess is you have 16 GB + same auto-managed PF, and "Commit size" would be ~56 GB or so for 95K by 95K matrix.	[reply] [d/l]
Re^10: Math::GSL::SparseMatrix is broken if installed on latest 5.32.1.1 "Strawberry Perl PDL edition", whom to report this issue to? [OT] by syphilis (Archbishop) on Nov 16, 2022 at 06:05 UTC
No more virtual memory? Ok - that would mean that "there are some mysterious rules of usage that I am overlooking". In fairness to them, perhaps that's not at all "mysterious" - but I wasn't expecting that sufficient memory would be allocated to actually store so many zeros. Thanks for the discussion. It was interesting to poke at (part of) the GSL library again. Cheers, Rob	[reply]
Re^11: Math::GSL::SparseMatrix is broken if installed on latest 5.32.1.1 "Strawberry Perl PDL edition", whom to report this issue to? [OT] by Anonymous Monk on Nov 16, 2022 at 06:53 UTC


go ahead... be a heretic
	PerlMonks