Subject: interface for numerical integration, roots etc
From: Stavros Macrakis
Date: Wed, 26 May 2010 15:03:03 -0400
I agree that having a named-argument convention would be a good thing, but
think it would be a bad idea to overload equation syntax for named
arguments.
I rather like using => or -> to notate mappings, whether in argument lists
or in structured objects.
-s
On Wed, May 26, 2010 at 06:33, John Lapeyre <pdl at johnlapeyre.com> wrote:
> > Consider using the Maxima function assoc along with a list argument. Then
> > you should be able to do things like
> >
> > nintegerate(blob, x, 0, 1, method = 'trapezodial, number_panels = 42,
> ...)
> >
> > The final optional arguments can be in any order.
>
> I want to use the same method of passing options,
> some of which may be equations, in many
> functions, some of which have varying numbers of non-option
> arguments, some of which may be equations. In other words,
> I am looking for a generic way to pass named arguments, mixed
> with positional arguments. So these would work
>
> 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);
>
> 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 ]);
>
> Reading the last two lines, you have to think a little to decide
> what = means (even for the first option); It's similar to a
> listener understanding slightly more slowly when
> disambiguating a phrase. But the last two are not too bad, and
> don't rob the user of privately defining somewhat
> popular infix operator symbols.
>
> Regards,
> John
>
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
>