One key subgoal that is completely independent is to figure out how to
draw a line on the screen using SBCL or CLISP and the new lisp-based GUI
work. planet.lisp.org has had several discussions about this. A lisp-based
GUI for graphics would be much more portable.
Do you mean just for plotting or a complete user interface ?
I have a project to redo HyperDoc using _javascript_ and XMLHttpRequest.
This uses a browser as the front end for the hyperdoc pages and uses
an axiom back end to service requests for actions. Eventually this will
go into the Doyen Wiki. I've rewritten a couple dozen pages so far and
am working test examples.
Yes, HyperDoc show its age. Can you already generate static HTML ?
Why do you want to use XMLHttpRequest for ?
I have a project to document the integration routines in axiom. I have
several sources of text (Trager's thesis, Bronstein's thesis, etc) as
well as 4800 integrals that came from the Maple test suite (reported
on elsewhere in this mailing list). I've modified axiom to tell me
where each integral resolves and am classifying the various integrals
into sets of examples. That way each of the 40ish 'integrate' routines
will have example input associated with it.
My experience with Bronstein code is that there is not much comment and it is very architectured. I have not try to read the Risch implementation. I think Martin had a look at it.
I have a project to port axiom to the MAC. The key issue is getting GCL
to build on the MAC. Since MACs are based on BSD the include file chain
is completely different from linux and so things resolve poorly. Plus
I find the MAC impossible to use (my ability to use a system is
inversely proportional to its "ease of use").
Being a Mac user I think this should be the top most priority ;)
Each of my try was stopped by GCL too. It is more than BSD issue Darwin use CMU microkernel and the way the stack is created is different from BSD or Linux.
I am sorry you find the Mac difficult to use. Have you try Fink or DarwinPort ?
I also recomend this Emac http://homepage.mac.com/zenitani/emacs-e.html .
I have a research effort to rewrite the algebra using provisos.
This uses the idea of generalized intervals to contain conditional
statements that constrain the validity of computations.
Will all domain need to be made provisos aware ?
How will the conditional description be part of the type ?
The database design in Axiom is old. It uses random access files which
follow VM/370 LispVM design. These databases should be redone using a
better overall design.
What is this database ?
Axiom needs updated Groebner basis work (although the current routines
performed quite well at ISSAC 2006 when compared to singular and maple)
I think the algebra need a good clean up. I have spend quite some time with the polynomial univariate and multivariate and you can see they have been done at the begining. I think that a lot of work form Aldor libAlgebra should be included in Axiom.
Axiom needs Symbolic Summation (extensions of Gosper's work)
I am doing works in that direction.
Axiom needs to be able to do higher-order expressions like:
x := p^n * 3*p^m + 2
y := q^r * 6*q^s - 3
what is the j'th term of x*y? Well, since the we don't know the
exponents (n, m, r, or s) we have to construct a function that
will return the k'th component of x, the i'th component of y and
a final function that gives the result of x*y as a function of
the component functions. f(x(k),y(i)). Nobody does this yet to
my knowledge.
I need to check but I think work related to this as been show at last ISSAC ?
Also I have trouble with the _expression_ domain I dont really understand how to use it. I will like an _expression_ tree better.
If X is an 2x2 matrix what is X^p? If x is NxM what is X^p?
I think there is already a distinction between sqare and not sqare matrix ?
What is the i,j'th entry?
I dont understand this question.
Can we construct a Maple parser that will generate Axiom internal
S-expressions? This would allow us to replace the Axiom input language
with a Maple input language. Is this useful? Is this better than B#?
That look complicated.
My understanding of B# is it will be a smart interpreter that can do as much type guessing as possible. But if people want to specify type they should be free to do so.
If we decorate the Categories with their mathematical axioms can
we prove anything about them? Can we do it automatically using ACL2?
Can we extend the compiler to do the proof while it compiles?
Very difficult.
Can we define a "problem graph" semantic network that will sit at the
heart of the crystal? What is the subsumption rule and is it theoretically
sound and stable?
I dont understand.
Axiom should be attached to a Computer Aided Design program to
model the stresses and strains and theoretical failure points.
FEM analysis is traditionally more on the numeric computation side. But people are working on mix symbolic numeric method( http://www.sfb013.uni-linz.ac.at/ )
Axiom does not use threads or multiple processors but this is
clearly the future direction of hardware. We need to find algorithms
that can be done in parallel and work up an example that gives linear
speedups based on the number of processors.
You need very good language support to make this practicable.
Also parallel algorithm tend to be significantly more complicated.
Regards
Antoine Hersen
_______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org http://lists.nongnu.org/mailman/listinfo/axiom-developer
