Here the reason of adding the variable VAR to the parameter list of the calls to
the functions:
In the original code we have the following declarations of the functions:
(defmfun $specint (exp var) ... ) ; we call $specint with EXP and VAR
(defun grasp-some-trigs (exp) ... ) ; in the following calls without VAR
(defun defintegrate (exp) ... )
(defun distrdefexecinit (fun) ... )
(defun destrdefexec (fun) ... )
(defun defexec (exp var) ...) ; at this point we have again a call
; with the now global defined variable VAR
Later in the code we have the same situation with the functions NEGTEST and
LTSCALE. We call NEGTEST without VAR, but next we call LTSCALE with the global
variable VAR.
So the use of the global variable VAR is very inconsistent and it might be
difficult to understand. The extension of the parameter list might help to be
more consistent and to have more readable code.
Perhaps it might be even better to use another name for VAR e.g. LTVAR in the
above functions and to emphasize the use of the global variable VAR at such
points in the code we really need it.
The points we really need to use the global VAR are routines which call the
routine M2. The pattern routines M2 use the test functions freevar, hashvar,
freepar, ... which test against the global variables VAR and *PAR*.
Dieter Kaiser
-----Urspr?ngliche Nachricht-----
Von: raymond.toy at ericsson.com [mailto:raymond.toy at ericsson.com]
Gesendet: Freitag, 20. Juni 2008 15:41
An: Dieter Kaiser
Cc: toy.raymond at gmail.com; maxima at math.utexas.edu
Betreff: Re: [Maxima] Further work on $specint
Dieter Kaiser wrote:
>
> Perhaps, it would be the best to combine the two test files at the end. But
how
> many tests we should append to the testsuite is maybe a decision of the
> developpers and project admins of Maxima.
Thanks for working on the test suite. Don't think it matters if we have
multiple test files or combine them into one. But I do want them to be
run by default.
>
> Because I am working continously on $SPECINT there a further changes due to
the
> algorithm for the Unit Step function and the Abs function necessary.
Furthermore
> I would like to add an algorithm to integrate a general summation.
>
> One problem is that because of the more and more additional code to the main
> routines we are loosing the first concepts of the code. It might be necessary
to
> restructure some parts of the main routines to reflect better the main parts
of
> the algorithm and to have more elegant and readeable code.
As long as it's readable first, elegant second. :-)
I do have one question. In quite a few functions you changed the
parameter list to include exp and var. Why was that?
>
> In practice I work with a complete different file. In this file I have added a
> lot of debugging code, grouped the parts of the code which belong together,
> added a lot of comments and deleted a lot of "unnecessary" function calls.
If you want to reorder the file, that's ok with me. But can do the
changes separately? That is, send a patch with JUST reordering. Then
additional patches on top of that. This is just to make it easier for
to figure out what is going on.
Also, the specint stuff is fairly complicated, so debugging code is
good. I think you can leave the debugging code in, but conditionalized
out, if you want.
Thanks again for working on this,
Ray