On 1/2/2012 4:06 AM, Bryan Jurish wrote:
On 2011-12-30 13:53, chm wrote:
On 12/27/2011 3:29 PM, Bryan Jurish wrote:

 From a more principled (as opposed to purely pragmatic) standpoint, I
think there are good reasons to allow size-0 dimensions across the
board
...
to provide identity elements for glue().

The identity element argument seems like a plausible
justification/motivation for the existence and meaning of
such piddle shapes with 0-length dimensions.

... just a note after the fact: it seems that the return value of
whichND(zeroes(4,3)) has changed in the 2.4.10 release candidate as
well. With $,=' '; I get:

  ##-- v2.4.7_001 (debian squeeze)
  print whichND(  ones(4,3))->dims; ##-- "2 12"
  print whichND(zeroes(4,3))->dims; ##-- "2 0"

  ##-- v2.4.9_015
  print whichND(  ones(4,3))->dims; ##-- "2 12"
  print whichND(zeroes(4,3))->dims; ##-- "0"

Could the same effect be obtained by adding an explicit
dimension shape piddle/list to your CCS objects?  It
seems like the missing piece with the current PDL is
a clever way to carry around the shape info in only
two piddles.

Not sure what you mean here by "the same effect".  I actually do carry
around additional shape information in my CCS objects, in order to allow
for loss-free decoding (in case of "missing" final rows, columns, etc),
dimension shuffling (reorder(), xchg(), etc), and something like dummy
dimensions.  The $which and $vals components are just the guts.  The
full specification uses 2 piddles with shape information (1 for
"physically indexed" dimensions and 1 for "virtual" (read "dummy")
dimensions), the aforementioned $which and $vals piddles, and a perl
scalar for some bitmask flags (for inplace(), etc).  There's also a
dedicated user component for subclasses, and a little-used array for
Harwell-Boeing dimension-specific "pointers" (these should allow
constant-time access to the given dimension, e.g. for dice_axis(); in
practice they're almost never used though).  In hindsight, I should also
have stored the $missing value separately rather than in $vals, but I
didn't...

I meant that the current implementation uses the shape information
implicit in the $which and $vals and the previous handling of Null
and Empty piddles.  It would seem that the same information would
be contained in 2 1-D piddles and an explicit shape piddle.

As it is, I need to be able to match up $which and (nthe on-missing
prefix vector of) $vals on the shared potentially length-0 dimension
(Nnz) in pretty much all of the CCS PDL::PP code; I suppose I could
prevent that alignment by renaming one of the dimensions in the PDL::PP
subroutines; I'm not sure how this would help though...

While the new range/index/which... has fixed the various
crashes, it is possible that the handling of Empty and
Null piddles needs further understanding.  I think
your module definitely stretches those edge cases to
their [poorly documented] limits.  I'm looking forward
to hearing Craig's thoughts on this and, eventually,
explicit documentation on what Null and Empty piddles
are and the rules for handling them (from perl and from
PP code).

Cheers,
Chris

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?





_______________________________________________
Perldl mailing list
[email protected]
http://mailman.jach.hawaii.edu/mailman/listinfo/perldl

Reply via email to