moin Chris,
On 2012-01-02 15:21, chm wrote:
> 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.
[snip]
>>
>>> 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...
[snip]
>
> 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.
Ah, I see. That would be pretty much equivalent to a clump(-1) on the
$which piddle then, which would make it *much* harder to work with as a
list-of-vectors; although I imagine it could be done (PDL itself doing
much the same thing on dense structures)...
>> 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.
Sorry about that ;-) I didn't mean to cause undue headaches.
> 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).
Likewise. I think I may have run up against the crash-scenarios a few
times myself in the past, but apparently managed to work around them by
catching empty piddles on the perl level. Still, I don't understand how
empty (but non-null) piddles managed to segfault perl, but then again,
my understanding of the PDL core is very poor. Can somebody clue me in
on this, e.g. with a pointer to some previous list discussion on the topic?
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
Deutsches Textarchiv
Berlin-Brandenburgische Akademie der Wissenschaften
Jägerstr. 22/23
10117 Berlin
Tel.: +49 (0)30 20370 539
E-Mail: [email protected]
***************************************************
_______________________________________________
Perldl mailing list
[email protected]
http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
