Ah, maybe I got it wrong. I thought he wanted to change the value of BAD
to something else instead of replacing it with a genuine number. I read
setbadval (which is actually badvalue) instead of setbadtoval.
Ingo
On 12.06.19 18:34, Ed . wrote:
Doesn't that render setbadtoval entirely pointless?
Or is the problem actually that Stephan didn't do
$x->inplace->setbadtoval(23);
so what he wanted would be:
use 5.010;
use PDL;
my $x = indx(1,2,3)->setbadat(1);
say $x; # [1 BAD 3]
my $y = $x->setbadtoval(100);
say $x; # still [1 BAD 3]
say $y; # [1 100 3]
Best regards,
Ed
-----Original Message-----
From: Ingo Schmid
Sent: Wednesday, June 12, 2019 5:25 PM
To: [email protected]
Subject: Re: [Pdl-general] Several problems with PDL
Hi,
let me comment the easy one, this is a feature, I think. Once an element
is flagged bad, bad sticks. Bad value should be a value that is normally
never present in your data. In particular for the smaller integer types
this can be a problem, of course.
At least that was my take on bad values. They indicate missing/corrupt data.
Best wishes
Ingo
On 12.06.19 17:53, Stephan Loyd wrote:
4. setbadtoval() does not work well with some PDL types. For example,
use 5.010;
use PDL;
my $x = indx(1,2,3)->setbadat(1);
say $x; # [1 BAD 3]
$x->setbadtoval(100);
say $x; # still [1 BAD 3]
Is this a bug or a feature?
_______________________________________________
pdl-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/pdl-general
_______________________________________________
pdl-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/pdl-general
