Hi folks!
Although this is a bit early, because I'm very new to Maxima, I wanted to
get it out. I hope Maxima will be THE cas for me and lots of others, so
here are my proposals: (Please note, just ideas!)
[policy]
1. Maybe it would be good to get the mailing list a little organized? I
would
propose to use the following indicators (always in, say brackets)
[policy] organisation, goals, visions, etc.
[install] installing issues
[user] on using maxima
[devel] on developing maxima
[doc] on documentation
This would make it very easy for me to create a (monthly?) digest, if
wanted. More importantly, I could skip more easily those parts I'm not to
interested in.
(Yesterday I read the whole archive 2001. My wife is a little angry...)
-------------
2. How about a good and bads list:
Goods:
GPL
access to lisp -- what a wonderful language for doing maths! --
underneath, mathematica, maple don't have this!
doesn't (!) simplify automatically like mathematica does. This is a great
feature, because often I KNOW that some expression doesn't simplify.
Mathematica then still tries, takes quite some time (I had a case with 20
seconds per eval on my notebook) and then returns the input
nearly unchanged! It's important to me that the cas does exactly what I
tell it to do, no more!
wonderful interface to emacs that makes debugging easy -- Mathematica
doesn't have this!
highly portable on every layer (is this correct?)
very nice integrated doc (I like texinfo and describe!)
probably a lot more
Bads
doesn't use assumptions enough yet
probably a lot more
-----------
3. I like the name Macsyma better...
-------------
4. Lisps
I think the idea of Richard Fateman concerning the use of Allegro could be
exploited differently, too: Why not encourage (ask) Lisp vendors to
support maxima and gain a nice package for their users. "Support" could
be: contributing to the building procedure, bug reports, (conditional)
additions and maintainance to the kernel to make maxima run faster,
better, etc. with their lisp (no new features!!!)
I think it is very important to keep maxima running with as many FREE or
GPL lisps as possible (especially with gcl, because I like the idea of
maxima --> lisp --> c!) which probably means to make it as common lisp as
possible.
--------
5. I like the idea of having subdirectories working, nonworking and
untested. Why not add a standard comment on the first line of the package
or have directories
/share/algebra,...
/share/untested and /share/nonworking?
Vadim V. Zhytnikov vvzhy@mail.ru
Tue, 25 Dec 2001
>As for directory structure I think that one share directory with sub
>directories
> /share
> /algebra
> /matrix
> /graphics
> /ode
> ....
>is the most logical way to arrange things. It is very convenient
>from the user's point of view and libraries in Maple and
>Mathematica are arranged in similar fashion.
great! I'd add
/share/combinatorics
>Subdivision of the style "tested/working/nonworking" seems to
>me less important. Some packages may work on maxima+gcl
>but fail on other lisps.
this really shouldn't happen too often after 6.0!
>But simple Maxima patches will
>change their status. Some packages must be
>used as source to work properly but it seems that there
>are also others which must be compiled. Finally I
>guess there are lot of packages which require just
>few lines of change to make them work.
Let's see.
[Devel]
1. Question: aren't most functions (lisp files in src) really
packages, only written in lisp?(If I got things right, this doesn't make
that much a difference to maxima) I'd like the separation in a kernel and
packages! For example: I simply won't ever (ok, maby once a month) use
integration, diff,... so, if possible:
separate kernel (to be defined) and packages as much as possible
in the init file I tell maxima what I want to use always!
maybe this would help to maintain things.
2. I like the standard for a position in mathematica, i.e. -1 is the last
element in the list.
3. I like the idea of conversion, touched by Mr. Fateman and dan stanger
earlier this year. But I'd find it good to have it the other way to. So I
could do something in Maxima, and then look what Mathematica does with it.
(I'm talking of "simple" things like sums and Intgrals and the like, no
sophisticated macros)
[user]
1.
I don't quite understand dan stangers reply to my integerp question: He
writes
> No. When a symbol is declared INTEGER, automatic simplifications can
> exploit this fact. For example, SIN(n*%pi) simplifies to 0 if n is
> declared INTEGER. A symbol can be declared INTEGER if it is known to
> represent an integer. INTEGER is a member of the FEATURES list. It
> can be asserted with DECLARE, withdrawn with REMOVE, and detected with
> FEATUREP.
What's IntegerP for, then, if it doesn't use features. I found it used
quite often in nusum.mc for example.
I feel, it should be there to test wheter x is an integer expression. So
Declare(x,Integer); IntegerP(2^n);
should give T.
If I want to test for a actual number, I would say
IntegerP(x) and NumberP(x);
By the way, what's the difference between assume and declare, in my
opinion,
declare(x,positive);
and
assume(x>0);
should really be the same thing...
(By the way, KIND is not known at my maxima, but I didn't get the latest
version yet!)
---------------
2.
I really like to use
[a,b]:[1,2];
instead of
a:1;b:2;
but it doesn't work in 5.6! does it work in 5.9pre?
----------
3.
Maybe I get my prof Christian Krattenthaler to have a look at the sym dir.
He knows french better than I do and schur functions a lot better then I
do. (But I'm working on both)
-----------
Sorry for the long list, but I had to fetch up now. And sorry for not
citing enough, I'm not too good with pine.
Happy new year!
(Guten Rutsch!)
Martin Rubey
www.mat.univie.ac.at/~rubey