[seqfan] Re: Sequence from buggy polyomino counter

[Neil Sloane]

> Can a buggy program produce a valid sequence?

If I recall correctly, that is how roast pork was discovered  (according to
Charles Lamb).




On Fri, Dec 21, 2018 at 1:15 PM Andras via SeqFan <seqfan at list.seqfan.eu>
wrote:

>  For what it is worth, messing around with a broken program is exactly
> how A285192 came to be.    On Saturday, December 22, 2018, 12:50:09 AM
> GMT+9, P. Michael Hutchins <pmh232 at gmail.com> wrote:
>
>  Can a buggy program produce a valid sequence?
>
> Note that finding a different program to produce the same sequence would be
> hard to come by.
>
> On Fri, Dec 21, 2018 at 7:21 AM Alex Meiburg <timeroot.alex at gmail.com>
> wrote:
>
> > 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/
> > >
> >
> > --
> > Seqfan Mailing list - http://list.seqfan.eu/
> >
>
> --
> Seqfan Mailing list - http://list.seqfan.eu/
>
>
> --
> Seqfan Mailing list - http://list.seqfan.eu/
>