Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!julius.cs.uiuc.edu!wuarchive!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!comp.vuw.ac.nz!actrix!Bruce.Hoult
From: Bruce.Hoult@bbs.actrix.gen.nz
Newsgroups: comp.theory
Subject: Re: Non recursive "Towers of Hanoi"
Keywords: Towers of Hanoi, Recursivity, Storage
Message-ID: <1990Nov27.125839.27559@actrix.gen.nz>
Date: 27 Nov 90 12:58:39 GMT
References: <1197@disuns2.epfl.ch> <1990Nov27.112713.26729@actrix.gen.nz>
Sender: Bruce.Hoult@actrix.gen.nz (Bruce Hoult)
Organization: Actrix Information Exchange, Wellington, New Zealand
Lines: 15
Comment-To: Bruce.Hoult@bbs.actrix.gen.nz

In article <1990Nov27.112713.26729@actrix.gen.nz> I wrote:
> It satisfies all your constraints -- in particular note that it calculates
> the number of moves left as a natural part of looking for the next move.

Whoops!

The calculation for the number of moves left sometimes gives an overestimate
if the desired final configuration is not the standard one of all disks on
the same pile.

It isn't immediately obvious to me how to correct this, although I think one
way would be to remove the multiply-by-2 part of the calculation, and add an
extra loop that calculated the number of moves from the desired final position
to the position with "diskToMove" having been moved and all smaller disks on
"pileSpare" (this is symmetrical to what will actually be done).