Skip Menu |
Report information
Id: 131686
Status: open
Priority: 0/
Queue: perl6

Owner: Nobody
Requestors: perl6 [at] mscha.org
Cc:
AdminCc:

Severity: (no value)
Tag: Bug
Platform: (no value)
Patch Status: (no value)
VM: (no value)



To: rakudobug [...] perl.org
Subject: [BUG] [X] @list-of-lists misbehaves with list of one list
From: Michael Schaap <perl6 [...] mscha.org>
Date: Sat, 1 Jul 2017 21:25:30 +0200
Download (untitled) / with headers
text/plain 470b
This is OK: Show quoted text
> say [X] ((1,2,3), (4,5,6));
((1 4) (1 5) (1 6) (2 4) (2 5) (2 6) (3 4) (3 5) (3 6)) Show quoted text
> say [X*] ((1,2,3), (4,5,6));
(4 5 6 8 10 12 12 15 18) ... but this is incorrect: Show quoted text
> say [X] ((1,2,3),);
((1 2 3)) Show quoted text
> say [X*] ((1,2,3),);
(6) Expected output is: ((1) (2) (3)) and ((1) (2) (3)) Note that [*] behaves as expected: Show quoted text
> say [*] ((1,2,3),(4,5,6));
9 Show quoted text
> say [*] ((1,2,3),);
3 ... since this is equivalent to: Show quoted text
> say [*] (3, 3);
9 Show quoted text
> say [*] (3,);
3
I think this is related: https://github.com/perl6/doc/issues/1400

On 2017-07-01 12:25:39, perl6@mscha.org wrote:
Show quoted text
> This is OK:
>
> > say [X] ((1,2,3), (4,5,6));
> ((1 4) (1 5) (1 6) (2 4) (2 5) (2 6) (3 4) (3 5) (3 6))
> > say [X*] ((1,2,3), (4,5,6));
> (4 5 6 8 10 12 12 15 18)
>
> ... but this is incorrect:
>
> > say [X] ((1,2,3),);
> ((1 2 3))
> > say [X*] ((1,2,3),);
> (6)
>
> Expected output is:
> ((1) (2) (3))
> and
> ((1) (2) (3))
>
>
> Note that [*] behaves as expected:
>
> > say [*] ((1,2,3),(4,5,6));
> 9
> > say [*] ((1,2,3),);
> 3
>
> ... since this is equivalent to:
>
> > say [*] (3, 3);
> 9
> > say [*] (3,);
> 3


Subject: Re: [perl #131686] [BUG] [X] @list-of-lists misbehaves with list of one list
To: perl6-bugs-followup [...] perl.org
From: Michael Schaap <perl6 [...] mscha.org>
Date: Sat, 1 Jul 2017 22:17:20 +0200
Download (untitled) / with headers
text/plain 691b
That may indeed explain why it works the way it does, but that doesn't mean it isn't a bug. IMO it certainly is; [X] and [X*] don't work as advertised. Let me explain how I found this bug. I'm generating a list of divisors for a number. I already have the prime factorization of that number, and a list of all the "prime powers". Examples: 24 = 2³×3¹: ((1, 2, 4, 8), (1, 3)) 42 = 2¹×3¹×7: ((1, 2), (1, 3), (1, 7)) 64 = 2⁶: ((1, 2, 4, 8, 16, 32, 64),) Now it's easy to generate the divisors: Show quoted text
> say [X*] ((1, 2, 4, 8), (1, 3));
(1 3 2 6 4 12 8 24) Show quoted text
> say [X*] ((1, 2), (1, 3), (1, 7));
(1 7 3 21 2 14 6 42) Show quoted text
> say [X*] ((1, 2, 4, 8, 16, 32, 64),)
(2097152) Oops...
I'd agree that it is a bug, yes. Well, the reason why it happens might be justified, but this is probably one of the fattest traps I've seen so far. I really think we should come up with a way to eliminate this trap somehow. Not sure how, but there must be a way and I really recommend anybody reading this to think in this direction (instead of writing a lot of text to come up with excuses to reject this ticket). Maybe it's something we can fix in v6.d, or maybe we can add some kind of warning right now. I don't know, but I truly hope that there is a solution.

On 2017-07-01 13:17:58, perl6@mscha.org wrote:
Show quoted text
> That may indeed explain why it works the way it does, but that doesn't
> mean it isn't a bug. IMO it certainly is; [X] and [X*] don't work as
> advertised.
>
> Let me explain how I found this bug.
> I'm generating a list of divisors for a number. I already have the
> prime factorization of that number, and a list of all the "prime powers".
> Examples:
> 24 = 2³×3¹: ((1, 2, 4, 8), (1, 3))
> 42 = 2¹×3¹×7: ((1, 2), (1, 3), (1, 7))
> 64 = 2⁶: ((1, 2, 4, 8, 16, 32, 64),)
> Now it's easy to generate the divisors:
>
> > say [X*] ((1, 2, 4, 8), (1, 3));
> (1 3 2 6 4 12 8 24)
>
> > say [X*] ((1, 2), (1, 3), (1, 7));
> (1 7 3 21 2 14 6 42)
>
> > say [X*] ((1, 2, 4, 8, 16, 32, 64),)
> (2097152)
> Oops...


Download (untitled) / with headers
text/plain 2.4k
I agree that things like my @divisors = [X] @prime-factor-powers; my @transpose = [Z] @matrix; look perfectly reasonable and elegant, and the fact that the single-sub-list edge-case ruins them is regrettable. Nor can I image any scenario where the current behavior of that edge-case is useful. I assumed that because it was the natural result of a core Perl 6 design decision which is surely not under discussion anymore (the "single-argument rule" for list-munging routines like `zip` and `cross`), we would have to live with it. But Aleks-Daniel is right, it really would be great to find some way to "fix" this edge-case. Here's a first idea: --- Maybe `reduce` could simply introspect the operator and if sees that the signature starts with a "single-argument slurpy" parameter (`+foo` / `+@foo`), adapt the calls to it accordingly? At first glance that seems LTA (special cases are icky), but consider that: 1) `reduce` *already* introspects its operator and adapts its operation accordingly, in order to provide maximum DWIM regarding associativity, unity, etc. 2) The "single-argument rule" can be seen as just another calling convention. When we write `zip @foo`, the the parser may think a function is being called with one argument... but *we* know that we're sending all the sub-lists of @foo to be zipped, and that if we had wanted to send the single list @foo we would have had to write `zip (@foo,)` or `zip $@foo`. `reduce` also knows that it wants to apply the operator to a single item in the edge-case in question, and it could adapts its call to make that happen for whatever calling convention the operator uses. Point (2) raises the question if other built-ins like `map` and `grep` would have to learn about different calling conventions as well, for consistency. But I don't think that's necessarily the case. Things like `map` are very generic in the sense that they don't understand anything about what is being piped through them... the user is fully in charge of controlling the inputs and outputs of the callback. (Also, the current behavior is actually useful there.) `reduce` is more high-level, in the sense that it knows it's dealing with an operator and a list of elements to fold, and wants to call the operator with either zero, one or two of those elements at a time. This shouldn't be interpreted as an RFC yet, just some thoughts. Someone would have to thoroughly think through the implications, and test the spectest/ecosystem fallout.
Download (untitled) / with headers
text/plain 767b
Show quoted text
> ... it really would be great to find some way to "fix" this edge-case.
I don't think anything needs to be fixed. This is along the same vein as the misguided thinking that `[Z] (3,2)` should yield `(2,3)`. I also think the comparison to [*] is invalid since it operates on number-y things, and [X] explicitly operates on 2 or more lists or iterables. My thinking is that doing `[X] ((3,2),)` is kinda like doing `[X] ((3,2),Empty)`... Not exactly equivalent, but almost. The Cartesian product of singleton sets is again a singleton set (ie. product [[1]; [2]; [3]] is [1; 2; 3] My feeling is that current behavior is fine. At most, perhaps a warning in a similar vein to `sink context` warnings, eg. 'Useless use of meta-reduce [X] on single list' or something
Download (untitled) / with headers
text/plain 1.2k
On Tue, 18 Jul 2017 07:45:16 -0700, joshuamy@gmail.com wrote: Show quoted text
> My thinking is that doing `[X] ((3,2),)` is kinda like doing `[X] ((3,2),Empty)`...
Assuming I understand your analogy correctly, that's exactly what's *not* happening, and is why this RT exists. See: dd [X] 3, 2; # ((3, 2),).Seq dd [X] (3, 2); # ((3, 2),).Seq dd [X] ((3, 2),); # ((3, 2),).Seq The first two are unsurprising, but note how the third one is *also* being treated as the Cartesian product between the two sets `3` and `2`, rather than the single set `(3, 2)`. Also, scenarios where the argument list to `[X]` or `[Z]` is fixed-sized (like in these examples), isn't what is tripping people up (because there's no reason to write that in the single-sublist case anyway). The problem is with crossing or zipping a variable-sized list of lists, like in `my @transpose = [Z] @matrix;`, which works fine for most inputs but breaks down for the "@matrix has exactly one row" edge-case. I've explained why this is happening and why it ruins people's day in this docs ticket: [1], and this StackOverflow answer: [2]. --- [1] https://github.com/perl6/doc/issues/1400 [2] https://stackoverflow.com/questions/44821983/recursive-generator-manual-zip-vs-operator/44831926#44831926
Subject: Re: [perl #131686] [BUG] [X] @list-of-lists misbehaves with list of one list
To: perl6-bugs-followup [...] perl.org
Date: Wed, 19 Jul 2017 00:59:52 +0200
From: Michael Schaap <perl6 [...] mscha.org>
Download (untitled) / with headers
text/plain 969b
In my opinion, to decide whether it's a bug, you shouldn't look at the implementation of [X] and [X*], but rather at its practical use. In what cases would you use it, and what do you expect it to return when your list of lists happens to be one list? That's what I was trying to do with my example to determine the divisors of a number, given the prime factorization. (That was a simplified version of my actual code where I encountered the bug, and lost about half an hour figuring out what was happening.) If someone states the current behaviour is correct, I'd like them to come up with a practical example where [X] or [X*] currently does the right thing. But perhaps an even easier way to look at it is: [X] (@a, @b, @c) is equivalent to @a X @b X @c [X] (@a, @b) is equivalent to @a X @b so [X] (@a,) is equivalent to @a and [X*] (@a, @b, @c) is equivalent to @a X* @b X* @c [X*] (@a, @b) is equivalent to @a X* @b so [X*] (@a,) is equivalent to @a


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org