Re: [Axiom-developer] Graphics and Axiom (was Re: touchgraph, hypertex, hypergraph)

[root]

Jason,

> While graphics software is under discussion there are a few questions
> I would like to raise:
> 
> With Axiom's current graphics system, is it possible to generate
> graphs of Postscript (or encapsulated Postscript) non-interactively,
> without having the X Window System running? There are circumstances in
> which this functionality would be desirable, including server-side
> applications of Axiom that convert and deliver the graphical output to
> a client via a Web page or similar interface. Some users with
> vision-related disabilities might want to generate a graph of a
> function and emboss it to create a tactile version, or simply include
> it in a document written in TeX/LaTeX, in which case non-interactive
> operation is needed.

Interesting question, actually. I suspect that it is not possible but
only because of the way it is architected.  I looked at the code and
it creates a "graphics context" for the postscript code. The "PS"
button will actually write out the graph as drawn. There may be
a path that skips all of this but I don't see it.

Clearly though it would be possible to output graphics directly to
postscript. Not in the short term though... see below.

> 
> As a more general issue, is it currently anticipated that Axiom will
> continue to maintain its own graphics functions, or would it be
> preferable to integrate support for an externally developed graphics
> language? These two options aren't entirely mutually exclusive, of
> course. Regarding the latter possibility, projects such as
> http://asymptote.sourceforge.net/ are worth watching (they may be
> other, comparable efforts - I haven't tried to conduct a thorough
> search).

I looked at removing the graphics from axiom entirely and using 
gnuplot. The idea was to merge gnuplot and axiom functionality
so both programs benefit. There were a couple obstacles which made
me back off that path. Most notable among the reasons is that graphical
display of data is very intuitive and current programs are incredibly weak.

I found that I'd like more generality in the graphics for several
reasons. For instance,

a) Axiom's graphics are currently oriented toward functions rather
   than fully general geometric primitives. However the geometry and 
   algebra fields are merging. We should be able to do constructive
   solid geometry primitives in the algebra and display them.

b) Axiom should be able to work with models (solid, for engineering),
   (stick, for chemistry), etc where you'd like to be able to compute
   things like beam loadings or binding strengths and not only show
   the function graphs but the physical models. BRL/CAD is a possible
   candidate for use. Students could construct bridges, create vectors
   as test loads, and see when beam parameters are exceeded causing
   bridge failures. Matrix algebra can handle the required differential
   transformations.

c) Axiom's graphics need to be able to handle more general types of
   graphs like Cayley graphs or Thompson graphs of a group. We'd like 
   to be able to do this for our encryption research at CAISS.

d) Axiom's graphs should at least be self-referential. That is, they
   should be able to support the kind of graphs we need like graphs
   of the algebra hierarchy. This would be useful for network flows,
   embedding trees in graphs, etc.

e) Axiom should be able to get direct input from the graphs by allowing
   the user to construct graphs in various ways. For instance you could
   allow the user to construct feynman graphs and write the equations
   from the graphs (each graph is a term in the equation). Or use an
   edge-finding algorithm to find the edge of a strangely shaped 
   object and then integrate to get the volume.

f) Done correctly the graphs should share data structures and memory with
   the algebra. Thus you should be able to create data structures of many
   kinds in Axiom (which you can) and have an isomorphic mapping of the
   data structure and the graph. Thus manipulations of the graph become
   manipulations of the data structure and data structure manipulations
   are reflected in a modified graph. 

   This would allow interactive algorithms for more experimental
   mathematics where you could display results, let the user use their
   intuition to guide the program by manipulating the graph, and
   continuing the computation. For instance, you could guide a
   root-finding algorithm in many dimensions by using visual cues to find
   intervals that contain points of intersections.  You could see
   floating-point polynomial fitting tubes wrapped around a curve and
   find points where the floating point values were unstable.  You could
   see the branch cuts in function terms of an equation and dynamically 
   choose the cuts which overlap in the result.

In short, graphics needs to be more tightly integrated not less.

On the practical, near-term front I've got to get graphics (and
hypertex) running on windows. To that end I'm rewriting the C code
into common lisp and using TK as the front-end. This will make the
graphics instantly portable and much more maintainable. But the long
term effect will be that the graphics code is written in the same 
language and can be run in the same image as the algebra.

This, of course, is not the graphics conversation between Bill Page
and me. Bill pointed me to TouchGraph which allows you to look at
a wiki in a graphical way. The graph dynamically reorganizes on the
screen.

I'm using the code for a similar, standalone version to help me
understand the page layout for hypertex. Hypertex currently contains
a couple hundred pages and about as many links. I need to modify
this tangled pile so it is brought up to date, is better organized,
and is more maintainable.

The TouchGraph graphics for this is written in Java, not lisp.
I'm hacking the code to see if I can make it display something
useful for me at the moment. This is just a subgoal of the hypertex
problem and I have no plan to use this kind of graph in axiom, at
least not the java version. This would be so much easier to integrate
if it were in lisp.

Tim