[seqfan] Re: An idea for a simple mechanical computer to illustrate two OEIS-sequences.

[Fred Lunnon]

Do not send this fellow out to buy groceries!    WFL


On Fri, Aug 27, 2021 at 9:24 AM Antti Karttunen <antti.karttunen at gmail.com>
wrote:

> I went to pick up some berries, but came back with this idea instead
> (well, in any case, involving small round things):
>
> We have a machine, with several glass tubes, that are labeled as
> "2", "3", "5", "7", "11", "13", etc. When machine is in
> operation, each tube contains zero or more steel balls that just
> fit inside them.  The tubes are open from the top, while at the bottom
> of each one there is a mechanical "valve", normally closed, but which
> can be electrically opened just for the time it takes for exactly one
> ball to come out of the tube (or none if the tube is empty, but never
> letting out more than one).  Moreover, at the top of the glass tubes is a
> moving "ball-dispenser" that may automatically drop one or more balls to
> some
> of the glass tubes, by the program's instructions.  (I'm partly
> inspired by this old Lotto-machine https://youtu.be/_5Dn7mm2WkE?t=21
> but of course in our version the tubes must be tall enough to
> accommodate several balls, balls that however, need not be specially
> marked, but can be totally indistinguishable from each other).
>
> Also, under each bottom-valve of each tube is either an optical or
> mechanical sensor that detects a dropped ball, before it is transferred
> back up to the dispenser's reservoir of extra balls by some mechanism
> hidden to us.
>
> The user activates the machine by manually dropping several balls into
> the tubes (>= 0 in each), after which he presses the start button,
> from which onward the machine's mechanical program proceeds as follows: the
> tubes are scanned from the left to the right, starting, from the tube
> labeled "2", with each tube's bottom valve opened in turn to allow a
> single ball to come out of the tube, provided there are any balls in that
> tube.
> The dropped ball then passes the above-mentioned "ball-sensor", which
> activates a hard-coded "dispensing routine" specific for each tube.
>
> For the tube "2" nothing is done, for the tube "3", for any ball that
> comes from the bottom of it, the ball-dispenser drops an extra ball
> into the tube "2" (*), for the tube "5", if a ball comes out, then the
> ball-dispenser drops two balls into the tube "2", for the tube "7",
> for a single ball coming out, the dispenser drops one ball to "2" and one
> ball to "3", for "11" one ball to "2" and one to "5", for "13" two
> extra balls to "2" and one to "3", and so on.  Each ball-sensor,
> when activated by a dropped ball, also rotates an arrow in a clock-like
> display, which keeps the total count how many balls goes through the
> machine.
> Additionally, there is another arrow that is rotated by one step
> whenever all the tubes have been scanned in turn and the process
> returns back to the tube "2". The output of the program are those two
> counts, which are ready when all the tubes are finally empty.
>
> (* Here it might be the same ball, if there were a direct intermediate
> tube or channel
> from the bottom of "3" to the top of "2". For other tubes no such
> shortcut-optimizations
> are possible, and the dispenser needs to be used.)
>
> If we consider the number of balls in the tubes "2", "3", "5", ..., etc,
> as giving the exponents in the prime factorization of n, which two
> sequences a(n) and b(n) the counts given by those two arrows correspond to?
> (Both are in OEIS).
>
> I don't know whether this kind of machine would make any sense in a
> science fair (the mathematics doesn't involve Fibonaccis, but just basic
> number theory, no rocket science), but it might make a nice clanking
> contraption for Bridges kind of Art festival? Or let the bright kid to
> play with it and figure out what's going on? Like e.g., why the machine
> always stops, even though for a moment the number of balls often increases?
>
> Also, I wonder if there there other number theoretical iterations or
> problems that would allow such simple-minded mechanical
> implementations?
>
>
> Best wishes,
>
> Antti Karttunen
>
> --
> Seqfan Mailing list - http://list.seqfan.eu/
>