> John, thanks for looking into this. If there is some function which
> does something for which Maixma has no built-in equivalent,
> then it makes sense to implement it. However, creating aliases for
> existing functions seems very inadvisable. In some cases maybe
> an existing function could be extended with a new feature.
My thinking evolved on this. I originally had the same idea
as you. But extending the capabilities of Maxima is only a
minor goal. The main idea is to bring Mathematica users and
Mathematica user code to Maxima (no, I don't mean kill
Mathematica). For functions that duplicate functionality, I
would recommend the native Maxima if possible. But, for
translating code, its better that someone invests four hours
translating into suboptimal, but working Maxima code, rather
than choosing not to spend 20 hours translating into core
Maxima when thats the only choice.
If the user base and amount of useful code increases
significantly, so will the number of developers who can work
on all the things that need to be done to Maxima. (Of course
this depends on how far I go with the project and whether it
does attract people after all. I can't predict
if that happens.)
> In particular, Fold, FoldList, Nest, NestList, IntegerDigits,
> and FromDigits seem to offer features which aren't provided
> by Maxima at present. So it makes sense to implement those
> in some way (not necessarily an exact translation of the
> Mma functions).
I was wondering too whether to make them exact or make improvements
or othe changes. As I said above I am coming around to the
idea duplicating functionality as closely as possible. The Mma
functions give a focus to developing these algorithms and functions.
Someone may think integerdigits should be different and fit into
Maxima differently. So he can implement it then. Maybe IntegerDigits
will call that function. But IntegerDigits is done and its part of
a package; the idea is out there. If I hadn't put it in this
package, integerdigits would be sitting on my hard drive, half
implemented.
I think extending an Mma compatibility functions without
breaking compatibility is a fine idea. Or you could have a
switch turns strict compatibility on and off, like gcc. But
thats more than I want to deal with right now. Of course,
people can, and will, do whatever they want with them.
>Sinc is a widely useful function, but unfortunately creating a new
>Mathematical function in Maxima is a bit of work. Still, we should
>get started by listing the properties a sinc function should have,
>and then figure out how to tell integrate, diff, limit, etc about the
>new function.
Yes I didn't think about Sinc, when should it be evaluated and
so forth. Its probably useless now, because it doesnt give any
advantage over typing the expression in by hand. It should be
improved or removed. I am experimenting.
> The existing first function could be extended with a second
> argument to get the functionality of Take, I think.
Yes thats a good idea.
> There has already been some work on a range function in Maxima,
> dunno how Mma Range compares. I'm inclined to recommend
> additional work on the existing stuff instead an incompatible
> definition.
Barton gave me several tips and pointed to his range code. I'll
certainly replace my kludged stuff with his work.
> Aliases of existing functions (Union, Tr, Eigenvalues, etc) seem
> ill-advised.
I don't know if you saw version 0.04 or 0.05. But they are not
just aliases. Union, Intersect, etc. take either a sets or
lists and return the same type. Also, eigenvalues are returned in
two different formats in the two systems. For an inexperienced
user (well and for me) its a PITA to munge the Maxima list
if thats not the form you need. When translating Mma code,
this munging would have to be done every time, or reimplementd
or whatever. The matrix functions work on Maxima matrices or
nested lists. Again, the idea is for the user not to worry
about translation details. Also, many of those functions can
be developed further.
> I think there are some features which could be useful to Maxima,
> so we should try to sort them out and plug them into the
> appropriate places.
I agree. A lot of what I write will be of varying
quality. It would be great if it stimulates someone to
integrate these things carefully into Maxima.
Thanks,
John