On 1/27/2012 8:16 AM, Rupert Swarbrick wrote:
>
> Right. I'm not sure if you've actually read my message? Or maybe I
> wasn't clear.
I didn't read your earlier bug report previously, but I just read it.
It seems to me that remrule doesn't do what the documentation says.
I haven't tested it much, but I suspect that it either works if you
remove ALL the rules,
or if you remove the most recently defined rule.
In fact, it is kind of unlikely that the author of this code (initially
me, in about 1969), tried
it in the circumstance that you have come up with. That is, defining
rules with the
simplifier OFF does not usually make sense. After all, if you are
defining a rule
F(A) --> B, and then try to define another rule F(A) --> C, the
simplifier will change that
latter rule to B-->C. If you didn't mean that, then what did you mean?
The only time turning the simplifier off makes sense is if you are
trying to over-ride
a built in simplification. e.g. if you would like to do
tellsimp(0^0,undefined).
I suspect that one fix would be to change the documentation to say that
remrule will only remove
(a) all the rules on an operator or
(b) the last rule on an operator.
I am sure that there are lots of anomalies that could be uncovered in
Maxima by turning off
the simplifier and expecting Maxima to do whatever a user imagines that
it should do in
such a circumstance.
>
> At the moment, tellsimp/tellsimpafter and remrule interact weirdly. The
> reason for this is (I presume) a performance hack. My first try to fix
> this works by removing the hacky method and replacing it with something
> sane. It appears to work at least as fast, or faster.
>
> I'm aware that I can work around bugs, but that's an... unusual
> approach.
Well, it depends on the circumstance. I agree that remrule doesn't do
what the documentation seems to
indicate it should do, but don't you think you are doing something
pretty odd? After all, you are saying
that the system should simplify the same exact expression, foo(1) into
two different results, and doing so
by temporarily disabling the simplifier. Can you think of no other way
to accomplish your goal?
I think that
tellsimpafter(foo(1),a)
tellsimpafer(foo(1),b) is a user error, and if you hadn't turned off
the simplifier, you would have gotten an error message.
if you had said
tellsimpafter(foo(1),bar(1));
tellsimpafter(foo(1), b);
you would have been informed that the second rule was placed on bar,
not on foo.
While I don't want to exactly correlate it with your situation, I would
dispute that your
statement about working around bugs is unusual. It is probably the most
frequent approach.
It happens like this: a bug is reported. The person in charge of
resolving bugs decides that it
is not a bug, but a "user error" or PICNIC. "Problem in Chair, Not in
Computer". The advice
is to change the user program. User does so and continues until the
next bug...
From the user perspective it appears he/she is being told how to work
around a bug.
Statistically speaking, user error constitute a vast majority of
reported bugs in programs.
> Are you saying that I should not expect Maxima to have sane
> semantics with defrule and friends?
If the documentation of remrule is changed, does that make it sane? Maybe
one should also add that any bugs that occur only when simp:false, are
user errors.
> Or do you think that I was trying to
> write this to improve performance?
Nope. The difference in performance for tellsimp/tellsimpafter should be
negligible.
The initial implementation was complicated by the notion that after a
bunch of tellsimps etc
one would end up with a single subroutine that could be compiled into
machine code.
This would be harder to do with a separable list of rules. In practice,
no one compiles the
subroutine.
RJF
> Or have I misunderstood you?
>
> Rupert