[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?
No.
> 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 ++
comments.
Martin