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
