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...
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...
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
