[seqfan] Re: Sequence from buggy polyomino counter
Andras
andras at yahoo.com
Fri Dec 21 18:16:40 CET 2018
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/
More information about the SeqFan
mailing list