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

[Bill Page]

On Thursday, January 20, 2005 4:04 AM Tim Daly wrote:
Jason White wrote:
> 
> > 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?

No it is not possible without X Windows running. But it is
possible to do it non-interactively. The commands look like
this:

   viewPort:=draw(sin x, x=-%pi..%pi)
   write(viewPort,"your-file.ps","postscript")

> > 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.

Yes, we have exactly this problem on MathAction. In this case
to get around this limitation what I am planning to do in fact is
to install X Windows on the axiom-developer.org server using the
X Windows framebuffer virtual graphics device (fbdev). Yes, this
is possible even though we will not have access to a graphics
console. `fbdev' is often used to allow remote access via VNC.
I use this very successfully with a remote debian server. Having
this kind of remote access to axiom-developer.org will be useful
for other reasons.

So on MathAction, the above commands will actually start Axiom
graphics in a local X-server environment (even though it will
never be viewed directly via a remote VNC session) and then it
write the postscript that is then processed by LatexWiki (or
perhaps be converted directly to png format) to display the
graph on the web page.

Doing this in MathAction is still all "in theory" of course.
I am not sure what sort of overhead will be involved in doing
this on the server. (The usual solution I guess is buy a bigger
server. Buying hardware is still a lot easier than writing
software.)

We have a similar problem with integrating Axiom graphics into
TeXmacs although in this case the workstation running TeXmacs
(on linux at least) will already be running in an X environment.
I guess what will happen is that the Axiom graphics window will
pop-up, write out the postscript file, then close. TeXmacs will
get the contents of the postscript file and do it's thing.

> > 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.

Yes, this will be possible on MathAction.

> 
> 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.

Don't forget the `write' command in Axiom graphics.

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

??? This *is* possible now - provided you do have an X windows
environment available.

> > 
> > 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).

Thanks for the reference. Asymptote looks VERY interesting to me.

> 
> 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 think we should be open to the idea of integrating such programs
as Asymptote and even tools like gnuplot. Even though in some cases
they may do less than we may want in general. Reduce already has an
gnuplot interface. It is possible to use Reduce and gnuplot on
MathAction. See:

http://test.axiom-developer.org/Members/billpage/ReduceTest1

I would like to be able to do the same with Axiom and gnuplot.

> 
> 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.
>

Asymptote sounds like a good choice for this.

> 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.

I am worried when a system like Axiom begins to try to be "all
things for all people". I think this approach is already starting
to kill other computer algebra systems like Maple and Mathematica.

> 
> 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.

This seems like it is confusing general graphics with plotting
functions. Yes I agree they are related, but trying to do this
in an "all-in-one" approach seems wrong to me. Instead we should
be making use of other tools by integrating them with Axiom
where licensing conditions allow.

> 
> 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.

For the visualization part, Asymptote seems like a good tool
to me.

> 
> 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.

Of course there is no problem with this in principle, all it
takes is some Axiom programming. This sort of integration of data
structures and algebra is already part of the basic design of
Axiom.

> 
>    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.

I don't see any conflict between these goals and integrating other
software.

> 
> 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.

Well you are the lisp programmer, Tim, but this sort of re-writing
of existing code seems like the wrong choice for a "near-term"
solution. Is it really practical for one person to do this sort
of conversion from C to lisp? Realistically, how many lines of
code are we talking about? How many graphics primitives will
need to be translated? Etc. etc. :(

Regards,
Bill Page.