# [Maxima] interface for numerical integration, roots etc

Richard Fateman fateman at cs.berkeley.edu
Wed May 26 13:14:08 CDT 2010

```common lisp allows keyword arguments.  They look like this
(count 4 #( 1 2 3 4 5 6) :test #'<)  ;; count how many items r  in
vector such that 4<r
(count 4 #( 1 2 3 4 5 6) :test-not  #'<)  ;; count how many items r in
vector such that  not(4<r)..

So the keywords are part of the syntax, prefixed by colons.  The
definition form
is fairly elaborate including optional, keyword, rest, default-values etc.

You can read up on how CL solves this particular problem perhaps by
overkill.

I disagree with RD's comment regarding the -> syntax .

First of all, Mathematica has some visibility and popularity. It's not
terrible to say to
a potential user that the language, say for feeding options to the
integration program,
looks the same in Maxima.

It is in some sense, returning the favor. For example, Mathematica
adopted % from Macsyma.

The rest of the syntax, though hardly exactly the same, coincides in
lots of instances.

Secondly, when Mathematica has adapted some kind of mathematical notation to
try to make it easy to use, it is worth considering whether it is a good
reflection
of how that notation should be written.  Sometimes it is quite clumsy,
and should
be rejected.  Sometimes it is just fine.  WRI might object, but they
could object
to anything.

Robert Dodier wrote:
> On Wed, May 26, 2010 at 4:33 AM, John Lapeyre <pdl at johnlapeyre.com> wrote:
>
>
>>  highlevelfunc(blob, [x,0,1],[y,a,b], u=v, maxiterations -> 10, eq1 -> c=d);
>>  highlevelfunc(blob, [x,0,1],[y,a,b], u=v, maxiterations => 10, eq1 => c=d);
>>
>
> I dunno. I don't see much value to adopting the notation from Mma
> since very few people will recognize it,
Why do you say that? I think there are many people who would understand
the notation without any
explanation whatsoever.  People who have used Mathematica or not.
> and, more importantly,
> Mma differs from Maxima in much more fundamental ways than
> syntax: it doesn't help to use the same syntax when programs are
> going to work differently anyway.
I think the programs WOULD work the same in fundamental ways.  e.g.
numerical_integrate(f, ..[x,0,1],  accuracy_goal-> 0.001,....)  in
maxima vs.
NIntegrate[ ....]
>  Same thing goes for adopting
> notations from Maple or Matlab or whatever.
>
I think that Matlab and Maple notations are considerably older.  I
cannot think
of any redeeming feature in Maple notation, offhand.  Matlab has its
problems,
but the notation for slices of arrays is compact and popular.

>
>>  highlevelfunc(blob, [x,0,1],[y,a,b], u=v, opts(maxiterations = 10, eq1 = c=d));
>>  highlevelfunc(blob, [x,0,1],[y,a,b], u=v, opts=[ maxiterations = 10, eq1 = c=d ]);
>>
>
> I think I like the last one there, although I would spell out "options".
> It's also OK to omit options=[...] and just put the options at the same
> level as the other arguments.
>
I think this has problems.  consider
solve([a*x+b=c],opts=[method=default])   where there 3 instances of =,
each meaning somewhat different things,
as well as two instances of [] meaning somewhat different things.

I prefer hlf(blob,blob2, option1->value1, ...)  or even
hlf(blob,blob2,option1,value1, ...)

by the way,
defrule(name, lhs, rhs)  COULD be changed to

name:lhs->rhs, syntactically,  and was originally proposed that way (by
me, to Joel Moses).  He was uncomfortable
with changing the parser (which was not extensible as it is now).
Mathematica makes much more use of rule definition  (in fact it is the
way most people "define functions").

RJF

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.math.utexas.edu/pipermail/maxima/attachments/20100526/6ae1cff2/attachment.html>
```

More information about the Maxima mailing list