On Jan 23, 2008 9:15 PM, Rupert Swarbrick <rupert.swarbrick at lineone.net>
wrote:
> However, I decided that I really needed to understand
> Maxima's simplification routines better, so I've been slowly working my
> way down simp.lisp. To ensure I read and understand, I've been writing
> documentation strings for the functions as I go, along with reindenting
> them for readability.
>
Adding documentation to the CVS tree is a good idea as long, of course, as
it is correct.
Can you tell the cvs diff tool to ignore space? If not, changing
indentation makes it hard to compare versions.
Then again, even adding end-of-line comments makes comparisons harder.
Maybe best to stick to ;; and ;;; comments on separate lines.
2) There are lots of smallish utility functions in simp.lisp, in
> particular predicates like mplusp and the like. As a general comment, I
> think it might be nice to group up, say, predicates in a file of their
> own for reuse - I'm sure we'd find the same code with different names
> in different parts of the tree.
Yes, there is lots of redundant code. And there are at least four
"standard" packages of utility functions: opers/mopers (which I wrote the
ancestor of 30+ years ago); mrgmac (Mike Genesereth); rzmac (Rich Zippel);
strmac (? most of these aren't used anywhere and include dangerous ops like
make-***-simp).
Though in theory I like the idea of making everything consistent, again this
will cause a lot of code change that doesn't reflect functionality change.
If we do this, it should be in one big push on a very well-tested, stable
version, not randomly checked in. Also, it should be decided by the group.
Your "good taste" may not correspond to others' "good taste".
3) Some of this code involves lots of copy-paste - in particular the
> predicates like ratnump and mplusp, which just check (caar x) - I think
> this stuff would be quite amenable to "macroization", which would mean
> other tests on the caar could be performed trivially.
>
Let's not worry about microoptimizations like this, though they are
tempting. Ideally, we should be able to have the compiler auto-inline when
appropriate. (I know, this depends on things like build order.)
4) Goto! Aargh! I never realised _how_ incredibly difficult it is to
> understand code with gotos - for example uses them heavily. Although I
> understand the code is working currently, I think it's worth going
> through this sort of thing and tidying it - after all, if I found a bug
> somewhere in the middle of simp.lisp: in plusin, say, I'd just groan
> and try to ignore it: the code's just so complicated that it's
> incredibly hard to keep in one's head at once (unless this is just me
> being rubbish!)
The code is hard to understand in many places. This also means that it is
hard to rewrite correctly. And again, changing code without changing
functionality makes for distracting diffs. The interactions among the
simplification routines can be subtle, so something that seems like an
improvement may in fact break other things.
I'd recommend you take some *specific* bugs that have been documented and
fix them as locally as possible (i.e. don't rewrite everything). For
example, making sure that 2/sqrt(2) simplifies to sqrt(2) without breaking
anything else.
5) (ahah there was another question) Can anyone explain the idiom of
> writing a defun containing just a ((lambda (x) ....) nil))
((lambda (a b c) ...) av bv cv) == (let ((a av) (b bv) (c cv)) ...)
Let was introduced into MacLisp sometime in the early 1970's, after a lot of
Maxima code had already been written. The semantics are precisely the same;
let has the readability advantage of putting the a's close to the av's.
-s