C Y wrote:
RJF wrote..
>>In the interests of not building towers, I would still prefer taking
>>whatever is written (say in Python!) and writing it it lisp so that
>>we have Maxima (in lisp) generating a picture-language that is
>>nothing more than a glyph/position collection (and maybe even
>>plotting, too?) talking to a very simple and OS/machine
>>independent display. Maybe even a postscript interpreter.
>>
>
CY wrote
> I agree this is attractive, but it has several practical drawbacks,
> not the least of which is we would have to maintain everything
> ourselves. Can you give us a rough idea of the problems we would
> have to tackle and solve before this could become a practical
> solution?
If it is written in common lisp, then there is rather little
to maintain on that side. The ability to do "display postscript"
might be machine/OS independent, but I don't know how this
would really work in practice.
My concern is that too much free software in this tower may in fact be
"demoware". That is, it works on selected cases (screenshots), and not
much else can be said about it. This is true of some commercial software
too, I guess. It can be really good or not, and is hard to tell because
the other half of the software production cycle (testing, debugging,
certifying, etc.) is usually not as exciting as the first half, namely
design and implementation.
Computer algebra system users tend to press on the
boundaries: what is the largest computation that can be done?
What is the largest expression that can be displayed? Thus
any front end must be very general, and of course very reliable.
Using someone else's MathML displayer may be a good idea,
but does this program know how to format EVERYTHING Maxima
can display? (Including Maxima language, maybe even lisp?)
Can it do line-breaks? Can it feed back "the user is pointing
to subexpression "s+t""?
To move away from the display issue, consider another issue:
memory allocation. I think that GCL has certain problems in
this regard, and I don't know about CLISP or the offspring of
CMU lisp. If you run a problem and you find you have inadequate
stack to complete it, what do you have to do? Here are
the possibilities:
1. You have to recompile GCL and reload Maxima because the
only way to increase the stack is by recompiling Lisp. 1b. You
then start your problem again, perhaps from some checkpoint,
and hope you have enough stack.
2. You have to reload GCL with a different run-time parameter.
Go to 1b.
3. You do nothing because GCL has increased the stack automatically,
and has continued the computation. The fact that you have run
out of stack means that your computer / virtual memory/ etc
just can't do it. Rethink your algorithm, or make your problem
smaller.
4. Even though there is lots of extra memory, your system was
configured by design to use only 16-bit addresses (or some such
limitation), and your system can't use it. (A problem with
old Maple systems for example.).
One of the disadvantages of free open source software is that
because it is possible to solve problems by (1), the better
solutions of 2 or 3 are not addressed. Even though we know
that recompiling GCL is not something everyone can do, the
fact that it is possible to do so means that some problems will
not be solved "professionally". There are of course advantages
to free software, but it is a balance.
Anyway, I've digressed too much. If someone can tell me that there is a
postscript displayer or a alternative way of spewing characters onto a
screen -perhaps into emacs21 -- not just on linux but on windows -- that
would be great. (I'm willing to build the tower emacs21+maxima since
emacs has clearly gone beyond the demoware stage. I just don't know
enough about any of the other proposals, though I'm trying to learn
more.) Or maybe Gtkmath would be happy to display stuff? I am
willing to write a program that takes the internal form of Maxima
(a+b)/(c+d), and change it to
display times-italic(a) at relative position 10,10
display times-roman (+) at ....
etc.
Though it would be really nice if someone had font metric tables in a
database accessible from lisp.
RJF