Enumerating all 3-tuples

Ben Bacarisse ben.usenet at bsb.me.uk
Sat Mar 10 16:53:25 EST 2018


bartc <bc at freeuk.com> writes:

> On 10/03/2018 20:06, Ben Bacarisse wrote:
>>> On 10/03/2018 14:23, Ben Bacarisse wrote:
<snip>
>>>> Off topic: I knocked up this Haskell version as a proof-of-concept:
>>>>
>>>>     import Data.List
>>>>
>>>>     pn n l = pn' n (map (:[]) l)
>>>>              where pn' n lists | n == 1 = lists
>>>>                                | otherwise = diag (pn' (n-1) lists) lists
>>>>                    diag l1 l2 = zipWith (++) (concat (inits l1))
>>>>                                              (concat (map reverse (inits l2)))
>>>>
<snip>
>> but, as I've said, the order of the results is not the usual one (except
>> for pairs).

> OK. I ran it like this:
>
>  main = print (take 20 (pn 3 [1..]))
>
> But I'm trying to understand the patterns in the sequence. If I use:
>
>  main = print (take 50 (pn 2 [1..]))
>
> then group the results into sets of 1, 2, 3, etc pairs, showing each
> group on a new line, then this gives sequences which are equivalent to
> the diagonals of the OP's 2D grid. (Except they don't alternate in
> direction; is that what you mean?)

Yes, the pattern for pairs (pn 2 [1..]) is the normal one (one of them
anyway).  In the 2D grid the diagonals are lines of equal sum (for a
numeric grid, of course) and all the pairs that sum to x appear before
those that sum to x+1:

*Main> take 28 $ map sum $ pn 2 [1..]
[2,3,3,4,4,4,5,5,5,5,6,6,6,6,6,7,7,7,7,7,7,8,8,8,8,8,8,8]

The recursive step breaks this rule.  I'm sure there's a better rule,
but it's getting more and more off-topic...

-- 
Ben.



More information about the Python-list mailing list