-=> On 10 Jun 98  10:11:02 you wrote to me <=-

Hi Bill,

BB>         Nice to hear from you again. :-)

You too. :)

MS> Darn!  I never saw it.  :( You should probably repost it if it's
MS> not too large, since you guys in the UK just got cut off from
MS> the rest of us for a week or two.  Again.

BB>     I did.  In ANSI C form, but the thing's either jerky, slow
BB> or frenetic.  Haven't solved that one yet.

I got it in the repost.  BTW, did you originally write this code?
FWIW, I've simplified some of the output statements, especially the
ones that output the Escape character.

The program works fine on the Amiga, but I dropped the wait() stuff
since it runs slow enough on my 25MHz 68030.  :)

It's not easy to do smooth timing in ANSI C.  Apart from the lack of
a multitasking-friendly wait() function, CLOCKS_PER_SECOND can be
anything, and you really need better than 1 second resolution for
smooth graphics.

Fortunately for graphics programmers, most modern environments
provide decent timing functions. :)  However, even with low
resolution timing functions it's possible to get reasonably smooth
behaviour. I have used something like this:

/* PD pseudo-code */

    long per;   /* Desired loop period */
    long del;   /* time to delay */
    long t, t1;

    /* Initialize per */

/*  Initialize del to an approximately correct value.
 *  You could do this as shown below, although this may produce
 *  undesirable effects in some programs.
 */
    if (del<0)
    {
        /*  Initialize del */

        t = get_time();
        do_stuff();
        del = per - (get_time() - t);

        if (del<0)
            del = 0;
    }

    /* M A I N   L O O P */
    t = get_time();
    while(1)
    {
        do_stuff();
        do_wait(del);
        t1 = get_time();

        /* subtract excess from delay */
        del -= (t1 - t) - per;
        if (del<0)
            del = 0;    /* Can't delay for negative time! */
        t = t1;
    }

BB> It's a nuisance that the rest of the world periodically drops
BB> off the end of the echo.  :-)

Fido is a strange beastie, especially these days.  I'm in Sydney & I
frequently get cut off from Adelaide, since the Fido connection
between Sydney and Adelaide goes via the USA!

MS> I have encountered some beautiful symmetries buried in the Tower
MS> of Hanoi, however, I am yet to find the algorithm for the
MS> shortest set of moves between any two legal states.  Unless I'm
MS> looking at things the wrong way, this is a much more difficult
MS> problem than merely moving all the disks onto one peg.

BB>     You said a mouthful.  :-) Try heuristics?  State tables?

Something clicked when I first read your reply, and the solution
finally came to me!  I've been busy refining the algorithm over the
last few days, using REXX for rough development and C for the final
product.  I wasted much of last night working on a non-recursive
algorithm based on binary counting.  It almost works, but it's
getting very complicated.

In this packet you should find my HanoiSolve program, as well as a
document which attempts to explain my method.  This version just
prints out the moves as text, not graphics, but I wrote it with your
program in mind (I even borrowed a few bits & pieces :) so that it's
very easy to link my code to your program.

I guess I could post the graphic version, but I don't want to annoy
the echo inhabitants who've seen most of it twice already.  :)

I'm getting very tempted to do a 3D version.  :) BTW, sound is a
nice addition to any graphical Towers of Hanoi program.  One of my
REXX Towers of Hanoi programs plays a sound sample of a gong after a
disk is moved.  The sample playback frequency is dependant on the
disk size.  I use a chromatic scale, but I might play with a
diatonic or pentatonic scale for a more musical effect.

MS> AFAICS, the problem reduces to that of finding the shortest
MS> distance between 2 points in a fractal triangular grid.  Any
MS> ideas?

BB>     Bereft.  :-( Other than analysing the optimum heuristic
BB> solution to look for a pattern.  It might make an interesting
BB> expert system project of the learning variety.  Its final rules
BB> might be pretty close to an algorithmic solution.  How about
BB> that for the competition?

Fortunately, it's a bit easier than that. :)

MS> Why do some PC programmers seem allergic to using ANSI escape
MS> sequences?

BB>     Bob just put his finger on it.  Not all visual output
BB> devices respond to them.  That shouldn't stop them but it does.
BB> Cold.  Besides, it's associated with assembler raher than C,
BB> because it implies some specific product hardware knowledge.
BB> The implication if false, but the impression remains.

That's a pity, since these ANSI sequences are probably the most
portable way of doing fancy text output.

Michael Stapleton of Graphic Bits.     mikes{at}incybr.com.au

 * AmyBW v2.15b7+ *
... This tagline is encrypted
--- AdeptXBBS v1.11z (FREEWare/2)