Hello Robert,
thank you for your feedback.
I think your comments are of general importance. It is a question about what
sort of simplifications should be done automatically by the simplifier, second,
what further simplifications should be supported additionally and last what
would be the best way to implement further functionality.
In addition we have to think about the mechanism to implement the change of the
representation of a function and to implement general rules like SYMMETRIC or
INCREASING.
In the last implementations of new Maxima functions and extensions I have tried
the following way:
(1) Simplify automatically
Use known special values automatically.
Simplify automatically if one of the arguments is an integers or a rational and
the function can be simplified to a general expression which does not contain
special functions. (Is this done consistently? I have to check it.)
Implement known properties of the function like symmetry rules. So the
simplifier can automatically do more simplifications.
(2) Further simplification
Try to give all known knowledge about the function to the simp-function, but do
not use this extra knowledge automatically.
(3) The scheme of implementation
To do this I have used the flags factorial_expand, gamma_expand, beta_expand,
erf_expand, ... This flags are named consistently and switch on more
simplifications for the Factorial, Gamma, Beta, Error functions, ...
I think from the point of the Maxima User such a general naming scheme is very
useful. If you are used to it you will always know what flags could be useful.
Furthermore I have suggested to introduce a general flag function_expand which
could switch on all of these simplifications.
But we can change the naming convention and use expand_<function>.
Remark: The Exponential Integrals do not follow this naming convention. This has
to be done better.
The benefits are:
User code can switch on/off simplifications as needed and existing code has not
to be changed to introduce function calls to special simplifying functions.
The simplifications done by the simplifier are efficient, consistent and works
for nested expressions.
Maximas knowledge of the function is not spread over different functions.
To prevent an unintentional change of the value of a flag we could implement a
message with a warning to the user.
(4) Changing the representation of a function
For a lot of special functions I have implemented the possibility to change the
representation. I have build it into the simplifier too using flags like
erf_representation or hypergeometric_representation. For the Exponential
Integrals I have called this flag expintrep, but that is not consistent and
should be changed.
The simplifier does this change of the representation efficient, consistent and
recursively for nested expressions.
The benefit for the User is to have a choice which representation might be most
useful to continue the calculation or to choose a representation for which
further calculations like integration are possible.
(5) Setting of operator properties
Maxima has build in functionalities to support some general rules for a
function. But the implementations are spread over different mechanism like
defining reflection-rules, conjugate-functions, ...
One mechanism is a call to oper-apply in the simplifier. This is switched on by
the property OPERS T on the property list. When switched on, Maxima search a
rule on the list *opers-list. I think this is implemented up to now only for the
following build in functions:
$KRON_DELTA $symmetric
%LIMIT $outative
MAND $nary
MOR $nary
%SUM $outative
%ERF_GENERALIZED $antisymmetric
%INTEGRATE $outative
There are some more declarations in the database, but I think these do not work,
because the property 'OPERS T is missing on the property list.
Furthermore I think the implementation of opers-apply is not very efficient.
This might be the reason why it is not used for the implementation of the
reflections-rules for the trig functions or the conjugate-rules.
But this could be a further topic to work on.
For the beta function I would suggest the following code to set the operator
property $SYMMETRIC:
;;; Beta is symmetric beta(a,b) = beta(b,a)
(eval-when
#+gcl (load eval)
#-gcl (:load-toplevel :execute)
(let (($context '$global) (context '$global))
(meval '(($declare) $beta $symmetric))))
Dieter Kaiser
-----Urspr?ngliche Nachricht-----
Von: robert.dodier at gmail.com [mailto:robert.dodier at gmail.com]
Gesendet: Sonntag, 8. M?rz 2009 03:29
An: Dieter Kaiser
Cc: Maxima
Betreff: Re: [Maxima] Beta function
On 3/7/09, Dieter Kaiser <drdieterkaiser at web.de> wrote:
> 1. Expand beta(a+n,b) and beta(a-n,b) for n an integer
> The expansion depends on the flag $beta_expand. The expressions
> beta(a,b+n)
> and beta(a,b-n) are simplified accordingly.
OK. The invention of yet another global flag is a little
disconcerting, but there is ample precedent for it ....
Also I wonder if such a thing (whether a flag or a function)
should be named expand_beta instead of beta_expand.
It appears that foo_expand is more common in Maxima
than expand_foo, so, again, I guess beta_expand is more
harmonious with existing stuff.
> 2. Set the operator property symmetric: beta(a,b) = beta(b,a)
Agreed.
Thanks a lot for working on this!
Robert Dodier