[seqfan] Re: Sequence from buggy polyomino counter

[Alex Meiburg]

I initially wanted to guess that this was just double-counting based on the
*order* pieces were placed after the origin. The 1 and 4 terms agree either
way; when you get to 18, the two tiles are L (4 centered, 8 off) and I (2
centered, 4 off). The most likely explanation is that you'd treat the
polyomino (0,0) (1,0) (0,1) differently from (0,0) (1,0) (0,1) because of
the ordering. If your algorithm was successively laying down pieces to an
earlier stage, but not checking for multiple routes that might produce the
same shape, this would give 24.

I checked with the next element though, and I found that this particular
mistake would give 176 for n=4. I ran this through the OEIS and this turns
out to be http://oeis.org/A007846 .

I tried to reverse engineer your next term, then, the 192. This has an
additional excess of 16. Of the tetrominoes "with ordering" in the sense of
A007846, there are 16 I pieces, 64 L, 48 T, 32 S, and 16 O. If there was
one piece I would be suspicious of it would be O, given its unusual
topology. So maybe you're somehow counting O's double with the two ways you
can go "around" the O?

Anyway, I hope the idea that you might be counting (0,0) (1,0) (0,1) and
(0,0) (1,0) (0,1) separately would be enough to find a mistake in your
program.

In any case, trying to find out what your code is actually counting would
be a lot of fun -- and I'd bet good odds that it's counting *something*!
Maybe post your code? :)

-- Alexander Meiburg


On Fri, Dec 21, 2018 at 3:39 AM Hugo Pfoertner <yae9911 at gmail.com> wrote:

> Not very serious: My guess: 8*A279651 <http://oeis.org/A279651>(5) =
> 8*2232
> = 17856
>
> Hugo
>
> On Fri, Dec 21, 2018 at 5:20 AM Allan Wechsler <acwacw at gmail.com> wrote:
>
> > I was trying to sharpen my Haskell skills by writing a program to compute
> > A048664, the number of different polyominos including the origin cell,
> > where rotations, translations, and reflections are considered distinct.
> >
> > I wrote the code, compiled it a couple of times to get the syntax errors
> > out, and then tried it out. It has a bug. Instead of 1, 4, 18, 76, 315,
> it
> > produces 1, 4, 24, 192, 1856.
> >
> > My first impulse was: fix the darned bug! But then I thought: wait a
> > second, maybe OEIS can help me find the bug. So I searched for the
> programs
> > buggy output sequence.
> >
> > It's not in OEIS. Question: how much effort should I put into analyzing
> the
> > program's actual behavior? It might be doing something interesting that
> is
> > worth including. If anybody wants to try guessing, what's the next
> element?
> >
> > --
> > Seqfan Mailing list - http://list.seqfan.eu/
> >
>
> --
> Seqfan Mailing list - http://list.seqfan.eu/
>