Re: Array Dimensionality (Was: Re: Multi-d array transforms (was Re: Array rotate))
Larry Wall larry-at-wall.org |Perl 6| wrote: Alternately, we leave @@ (or @%) meaning ¢ and instead let some other syntax take over the pay attention to the capture's structure semantics from @@. Maybe it's another use for the zen slice: pay attention to the capture's structure is a can of worms. As things stand now in the Synopses, you get a lot of empty extra wrappers around things. You don't want to keep that exact! When you are not doing full-blown flattening, which levels in the morphology are extra due to passing though functions or grouping parens, and which are intended to be part of the final structure? Since the crazy stuff inside the capture is usually invisible, people will have a hard time using that correctly. (A literal reading of the synopses now gives us the morphology illustrated at http://www.dlugosz.com/Perl6/web/med-loop.html, and I hope to remove _some_ of those extra wrappings through refinement of the rules when I get around to studying that in detail.) My thoughts at this point is that slice context needs to *know* it is being rolled up into a final result that is a 2-dim array. The rules for that will strip out extra wrappers except where it really is significant, designed through use cases of seeing what common constructs actually produce. A shaped array knows what needs to be poured into it, so the RHS can be flattened. The single-dim array is just a special case of that; it generalizes to higher dimensions just fine, as seen in languages like APL. A smart shaped assignment, to handle containers with * in other than the highest position, can be supplied as part of a multi-dim array Module, designed separately along with a coherent set of features such as general vector-driven transposes etc. --John
Re: Array Dimensionality (Was: Re: Multi-d array transforms (was Re: Array rotate))
Daniel Ruoso daniel-at-ruoso.com |Perl 6| wrote: So, how do I deal with a multidim array? Well, TIMTOWTDI... my @a = 1,[2,[3,4]]; say @a[1][1][1]; say @a[1;1;1]; # I'm not sure this is correct I think that it should be. That is, multi-dim subscript is always the same as chained subscripts, regardless of whether the morphology is an array stored as an element, or a multi-dim container, or any mixture of that as you drill through them. I've not written out a full formalism yet, but I've thought about it. The multi-dim subscript would return a sub-array if there were fewer parameters than dimensions, an element if exact match, and recursively apply the remaining subscripts to the element if too many. Or.. (I'm using the proposed capture sigil here, which has '@%a' as its expanded form) my ¢a = 1,(2,(3,4); say ¢a[1][1][1]; say ¢a[1;1;1]; I think that makes the semantics of the API more clear... daniel The plain Array would work too, in the nested morphology: my @a = 1,[2,[3,4]]; @a has 2 elements, the second of which is type Array. say @a[1][1][1]; naturally. say @a[1;1;1]; means the same thing, intentionally. say @a[1][1;1]; say @a[1;1][1]; ditto. --John
Array Dimensionality (Was: Re: Multi-d array transforms (was Re: Array rotate))
Ok, There's one thing that is not clear in the thread, which is when an array is multidimensional or not... For instance: @a = (1, 2, 3; 4, 5, 6; 7, 8, 9); Will produce a flatten array, because list assignment causes flattening, so the dimensionality was lost. It is important to remember that this was a change in the spec that happened some time ago. Before that, @a and @@a did refer to the same variable, but this is no longer the case. Now @a and @@a are different variables (in fact the @@ sigil is probably going to be replaced, since it's not just list slice but it's actually a capture) So, in the @a = (1,(2,(3,4)); example, @a will be a flat list with 4 elements. So, how do I deal with a multidim array? Well, TIMTOWTDI... my @a = 1,[2,[3,4]]; say @a[1][1][1]; say @a[1;1;1]; # I'm not sure this is correct Or.. (I'm using the proposed capture sigil here, which has '@%a' as its expanded form) my ¢a = 1,(2,(3,4); say ¢a[1][1][1]; say ¢a[1;1;1]; I think that makes the semantics of the API more clear... daniel
Re: Array Dimensionality (Was: Re: Multi-d array transforms (was Re: Array rotate))
On Fri, Jun 12, 2009 at 11:51 AM, Daniel Ruosodan...@ruoso.com wrote: Ok, There's one thing that is not clear in the thread, which is when an array is multidimensional or not... For instance: �...@a = (1, 2, 3; 4, 5, 6; 7, 8, 9); Will produce a flatten array, because list assignment causes flattening, so the dimensionality was lost. Right. I should have said: @@a = (1, 2, 3; 4, 5, 6; 7, 8, 9); -- Jonathan Dataweaver Lang
Re: Array Dimensionality (Was: Re: Multi-d array transforms (was Re: Array rotate))
Em Sex, 2009-06-12 às 11:52 -0700, Jon Lang escreveu: On Fri, Jun 12, 2009 at 11:51 AM, Daniel Ruosodan...@ruoso.com wrote: Ok, There's one thing that is not clear in the thread, which is when an array is multidimensional or not... For instance: @a = (1, 2, 3; 4, 5, 6; 7, 8, 9); Will produce a flatten array, because list assignment causes flattening, so the dimensionality was lost. Right. I should have said: @@a = (1, 2, 3; 4, 5, 6; 7, 8, 9); The important point here is that it means we're dealing with a different type, so it can actually behave differently, so @@a.rotate would rotate the first dimension only.. maybe @@a.rotate(1;1) would mean to rotate by 1 in the first dimension and by 1 in the second, producing (5, 6, 4; 8, 9, 7; 2, 3, 1) daniel
Re: Array Dimensionality (Was: Re: Multi-d array transforms (was Re: Array rotate))
On Fri, Jun 12, 2009 at 04:00:10PM -0300, Daniel Ruoso wrote: : Em Sex, 2009-06-12 às 11:52 -0700, Jon Lang escreveu: : On Fri, Jun 12, 2009 at 11:51 AM, Daniel Ruosodan...@ruoso.com wrote: : Ok, There's one thing that is not clear in the thread, which is when an : array is multidimensional or not... : For instance: :@a = (1, 2, 3; 4, 5, 6; 7, 8, 9); : Will produce a flatten array, because list assignment causes flattening, : so the dimensionality was lost. : Right. I should have said: : @@a = (1, 2, 3; 4, 5, 6; 7, 8, 9); : : The important point here is that it means we're dealing with a different : type, so it can actually behave differently, so @@a.rotate would : rotate the first dimension only.. : : maybe @@a.rotate(1;1) would mean to rotate by 1 in the first dimension : and by 1 in the second, producing : : (5, 6, 4; 8, 9, 7; 2, 3, 1) I think captures are a bit of a red herring here. Arrays can be shaped without the @@ sigil, and that is part of its type, so assignment to @a and @.rotate can also do the right thing. The @@ context was originally just a way of declaring a context that turns nested captures into a multidimensional array at binding or coercion time. So @a := @@(1,2,3; 4,5,6; 7,8,9); used to be defined as the same as @a := [[1,2,3], [4,5,6], [7,8,9]]; Treating @@ as a capture sigil would make @@ coercion a no-op. So perhaps @@ isn't the Texas form of a capture sigil after all. Alternately, we leave @@ (or @%) meaning ¢ and instead let some other syntax take over the pay attention to the capture's structure semantics from @@. Maybe it's another use for the zen slice: @a = (1,2,3; 4,5,6; 7,8,9); # 1..9 @a[] = (1,2,3; 4,5,6; 7,8,9); # [1,2,3], [4,5,6], [7,8,9] Interestingly, that would mean that @a = 1,2,3; # 1,2,3 3 elems @a[] = 1,2,3; # [1,2,3] 1 elem! much like subscripts assume .[1,2,3] is a 1-dim slice of three elements, not a 3-dim vector pointing to a single element. There's something slightly pleasing about the equivalence @a = [1,2,3]; @a[] = 1,2,3; Larry
