[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Axiom-developer] documentation and the crystal
From: |
Bertfried Fauser |
Subject: |
Re: [Axiom-developer] documentation and the crystal |
Date: |
Tue, 30 Dec 2003 19:07:15 +0100 (CET) |
Dear Christmas holiday workers!
beside wishing all the best for the new year, I would like to ask a few
more questions about axiom documentation.
a) To me its not even clear how to structurize mathematics. One cxan
build mathematics on sets, hence the Bourbaki approch, or even better (in
my eyes, but equivalent in formal strength) on the *function first*
principle. What to choose for axiom? (In fact the set approch is build-in)
b) I do not see how you can automatically assign semantics to data
strutures etc. I think, one has at least to have a sort of *semantic
typing* during the documentation of axiom (code). Hence every piece of
documentation should come with a semantic type (or multiple such types)
which finally allow to put a direction into the crystal looking glass.
c) Algorithms should be plain and readable and not only be available in
code form (if even this way)
d) To me it would be much more natural to look at the documentation like a
big database and ask SQL like questions. EG:
> select from AXIOM algorithm where domain has commutative;
or such. And then get a sort of (semantic? web?) document which allows to
go deeper into an algorithm, eg, thet should be lionks to al faces of the
crystal which make sense to look at.
e) The system will not be more smart than its designers / users. I do not
see how an automated method will derive anything beyong mere syntactical
sorting. To be frak I have no idea how to reach the above needs.
f) As a probably managable project, it would be of utmost importance for
me (and other mathematically interested, who are stupid programers) to
have just the functionality described above for teh algebra lattice. I had
such an email with David Mentre, where some of the needs were discussed.
g) I do not think that *graph* is the best thing to have. One would need a
sort of *matroid*, ie. a mathematical sound structure which keeps trak of
all sorts of *dependencies* (assuming that independent objects/data are
unrelated) Matroids allow you to keep trak of a minimal set of relations
between objects etc. (You may think of a combinatorial geometry, where the
points/lines/... may or may not be related.
It might be foolish just to have nods and edges, but one hast to
have an n-dimesnional structure of nodes, edges, faces, volumes, ... where
the semantic meaning could be attached to the *dimensionality* of the
object. This would allow to trace up and down iinto the complexity of teh
system if eg. code has teh smallest dimensionality (say 1 dim), algorithms
a hiher (say 3-dim (to let space for future enhancements)) and
documentation of algorithms or a proof it works etc even higher such
dimenionality. A *browser* would offer to display or hide the complexity
away from a user or show it to him.
Say a novice user will be confused to see all details but needs
quite practical help and may be even examples (like in the book)
Sorry for not beeing as structures as you were, but I had no time to think
over Christmas ;-))
cheers
BF.
% | | PD Dr Bertfried Fauser Fachbereich Physik Fach M 678 |
% \ / Universit"at Konstanz 78457 Konstanz Germany |
% (mul) Phone : +49 7531 693491 FAX : +49 7531 88-4864 or 4266 (comul)
% | E-mail: address@hidden / \
% | URL : http://clifford.physik.uni-konstanz.de/~fauser | |