Hmmm. This needs some careful thought. There are two quasi-standard zero-element cases: if I recall right, Null PDLs have one dimension of length zero, and Empty PDLs have size (1,0). There were some earlier anomalies surrounding how these were handled, and I made an attempt to regularize them sometime last summer. I'll have a look at this over the next day or two.
On Dec 27, 2011, at 1:29 PM, Bryan Jurish wrote: > morning all, > > I've had some problems with the 2.4.10 RC handling of null-dimensioned > piddles, i.e. piddles with at least one dimension of size=0 (relevant > portions of previous discussion attached). As things stand, I sometimes > need 2d piddles of size (N,0) such as might be returned by > whichND(zeroes(1..$N)), and might later be passed to indexND(), > assumedly to return a flat 0-element vector. > > It seems that the PDL core's internal handling of such cases has changed > for the upcoming 2.4.10 release in such a way that my previous code no > longer works as expected. I freely admit that dimensions of size 0 are > weird, wacky, strange, bizarre, pathological, and often Just Plain > Wrong, but I still think there are some good reasons to keep them around > -- even to the point of allowing constructions such as zeroes(0,1) or > sequence(42,0). > > My use case is the PDL::CCS module, which defines a PDL-like perl class > for sparse N-dimensional matrices represented (basically) as a pair > ($which,$vals), where $which is an integer pdl(N,Nnz) such as returned > by whichND() on the corresponding raw PDL, and $vals is a pdl(Nnz+1) > containing the respective non-"missing" values and one additional > element representing the "missing" value (usually $missing==0, hence Nnz > ~ "number of non-zeroes"). If all values are missing (e.g. if trying to > sparse-encode the output of zeroes(1..$N) with $missing==0), then > $Nnz==0 and dims($which)==($N,0). > > So far, I've had to catch a lot of these cases by hand and explictly > construct such empty $which pdls using a dice_axis hack (e.g. > $which=zeroes($N,1)->dice_axis(1,null)), which successfully returns the > desired ($N,0) piddle. Problematically, when passed to indexND() (as > happens e.g. when decoding a sparse PDL::CCS::Nd object into a dense > pdl), the new PDL core code returns not a flat zero-element vector as > expected, but rather another ($N,0) piddle. This causes the new PDL > release to barf() with a "dimension mismatch" when indexND() with an > empty $which PDL is used as the left-hand side of an assignment with .= > (see sourceforge bug report link below). > > From a more principled (as opposed to purely pragmatic) standpoint, I > think there are good reasons to allow size-0 dimensions across the > board, even in constructors like zeroes(), ones(), sequence(), xvals(), > etc. The main reason for this is to provide identity elements for > glue(). In my day job, I deal pretty much exclusively with > concatenative monoids (string languages), and these are pretty > uninteresting (not to mention intractable) without the empty string. > Putting it differently, I think glue() should be a (family of) > concatenative monoid(s) rather than just a boring old semigroup ;-) > > Thoughts, objections, comments, corrections, and further discussion welcome! > > marmosets, > Bryan > > On 2011-12-20 14:37:08, chm <[email protected]> appears to have > written: >> On 12/20/2011 6:25 AM, Bryan Jurish wrote: >>> On 2011-12-18 22:56, chm wrote: >>>> Fails tests: >>>>> MOOCOW/PDL-CCS-1.14.tar.gz (requires PDL::VectorValued) >>> >>> Should be fixed (band-aided) in newest PDL::CCS on CPAN >>> (MOOCOW/PDL-CCS-1.15.tar.gz). The culprit seems to have been a change >>> in the PDL core's handling of Nx0 piddles somewhere between 2.4.9 and >>> 2.4.9_015. Report filed as sourceforge bug #3462924 >>> > (https://sourceforge.net/tracker/?func=detail&aid=3462924&group_id=612&atid=100612). >>> >>> This is a degenerate case, but it can easily happen in PDL::CCS (sparse >>> piddles) as a result of run-of-the-mill internal index-piddle twiddling. >> >> Hi Bryan- >> >> I'm not sure I comprehend what a [2,0] shaped >> piddle means. My first thought is that it >> should not be returned by dice_axis at all. >> >> There have been some changes to PDL since 2.4.9 >> in *exactly* those edge cases. But the previous >> handling caused segfaults in perl. I would like >> for some feedback from the range-master based >> on further discussion. >> >> Maybe you could post separately to the mailing >> list with some examples showing where non-trivial >> 0 length dimensions were supported, how they >> arise in practice... In particular, is there >> different code approaches that could work? > > -- > Bryan Jurish "There is *always* one more bug." > [email protected] -Lubarsky's Law of Cybernetic Entomology > > _______________________________________________ > 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
