Re: [Pdl-general] Changes I noted PDL2.025 -> PDL2.084 - rcols issue

[Karl Glazebrook via pdl-general]

Seems I can’t help myself! I have now found the offending line in rcols() and 
can now reproduce this without rcols. That should at least make it easier to 
track down.

use PDL;
$x = sequence(100)+1; # This works
$x = $x->mv(-1,0)->slice("0:3");
print $x, "\n";
$x *= 100;
print $x, "\n";
$y=&PDL::_clump_int($x,-1);
print $y, "\n"; # prints [0 0 0 0]
1;

It seems to be the particular combination of ->mv and ->slice (that was on line 
693 of misc.pd). This is a 1D ndarray so the ->mv(-1,0) should do nothing. 
Removing it however makes the problem go away.

Works fine in PDL-2.025. Some bug that has been introduced in ->mv ?

Sorry to the stream of consciousness series of emails. I will stop looking 
now...

Karl




> On 7 Jan 2024, at 4:32 pm, Karl Glazebrook  wrote:
> 
> OK here is some deeper diving in to the problem
> 
> 
> use PDL;
> $x = rcols 'tmp.dat'; # This does causes the error
> #$x = sequence(4)+1; # This works
> print $x, "\n";
> $x *= 100;
> print $x, "\n";
> $y=&PDL::_clump_int($x,-1);
> print $y, "\n"; # prints [0 0 0 0]
> ;
> 
> 
> 
>  looks like the error is happening in the internal pp routine _clump_int in 
> slices.pd.
> 
> 
> I also found ->sever() had the same behaviour with rcols:
> 
> pdl> $x = rcols 'tmp.dat' 
>  
> Reading data into ndarrays of type: [ Double ]
> Read in  4  elements.
> 
> pdl> $x *= 100
>  
> 
> pdl> p $x 
>  
> [100 200 300 400]
> pdl> p $x->sever  
>  
> [0 0 0 0]
> 
> 
> Note this is not a general problem with dataflow, if I make a sequence and 
> slice or index is then the ops work fine. It is just something weird on the 
> ndarray produced by rcols.
> 
> Karl
> 
> 
> 
> 
> 
>> On 7 Jan 2024, at 3:41 pm, Karl Glazebrook via pdl-general 
>> > > wrote:
>> 
>> Ah! I believe the difference between medover and median is a clump(-1) to 
>> collapse the dimensions
>> 
>> There does it indeed to be something wrong with clump too, so that is 
>> probably the underlying cause
>> 
>> pdl> $x = rcols 'tmp.dat'
>>
>> Reading data into ndarrays of type: [ Double ]
>> Read in  4  elements.
>> 
>> pdl> p $x
>>
>> [1 2 3 4]
>> pdl> $x *= 100   
>>
>> 
>> pdl> p $x
>>
>> [100 200 300 400]
>> pdl> p $x->clump(-1) 
>>
>> [0 0 0 0]
>> 
>> What could be happening in rcols() that produces an ndarray that behaves 
>> like that?
>> 
>> Karl
>> 
>> 
>>> On 7 Jan 2024, at 12:48 pm, Luis Mochan >> > wrote:
>>> 
>>> I noticed that medover and maxover do work as expected in this case.
>>> 
>>> 
>>> On Sun, Jan 07, 2024 at 11:26:56AM +1100, Karl Glazebrook via pdl-general 
>>> wrote:
 Hi all,
 
 This dinosaur just upgraded from PDL v2.025 to v.2.084 (yes, I know that 
 is lame)
 
 I noticed a few things when running one of my complicated codes, I will 
 start seperate email threads
 
 First there seems to be a serious rcols bug:
 
 
 e.g. create a file
 
 # tmp.dat
 1
 2
 3
 4
 
 
 Loaded PDL v2.084 (supports bad values)
 pdl> $x = rcols 'tmp.dat'
 Reading data into ndarrays of type: [ Double ]
 Read in  4  elements.
 
 pdl> p $x
 [1 2 3 4]
 pdl> $x *= 100
 
 pdl> p $x
 [100 200 300 400]
 pdl> p median($x)
 0
 pdl> p $x
 [100 200 300 400]
 
 
 It seems the median function sees the values BEFORE the inplace 
 multiplacation, whereas print does not. This is very bad. min() and max() 
 are similar. No idea what is going on here! The behaviour or absent from 
 v2.025
 
 Notes
 - making a $x->copy() removes the effect
 - creating $x using sequence also removes, so it is something to do with 
 rcols() and not inplace in general?
 
 I’d be interested to know if others can reproduce this. It definitely 
 needs a fix
 
 best
 
 Karl
>>

Re: [Pdl-general] Changes I noted PDL2.025 -> PDL2.084 - rcols issue

[Karl Glazebrook via pdl-general]

OK here is some deeper diving in to the problem


use PDL;
$x = rcols 'tmp.dat'; # This does causes the error
#$x = sequence(4)+1; # This works
print $x, "\n";
$x *= 100;
print $x, "\n";
$y=&PDL::_clump_int($x,-1);
print $y, "\n"; # prints [0 0 0 0]
;



 looks like the error is happening in the internal pp routine _clump_int in 
slices.pd.


I also found ->sever() had the same behaviour with rcols:

pdl> $x = rcols 'tmp.dat'   
   
Reading data into ndarrays of type: [ Double ]
Read in  4  elements.

pdl> $x *= 100  
   

pdl> p $x   
   
[100 200 300 400]
pdl> p $x->sever
   
[0 0 0 0]


Note this is not a general problem with dataflow, if I make a sequence and 
slice or index is then the ops work fine. It is just something weird on the 
ndarray produced by rcols.

Karl





> On 7 Jan 2024, at 3:41 pm, Karl Glazebrook via pdl-general 
>  wrote:
> 
> Ah! I believe the difference between medover and median is a clump(-1) to 
> collapse the dimensions
> 
> There does it indeed to be something wrong with clump too, so that is 
> probably the underlying cause
> 
> pdl> $x = rcols 'tmp.dat' 
>  
> Reading data into ndarrays of type: [ Double ]
> Read in  4  elements.
> 
> pdl> p $x 
>  
> [1 2 3 4]
> pdl> $x *= 100
>  
> 
> pdl> p $x 
>  
> [100 200 300 400]
> pdl> p $x->clump(-1)  
>  
> [0 0 0 0]
> 
> What could be happening in rcols() that produces an ndarray that behaves like 
> that?
> 
> Karl
> 
> 
>> On 7 Jan 2024, at 12:48 pm, Luis Mochan > > wrote:
>> 
>> I noticed that medover and maxover do work as expected in this case.
>> 
>> 
>> On Sun, Jan 07, 2024 at 11:26:56AM +1100, Karl Glazebrook via pdl-general 
>> wrote:
>>> Hi all,
>>> 
>>> This dinosaur just upgraded from PDL v2.025 to v.2.084 (yes, I know that is 
>>> lame)
>>> 
>>> I noticed a few things when running one of my complicated codes, I will 
>>> start seperate email threads
>>> 
>>> First there seems to be a serious rcols bug:
>>> 
>>> 
>>> e.g. create a file
>>> 
>>> # tmp.dat
>>> 1
>>> 2
>>> 3
>>> 4
>>> 
>>> 
>>> Loaded PDL v2.084 (supports bad values)
>>> pdl> $x = rcols 'tmp.dat'
>>> Reading data into ndarrays of type: [ Double ]
>>> Read in  4  elements.
>>> 
>>> pdl> p $x
>>> [1 2 3 4]
>>> pdl> $x *= 100
>>> 
>>> pdl> p $x
>>> [100 200 300 400]
>>> pdl> p median($x)
>>> 0
>>> pdl> p $x
>>> [100 200 300 400]
>>> 
>>> 
>>> It seems the median function sees the values BEFORE the inplace 
>>> multiplacation, whereas print does not. This is very bad. min() and max() 
>>> are similar. No idea what is going on here! The behaviour or absent from 
>>> v2.025
>>> 
>>> Notes
>>> - making a $x->copy() removes the effect
>>> - creating $x using sequence also removes, so it is something to do with 
>>> rcols() and not inplace in general?
>>> 
>>> I’d be interested to know if others can reproduce this. It definitely needs 
>>> a fix
>>> 
>>> best
>>> 
>>> Karl
>>> 
>>> 
>>> 
>> 
>> 
>>> ___
>>> pdl-general mailing list
>>> pdl-general@lists.sourceforge.net 
>>> https://lists.sourceforge.net/lists/listinfo/pdl-general
>> 
>> 
>> -- 
>> 
>>  o
>> W. Luis Mochán,  | tel:(52)(777)329-1734 /<(*)
>> Instituto de Ciencias Físicas, UNAM  | fax:(52)(777)317-5388 `>/   /\
>> Av. Universidad s/n CP 62210 |   (*)/\/  \
>> Cuernavaca, Morelos, México  | moc...@fis.unam.mx 
>>    /\_/\__/
>> GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16  C2DF 5F0A C52B 791E B9EB
> 
> ___
> pdl-general mailing list
> pdl-general@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/pdl-general

___
pdl-general mailing list
pdl-general@lists.sourceforge.net
h

Re: [Pdl-general] Changes I noted PDL2.025 -> PDL2.084 - rcols issue

[Karl Glazebrook via pdl-general]

Ah! I believe the difference between medover and median is a clump(-1) to 
collapse the dimensions

There does it indeed to be something wrong with clump too, so that is probably 
the underlying cause

pdl> $x = rcols 'tmp.dat'   
   
Reading data into ndarrays of type: [ Double ]
Read in  4  elements.

pdl> p $x   
   
[1 2 3 4]
pdl> $x *= 100  
   

pdl> p $x   
   
[100 200 300 400]
pdl> p $x->clump(-1)
   
[0 0 0 0]

What could be happening in rcols() that produces an ndarray that behaves like 
that?

Karl


> On 7 Jan 2024, at 12:48 pm, Luis Mochan  wrote:
> 
> I noticed that medover and maxover do work as expected in this case.
> 
> 
> On Sun, Jan 07, 2024 at 11:26:56AM +1100, Karl Glazebrook via pdl-general 
> wrote:
>> Hi all,
>> 
>> This dinosaur just upgraded from PDL v2.025 to v.2.084 (yes, I know that is 
>> lame)
>> 
>> I noticed a few things when running one of my complicated codes, I will 
>> start seperate email threads
>> 
>> First there seems to be a serious rcols bug:
>> 
>> 
>> e.g. create a file
>> 
>> # tmp.dat
>> 1
>> 2
>> 3
>> 4
>> 
>> 
>> Loaded PDL v2.084 (supports bad values)
>> pdl> $x = rcols 'tmp.dat'
>> Reading data into ndarrays of type: [ Double ]
>> Read in  4  elements.
>> 
>> pdl> p $x
>> [1 2 3 4]
>> pdl> $x *= 100
>> 
>> pdl> p $x
>> [100 200 300 400]
>> pdl> p median($x)
>> 0
>> pdl> p $x
>> [100 200 300 400]
>> 
>> 
>> It seems the median function sees the values BEFORE the inplace 
>> multiplacation, whereas print does not. This is very bad. min() and max() 
>> are similar. No idea what is going on here! The behaviour or absent from 
>> v2.025
>> 
>> Notes
>> - making a $x->copy() removes the effect
>> - creating $x using sequence also removes, so it is something to do with 
>> rcols() and not inplace in general?
>> 
>> I’d be interested to know if others can reproduce this. It definitely needs 
>> a fix
>> 
>> best
>> 
>> Karl
>> 
>> 
>> 
> 
> 
>> ___
>> pdl-general mailing list
>> pdl-general@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/pdl-general
> 
> 
> -- 
> 
>  o
> W. Luis Mochán,  | tel:(52)(777)329-1734 /<(*)
> Instituto de Ciencias Físicas, UNAM  | fax:(52)(777)317-5388 `>/   /\
> Av. Universidad s/n CP 62210 |   (*)/\/  \
> Cuernavaca, Morelos, México  | moc...@fis.unam.mx   /\_/\__/
> GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16  C2DF 5F0A C52B 791E B9EB

___
pdl-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

Re: [Pdl-general] Changes I noted PDL2.025 -> PDL2.084 - PDL::NiceSlice issue

[Luis Mochan]

I found some time back problems with NiceSlice. Actually, with
Filter::Simple (used by default by NiceSlice, though it can use other
options, controlled with environment variables). I vaguely recall that
two slashes, as in two divisions consecutive, confuse it completely,
as they seem as regular expression.

I found this in my notes of 2022-11-05:
---
Make a filter:
  package MyFilter;
  use v5.36;
  use Filter::Simple;
  FILTER_ONLY
  code_no_comments => sub { say "Code:\n$_" },
  all => sub { say "All:\n$_" };
  1;
And a program:
  use v5.36;
  use lib ".";
  use MyFilter;
  my $x=1;
  say $x/2/3;

Execution yields:

  Code:
  my $x=1;
  say $x3;

  All:
  my $x=1;
  say $x/2/3;

  0.167

This means that /2/ is removed incorrectly. The name of the variable
($x and not $y) seems important.
---

Regards,
Luis




On Sun, Jan 07, 2024 at 12:01:27PM +1100, Karl Glazebrook via pdl-general wrote:
>
>
> > On 7 Jan 2024, at 11:55 am, Karl Glazebrook via pdl-general 
> >  wrote:
> >
> > (The mismatch of line numbers seems to be related to the use of hereto text 
> > earlier in the code, the debugger shows different line numbers)
> >
>
>
> PS just to prove this point given the line numbers issue:
>
>
>
>
> syntax error at /Users/karl/Software/perl/KGB/Redshift.pm line 251, near 
> "$FOO("
> Execution of /Users/karl/Software/perl/KGB/Redshift.pm aborted due to 
> compilation errors.
>
>
>
> You can see FOO triggers a compilation error and BAR does not, use 
> PDL::NiceSlice is way at the top of the module
>
> Karl
>


> ___
> pdl-general mailing list
> pdl-general@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/pdl-general


-- 

  o
W. Luis Mochán,  | tel:(52)(777)329-1734 /<(*)
Instituto de Ciencias Físicas, UNAM  | fax:(52)(777)317-5388 `>/   /\
Av. Universidad s/n CP 62210 |   (*)/\/  \
Cuernavaca, Morelos, México  | moc...@fis.unam.mx   /\_/\__/
GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16  C2DF 5F0A C52B 791E B9EB


___
pdl-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

Re: [Pdl-general] Changes I noted PDL2.025 -> PDL2.084 - rcols issue

[Luis Mochan]

I was able to reproduce it, and I don't understand it. Median, min,
max fail even after printing the updated $x, as if there were to
different variables $x.

On Sun, Jan 07, 2024 at 11:26:56AM +1100, Karl Glazebrook via pdl-general wrote:
> Hi all,
>
> This dinosaur just upgraded from PDL v2.025 to v.2.084 (yes, I know that is 
> lame)
>
> I noticed a few things when running one of my complicated codes, I will start 
> seperate email threads
>
> First there seems to be a serious rcols bug:
>
>
> e.g. create a file
>
> # tmp.dat
> 1
> 2
> 3
> 4
>
>
> Loaded PDL v2.084 (supports bad values)
> pdl> $x = rcols 'tmp.dat'
> Reading data into ndarrays of type: [ Double ]
> Read in  4  elements.
>
> pdl> p $x
> [1 2 3 4]
> pdl> $x *= 100
>
> pdl> p $x
> [100 200 300 400]
> pdl> p median($x)
> 0
> pdl> p $x
> [100 200 300 400]
>
>
> It seems the median function sees the values BEFORE the inplace 
> multiplacation, whereas print does not. This is very bad. min() and max() are 
> similar. No idea what is going on here! The behaviour or absent from v2.025
>
> Notes
> - making a $x->copy() removes the effect
> - creating $x using sequence also removes, so it is something to do with 
> rcols() and not inplace in general?
>
> I’d be interested to know if others can reproduce this. It definitely needs a 
> fix
>
> best
>
> Karl
>
>
>


> ___
> pdl-general mailing list
> pdl-general@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/pdl-general


-- 

  o
W. Luis Mochán,  | tel:(52)(777)329-1734 /<(*)
Instituto de Ciencias Físicas, UNAM  | fax:(52)(777)317-5388 `>/   /\
Av. Universidad s/n CP 62210 |   (*)/\/  \
Cuernavaca, Morelos, México  | moc...@fis.unam.mx   /\_/\__/
GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16  C2DF 5F0A C52B 791E B9EB


___
pdl-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

Re: [Pdl-general] Changes I noted PDL2.025 -> PDL2.084 - rcols issue

[Luis Mochan]

I noticed that medover and maxover do work as expected in this case.


On Sun, Jan 07, 2024 at 11:26:56AM +1100, Karl Glazebrook via pdl-general wrote:
> Hi all,
>
> This dinosaur just upgraded from PDL v2.025 to v.2.084 (yes, I know that is 
> lame)
>
> I noticed a few things when running one of my complicated codes, I will start 
> seperate email threads
>
> First there seems to be a serious rcols bug:
>
>
> e.g. create a file
>
> # tmp.dat
> 1
> 2
> 3
> 4
>
>
> Loaded PDL v2.084 (supports bad values)
> pdl> $x = rcols 'tmp.dat'
> Reading data into ndarrays of type: [ Double ]
> Read in  4  elements.
>
> pdl> p $x
> [1 2 3 4]
> pdl> $x *= 100
>
> pdl> p $x
> [100 200 300 400]
> pdl> p median($x)
> 0
> pdl> p $x
> [100 200 300 400]
>
>
> It seems the median function sees the values BEFORE the inplace 
> multiplacation, whereas print does not. This is very bad. min() and max() are 
> similar. No idea what is going on here! The behaviour or absent from v2.025
>
> Notes
> - making a $x->copy() removes the effect
> - creating $x using sequence also removes, so it is something to do with 
> rcols() and not inplace in general?
>
> I’d be interested to know if others can reproduce this. It definitely needs a 
> fix
>
> best
>
> Karl
>
>
>


> ___
> pdl-general mailing list
> pdl-general@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/pdl-general


-- 

  o
W. Luis Mochán,  | tel:(52)(777)329-1734 /<(*)
Instituto de Ciencias Físicas, UNAM  | fax:(52)(777)317-5388 `>/   /\
Av. Universidad s/n CP 62210 |   (*)/\/  \
Cuernavaca, Morelos, México  | moc...@fis.unam.mx   /\_/\__/
GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16  C2DF 5F0A C52B 791E B9EB


___
pdl-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

Re: [Pdl-general] Changes I noted PDL2.025 -> PDL2.084 - rcols issue

[Karl Glazebrook via pdl-general]

Further to this, I looked through the rcols() diff. I could find no significant 
change in the code that smelled like it could cause this.

Here is a visual diff: https://www.diffchecker.com/w2FX8O61/ 
. (v2.025, v2.084)

I am afraid it must be a subtle bug to do with the internal routines that rcols 
uses (buffering and extending of ndarrays?)  and perhaps the underlying 
dataflow engine. 

Arghh!

Probably worth tracking down as it might be causing other badness….

Karl

> On 7 Jan 2024, at 11:26 am, Karl Glazebrook via pdl-general 
>  wrote:
> 
> Hi all,
> 
> This dinosaur just upgraded from PDL v2.025 to v.2.084 (yes, I know that is 
> lame)
> 
> I noticed a few things when running one of my complicated codes, I will start 
> seperate email threads
> 
> First there seems to be a serious rcols bug:
> 
> 
> e.g. create a file
> 
> # tmp.dat
> 1
> 2
> 3
> 4
> 
> 
> Loaded PDL v2.084 (supports bad values)
> pdl> $x = rcols 'tmp.dat' 
>  
> Reading data into ndarrays of type: [ Double ]
> Read in  4  elements.
> 
> pdl> p $x 
>  
> [1 2 3 4]
> pdl> $x *= 100
>  
> 
> pdl> p $x 
>  
> [100 200 300 400]
> pdl> p median($x) 
>  
> 0
> pdl> p $x 
>  
> [100 200 300 400]
> 
> 
> It seems the median function sees the values BEFORE the inplace 
> multiplacation, whereas print does not. This is very bad. min() and max() are 
> similar. No idea what is going on here! The behaviour or absent from v2.025
> 
> Notes
> - making a $x->copy() removes the effect
> - creating $x using sequence also removes, so it is something to do with 
> rcols() and not inplace in general?
> 
> I’d be interested to know if others can reproduce this. It definitely needs a 
> fix
> 
> best
> 
> Karl
> 
> 
> 
> ___
> pdl-general mailing list
> pdl-general@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/pdl-general

___
pdl-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

Re: [Pdl-general] Changes I noted PDL2.025 -> PDL2.084 - PDL::NiceSlice issue

[Karl Glazebrook via pdl-general]

> On 7 Jan 2024, at 11:55 am, Karl Glazebrook via pdl-general 
>  wrote:
> 
> (The mismatch of line numbers seems to be related to the use of hereto text 
> earlier in the code, the debugger shows different line numbers)
> 


PS just to prove this point given the line numbers issue:




syntax error at /Users/karl/Software/perl/KGB/Redshift.pm line 251, near "$FOO("
Execution of /Users/karl/Software/perl/KGB/Redshift.pm aborted due to 
compilation errors.



You can see FOO triggers a compilation error and BAR does not, use 
PDL::NiceSlice is way at the top of the module

Karl

___
pdl-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

[Pdl-general] Changes I noted PDL2.025 -> PDL2.084 - PDL::NiceSlice issue

[Karl Glazebrook via pdl-general]

Hi all,

This dinosaur just upgraded from PDL v2.025 to v.2.084 (yes, I know that is 
lame)

I noticed a few things when running one of my complicated codes, I will start 
seperate email threads

This last one - I had PDL::NiceSlice failing randomly halfway through a long 
module?

So the module has ‘use PDL::NiceSlice’

then a line line this:

  $FOO($ix) .= 1;

causes a syntax error (i.e. in compilation) if placed at line 247 but not at 
line 249. Here is the surrounding code with line numbersso you can see it was 
innocuous :



syntax error at /Users/karl/Software/perl/KGB/Redshift.pm line 251, near "$FOO("
Execution of /Users/karl/Software/perl/KGB/Redshift.pm aborted due to 
compilation errors.
Compilation failed in require at /Users/karl/Software/bin/pdlredshift line 3.

(The mismatch of line numbers seems to be related to the use of hereto text 
earlier in the code, the debugger shows different line numbers)

(I was just placing those no-op statements in to try and see what was going 
on). As expected using ->slice instead causes the code to compile

I guess we should be cautious of the robustness of NiceSlice?

best

Karl



___
pdl-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

[Pdl-general] Changes I noted PDL2.025 -> PDL2.084 - scalars vs piddles

[Karl Glazebrook via pdl-general]

Hi all,

This dinosaur just upgraded from PDL v2.025 to v.2.084 (yes, I know that is 
lame)

I noticed a few things when running one of my complicated codes, I will start 
seperate email threads

Next I think this one is a design choice change I missed.

- Functions like median() max() etc now return a 0D piddle and no longer a 
scalar. This broke some gnarly code I had.

I expect this change was sensible, I am just curious as the reasons and when it 
happened?


best

Karl





___
pdl-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

[Pdl-general] Changes I noted PDL2.025 -> PDL2.084 - rcols issue

[Karl Glazebrook via pdl-general]

Hi all,

This dinosaur just upgraded from PDL v2.025 to v.2.084 (yes, I know that is 
lame)

I noticed a few things when running one of my complicated codes, I will start 
seperate email threads

First there seems to be a serious rcols bug:


e.g. create a file

# tmp.dat
1
2
3
4


Loaded PDL v2.084 (supports bad values)
pdl> $x = rcols 'tmp.dat'   
   
Reading data into ndarrays of type: [ Double ]
Read in  4  elements.

pdl> p $x   
   
[1 2 3 4]
pdl> $x *= 100  
   

pdl> p $x   
   
[100 200 300 400]
pdl> p median($x)   
   
0
pdl> p $x   
   
[100 200 300 400]


It seems the median function sees the values BEFORE the inplace multiplacation, 
whereas print does not. This is very bad. min() and max() are similar. No idea 
what is going on here! The behaviour or absent from v2.025

Notes
- making a $x->copy() removes the effect
- creating $x using sequence also removes, so it is something to do with 
rcols() and not inplace in general?

I’d be interested to know if others can reproduce this. It definitely needs a 
fix

best

Karl



___
pdl-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general