Hi,
I noticed this bug[1] the other day and spent a while thinking about
it. The way that simplification rules for operators currently works is
a property on the symbol called (confusingly) 'operators.
To declare a simplification rule, you define a function and set (get
'myoperator 'operators) to that function. To chain rules in tellsimp and
tellsimpafter, there is a complicated system, where the new rules call
previously defined rules in the start/end of their function bodies. This
is rather brittle and, since the interiors of the functions can't be
changed after the fact, causes bugs like this one.
I wrote a different implementation, where 'operators is kept (for
backwards compatibility), but just holds one rule, with no
chaining. tellsimp and tellsimpafter push functions onto a list stored
at a different property, which get called in order.
Current status: It works, but I haven't implemented some of the tidying
up that removerule did, so there's a bit of work to do yet. I was
worried about the performance: surely such a brittle system as the old
one had to be done for performance reasons! So I ran the testsuite for
timing, and it actually came in faster (30 seconds faster on about 10
minutes total), but this might have been down to noise. There are no new
failed tests.
My question is the following: Should I spend a few more hours making a
tidied up patchset and testing it as thoroughly as possible? Would such
a change be merged? I don't particularly fancy spending hours on
something that will be rejected out of hand just because it touches
src/simp.lisp...
Rupert
Footnotes:
[1] http://sourceforge.net/tracker/?func=detail&aid=1204711&group_id=4933&atid=104933
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 315 bytes
Desc: not available
URL: <http://www.math.utexas.edu/pipermail/maxima/attachments/20120126/3193d9b8/attachment.pgp>;