Subj : baja.c / unbaja.c
To   : Angus McLeod
From : Digital Man
Date : Thu Sep 08 2005 12:44 pm

  Re: baja.c / unbaja.c
  By: Angus McLeod to Deuce on Thu Sep 08 2005 01:42 pm

 >   Re: baja.c / unbaja.c
 >   By: Deuce to Angus McLeod on Thu Sep 08 2005 10:54:00
 > 
 >  >  > I've always wondered at baja.c's not using Dijkstra's algorithm to
 >  >  > simplify ARS, but I guess it pays off, now that unbaja.c is recovering
 >  >  > nested expression again.....
 >  >
 >  > Not sre I understand what you mean exactly... an ARS isn't really a good 
 >  > for a shortest path evaluation.
 > 
 > I meant the use of Dijkstra's *shunting* algorithm or a variant thereof,
 > to convert infix with nested sub-expressions to postfix, for simplified
 > evaluation by the low level processor (in this instance, the BAJA
 > low-level execution code).  I've always found it a little strange seeing
 > parenthesis actually embedded in the low level code as they are (in
 > tokenized form) in Sync's .BIN files.  These are usually removed by the
 > (semi-)compiler by application of some variation of Dijkstra's
 > shunting algorithm.  It's a very basic sort of code-optimization.

Honestly, I wasn't aware of any such algorithm and it didn't occur to me that
the compiled AR strings needed much opimization. :-)

In hind-site, I could've made a *lot* of different/better design decisions. :-)

 > It wasn't a criticism, just an observation.
 > 
 > And obviously, to de-compile postfix back into infix with nested
 > sub-expressions whould be, at best, non-trivial.  So as I said -- that
 > original decision by DM seems to be bearing fruit, what with unbaja.c
 > recently introduced.

Purely serendipitous, I assure you. :-)

                                                  digital man

Snapple "Real Fact" #6:
A honey bee can fly at 15mph.

.