[mercury-users] Visual Programming (again)

[Richard A. O'Keefe]

	| It also has a lot of practical problems:
	| how do you neatly lay out graphical programs?  How do you debug them
	
	There are evolutionary algorithms which do a very nice job of
	automatic graph layout - for example, Dr.  Dobbs' journal #302,
	Aug'99 ran an article on this, in an issue entitled 'Visual
	Programming'.  I expect that a user would want manual and
	automatic graph layout features.  I admit it is difficult to
	work with graphs on paper - a whiteboard is somewhat better.

Evolutionary algorithms tend to be s-l--o---w.  There are non-evolutionary
algorithsm; see the visualisation toolkit from AT&T for some nice ones.

	Debugging!  Well, how does bi-directional algorithm animation sound to
	you? You can watch your program running, examine your data structures as
	they are being determined, modify your 'code' during execution /
	simulation
	... :)
	
Once again, we see the implicit assumption that programs are *tiny*.
It's the "Nuclear power plant operator problem":  humans *can't* watch
thousands of nodes at once.  I've got bidirectional algorithm animation
for C (picked up from http://www.dis.uniroma1.it/~demetres/Leonardo/),
and it's cute the first few times you try it.
	
	In a graphical algebra, there is only the one symbol for * and /,

in *your* graphical algebra, perhaps.  Graphical algebras _in general_
can't afford to be that sloppy.  Amongst other things, consider that
	a, b, q, r: integer
	a = b*q+r
and
	a, b, q, r: integer
	q = a div b, r = a mod b
have *different* solution sets, and that in floating point arithmetic
	(a/b)*b != 1 != (a*b)/b
in general.  Also recall that you can multiply quarternions (yes, they
_are_ used in computing) but not always divide them.  You can eliminate
/ in favour of * _only_ for rational numbers.

	If you have a language which supports a variable number of parameters,
	you can also use * to mean 1 (give it no arguments) and + to mean 0.

I imagine that many Mercury users have met Lisp.
	
	| Complex relationships would still end up looking like a complete mess of
	| links, however. The way to minimise this mess would be the analogue of
	| "style" in textual programming, I guess.
	
	No, it would be the analogue of "structure" in textual programming.  I
	envisage a system where new relations (or 'patterns') may be defined (and
	treated as values if need be), so you get (at least) the power of LISP's
	lambda calculus for structuring your programs. You should also be able to
	make multiple images of labelled nodes, if necessary to improve
	readability. 
	
In short, you are re-inventing Conceptual Graphs.  There are already quite
a few CG tools out there. including interfaces to theorem provers and even
Prolog.

	| (1)     disp  = initial*time + accel*time*time/2,
	| (2)     final = initial + accel*time
	
	The asymmetry of your two 'expressions' is the following:
	If I am given 'inital', 'time' and 'accel', it is easy to compute 'disp'
	and 'final' by simple substitution of values into your equations. 
	
	If, on the other hand, I have been given values for *any other* triplet of
	the variables, (e.g. final = -1, accel = -9.8 and disp = 4) I will need to
	considerably rearrange your equations, which may involve solving 
	a quadratic, in order to find values for the other two variables.
	
No, *we* don't do any rearranging at all.  That's the *computer's* job.
Let's take your example of final, accel, and disp.  We get

	4 = initial*time - 4.9*time*time	[computer does this]
	-1 = initial - 9.8*time			[computer does this]
=>	initial = 9.8*time - 1			[computer does this]
=>	4 = 9.8*time*time - time - 4.9*time*time[computer does this]
=>	4.9*time*time - time - 4 = 0		[computer does this]
=>	no real solutions			[computer does this/suspends]

Computer programs have been doing this (symbolically) since the 60's, if
not before.  If I remember correctly, Sketchpad would even have a go at
quadratics.

	If the relation is expressed graphically (see the attachment),
	then most of this algebraic reexpression is rendered
	unnecessary, as there are no '=' signs (or else each link is an
	'=' or 'unify' sign), and no variable is favoured above the others.

Wrong.  The transformations have to be done *somehow*.  If doesn't *MATTER*
whether you enter the relationships graphically or as equations, the
computer is able to use the *same* internal representation and will *HAVE*
to carry out the same steps.  A computer that accepted equations would
probably convert my equations to something like

	EQ1 (EQUATION (+ (* 1/2 (** ACCEL 1) (** TIME 2))
	                 (* 1   (** INITIAL 1) (** TIME 1))
	                 (* -1  (** DISP 1))))
	EQ2 (EQUATION (+ (* 1   (** ACCEL 1) (** TIME 1))
	                 (* 1   (** INITIAL 1))
	                 (* -1  (** FINAL 1))))

which is semantically equivalent but visibly "symmetric".  The presence
of the '=' sign (or any other sign) and which side which term is on are
totally irrelevant computationally.

	In addition, a computer may simulate most modes of the relation
	directly, without need for reexpression.

It all depends on what you mean by 'direct' and 're-expression'.
	|     times(Accel, Time, A_T),
	|     plus(Initial, A_T, Final),
	|     times(A_T, Time, A_T2),
	|     times(A_T2, 0.5, Half_A_T2),
	|     times(Initial, Time, I_T),
	|     plus(I_T, Half_A_T2, Disp)
	| 
	| We may write the characters one by one, but we draw graphs element by
	| element too.
	
	The key is how you *read* the graph, which may be in any mode.
	
So?  You can *READ* the equations and the logical formula in any "mode"
too.   There is *nothing* directional about equations or logical formulas.
If you insist on reading equations or formulas right to left top to
bottom, that's your privilege, but it's a fact about your *choice* to
read them that way, not a fact about how they *have* to be read.

	A graph is transparent
	to meaning, if a person is familiar with the notation!
	
Ah, *IF*.  There's the rub!  I find it difficult to understand how anyone
could _not_ be able to read music, but there are millions of 'em around.
Also, a graph is readble *IF* it is small.  Let's see your familiar
graphical notation for
    - sorting
    - computing the optimal alignment of two proteins
    - the "parts explosion" problem
or something other than elementary algebra.

	I understand parsing to be the analysis of textual source code to build a
	parse tree, a (type of) graph in the computer.  If you program
	graphically, you are assembling the 'parse graph' using direct
	manipulation.

In other words, *precisely* the same steps are taking place, except that
the *user* is making the decisions and _telling_ the computer when to
construct a node, instead of letting the computer discover it.

	For example, the system could suggest optimisations for 
	your graph while you are writing it, whereas normally optimisation is 
	performed in the compile phase, with no interaction.
	
There have been incremental compilers for donkey's years.  The problem is
that in order to suggest optimisations, the compiler must understand the
semantics of all the symbols.  The significance of 'promise' is not that
it call tell the compiler things it should already know about arithmetic,
but that it can tell the compiler similar things about other, quite
complex, types and operations.  Without a similar mechanism, a graphical
interactive optimiser wouldn't do any better.

I note that your diagram took up more than 33kB in my mail, whereas my
equations took 87 bytes.  I can't actually _do_ anything with the diagram,
so I don't know what adidtional information it includes.
--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------