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