[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: C Y
Subject: Re: [Axiom-developer] Graphics and Axiom (was Re: touchgraph, hypertex, hypergraph)
Date: Thu, 20 Jan 2005 06:55:34 -0800 (PST)

--- root <address@hidden> wrote:

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

Just curious - are long term graphics discussions planned as part of
the Axiom conference, or is that too far down the road as yet? 
> 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.

Hmm.  Can you give an example of the Tim?  I'm not sure what you mean
by geometric primitives - triangles?  pentagons?  buckeyballs? ;-)

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

That sounds like almost entirely numerical work, except for simple
cases - almost a Matlab+ type setup - I take it the long term goal is
to provide Axiom with robust, optimized numerical abilities?  What a
fascinating idea to combine all these abilities.  You could have a
worksheet where people work their way from manipulations of the basic
physics equations describing oscillations on a symbolic level, and then
provide a model of a real spring for them to simulate numerically.  Or
if you could tie to some high energy physics libraries, you could
perhaps do the symbolic calculations to define your theory, and then
define and simulate an experiment to test it in the same document!  Or
you could include abilities of programs like Igor for data processing
and manipulation.

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

One type of program I've wondered about is Pigale 
I'm not up on the theory of what it's trying to do, but it has always
impressed me as an interesting program.  There was some talk a while
back about adding some abilities into Maxima to work with it, but
nothing came of it at that time.  I wonder if Axiom would be a good
match for it. 

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

You mean combine function and call-graph styles of plotting?  That
might have some interesting possibilities.  You could show the change
of a function at each step of a calculation (if that is of use for
anything besides maybe making a poster.)

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

That would be NEAT.  If Axiom ever gains the ability to solve PDEs,
perhaps you could use this mechanism to graphically define boundary
> 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 is one of those little mundane questions, but for 3D plots do you
want to do just wire frame or also have the option of camera and
lighting as in VTK or Izic?  (or a variety of molecular display
programs, if we get into chemistry, or solid views thinking about
brl-cad, etc.).  If we want to be capable of "presentation graphics",
where would that information be stored?
>    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.

Powerful stuff.  That reminds me (not sure why) - is there a "standard"
way to display a Dirac delta function?  Or is that something Axiom even
knows about?  In physics they show up a lot, but I don't know how
common or useful they are/would be in typical Axiom work.

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

Very exciting times!  


Do you Yahoo!? 
The all-new My Yahoo! - Get yours free! 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]