What happens if you my $pdl = pdl($ref)->setnantobad->sever
since inplace only helps if you need to save memory but the initial perl array is going to be _much_ larger than the resultant piddle? --Chris On Fri, Dec 21, 2012 at 12:32 AM, Chris Marshall <[email protected]> wrote: > Well, I see some other answers have > already been posted. Sorry about the dups. > What version of PDL are you using, what > is your os/hardware platform, output from > perldl -V? > > Do you have an example test case that > illustrates the problem? > > Thanks, > Chris > > On Fri, Dec 21, 2012 at 12:28 AM, Chris Marshall <[email protected]> > wrote: >> Hi Erich and welcome to PDL- >> >> Take a look at the docs for the pdl >> constructor... specifically the use of >> $PDL::undefval. (e.g., pdldoc pdl >> or 'help pdl' in the pdl2 or perldl shell, >> perldoc PDL::Core also gets you >> there but you'll have to read through >> to get to the pdl routine. >> >> --Chris >> >> On Thu, Dec 20, 2012 at 7:31 PM, Erich Greene <[email protected]> wrote: >>> Hi, >>> >>> I'm fairly new to PDL and this seems like an obvious thing to ask about, but >>> I haven't found it addressed in any docs or FAQs or in this list's archives. >>> >>> I'm trying to create piddles from arrays that might include undefined values >>> and treat those values as bad in further processing. But when pdl() >>> encounters an input value of undef, it puts a 0 into the piddle. Setting 0 >>> as the bad value later doesn't work for me because 0 is also a legitimate >>> data value, and once the piddle is made, there's no distinguishing an undef >>> treated as 0 from a real 0. (In fact, any float could be legitimate -- >>> that's why I've been using undef for missing data -- so experimenting with >>> badvalue was also a dead end.) >>> >>> Eventually, I came up with this: >>> >>> use 5.014; >>> use warnings; >>> use PDL::LiteF; >>> >>> # make a piddle where undef becomes BAD >>> sub pdlify { >>> my @in = map {ref eq 'ARRAY' ? @$_ : $_} @_; >>> my @out = map {defined($_) ? pdl($_) : pdl(0)->setbadat(0)} @in; >>> return cat(@out); >>> } >>> >>> This works fine in small-scale tests (my $x = pdlify(1..5,undef,7..10); say >>> $x; spits out [1 2 3 4 5 BAD 7 8 9 10] as it should), but in production, one >>> of two things eventually happens: >>> >>> 1) segfault >>> >>> 2) cat: unknown error from the internals: >>> PDL: Problem with assignment: PDL:Internal Error: data structure recursion >>> limit exceeded (max 1000 levels) >>> This could mean that you have found an infinite-recursion error in >>> PDL, or >>> that you are building data structures with very long dataflow >>> dependency >>> chains. You may want to try using sever() to break the dependency. >>> >>> Each call to pdlify is acting on a fresh list of scalars (all numbers or >>> undef), so there shouldn't be any dependencies to speak of at this point. >>> >>> Bottom line, is there an idiom or package already out there that will take a >>> list and create a piddle where undefined input values are represented as BAD >>> rather than 0, or is there at least some way to do it that doesn't go down >>> some mysterious recursive rabbit hole? >>> >>> Thanks. >>> >>> -- Erich >>> >>> _______________________________________________ >>> Perldl mailing list >>> [email protected] >>> http://mailman.jach.hawaii.edu/mailman/listinfo/perldl _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
