[Top][All Lists]

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

RE: [Axiom-developer] document, graphics

From: Martin Rubey
Subject: RE: [Axiom-developer] document, graphics
Date: Tue, 12 Jul 2005 16:39:35 +0200

Dear Bill, Bob, Kai, Ralf, *,

 > What is the size of the unit input transaction? Would one Axiom command per
 > transaction might be too limiting?


 > Of course it might consist of multiple lines even for a single command. But
 > what about multi-line function definitions? What about compiling SPAD code,
 > versus interactive use? Should we treat a SPAD compile as a unit
 > transaction?

Yes. Well, the compile of one domain or category. If I'm not very mistaken,
domains and categories are simply (complicated) function definitions.

 > What about Axiom commands that do not increment the line counter
 > such as
 >  )set output autoload off

In fact, )co is also such a command, I think.

(I'm very much hoping that in future the interpreter will also be able to
handle domain and category definitions...)

 > > The second part of the discussion is non-mathematical input/output.
 > > e.g. graphs, diagrams.  Can we do the same thing as for mathematical
 > > output?  (e.g. the output contains only data structures and hints, and
 > > no code?)  This requires a graph renderer/manipulator which understands
 > > the underlying data structure.  (e.g. 1-dimensional point set,
 > > 2-dimensional graph, 3d point set with mesh, etc) "understanding the
 > > data structure" is a separate problem from "communicating the data
 > > structure" since the latter can be simply marshaled into an sexp
 > > or XML data structure.
 > >
 > > Furthermore "draw" should really be an alias for "give me a point-set
 > > approximation".  Axiom generates a point-set.  The *user-interface*
 > > must decide what to do with it.
 > I am not convinced that a "point-set" language would be adequate
 > given problems of resolution, scaling, rotation etc.

Me neither. But maybe the user interface can ask axiom to produce this or
that. As far as I know, this is the way graphics is handled now. Look at 
view2D.spad and view3D.spad. By the way, SOCK_-GET_-FLOAT doesn't work on linux
right now, see bug #161...

 > > ... let's keep "pamphlet" as our primary format for the
 > > time being, and convert it.
 > Convert it during the build and install process? Continue
 > to maintain it in the format used now. Right?

yes, yes, yes! Though I wouldn't mind if the pamphlet format would change. The
philosophy should remain the same! Ralf Hemmecke thought quite a bit about a
better documentation format for Aldor, which would also work for Axiom, of
course. What is missing currently in the pamphlet format is an environment that
briefly documents the domain/package/category and an environment that briefly
documents an operation. For HyperDoc, this was done with the +++ and ++


reply via email to

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