[seqfan] Re: Sequence from buggy polyomino counter

Frank Adams-watters franktaw at netscape.net
Fri Dec 21 19:37:10 CET 2018


There are only two ways a buggy program can *fail* to produce a "valid" 
sequence. The first is if it fails for some inputs, whether getting an error, 
returning a result of the wrong type, or failing the halting problem.

The second is if it has portability problem - the only way I know of for the 
mathematical programing tools in use here to have such a problem is to 
convert a floating point number  to an integer. For example, if one 
implemented A000196 as "floor(sqrt(n))", you might sometimes get 
a(n^2) = n-1. This would vary depending on the tool, the selected 
precision, and in some cases the specific computer.

Otherwise, you will get a valid sequence.Whether that sequence is worthy of 
inclusion in the OEIS is another question. You need to determine what it 
actually is doing so that that can be assessed.

Franklin T. Adams-Watters


-----Original Message-----
From: P. Michael Hutchins <pmh232 at gmail.com>
To: Sequence Fanatics Discussion list <seqfan at list.seqfan.eu>
Sent: Fri, Dec 21, 2018 9:50 am
Subject: [seqfan] Re: Sequence from buggy polyomino counter


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