Subject: Revision 1.123 of simp.lisp: Replacing *quo
From: Raymond Toy
Date: Fri, 29 Oct 2010 12:20:22 -0400
On 10/28/10 5:30 PM, Dieter Kaiser wrote:
> The function *quo has been cut out and has been replaced by a call of
> '/' or quot in simp.lisp and in other files. I have done some work on
> simp.lisp, therefore I have analyzed some of the code carefully. I think
> a more correct change would be to replace *quo in the routines addk,
> *red and exptrl with truncate and in simpquot with '/'.
>
[snip]
> All this might be not worth to think about. But because some of the main
> simplifying routines have changed, we might have a look at the reasons
> of the small changes. Another point is, that it seems to be not obvious
> to replace *quo with '/' at some places in simp.lisp.
I think we've had similar discussions before. I, frankly, don't see the
point of replacing *quo with / or quot. There was nothing wrong with
*quo (except the the name, which is pretty hard to distinguish what that
does from / and quot). *quo wasn't broken before, and neither were any
of the users. But now we potentially do, unless we are 100% sure that
such changes are correct. From what you say, it seems that we are not
100% sure.
And, as we know, passing the testsuite only means we pass the
testsuite. It is not a proof that we didn't break anything. If you
look at some of the recent bugs, I think they are caused by changes to
fix other bugs, but inadvertently changing the results, causing other
bugs. This is pretty difficult to avoid but at least the changes were
meant to fix an error. The *quo change doesn't fix an error, and
potentially adds some.
I'm not saying we should never do such changes. It just needs to be
weighed against the possibility of introducing errors. The replacment
of nzero with makelist is ok because it was very clear that nzero does
what makelist does. Changing the special variable foo to *foo*, is
really good too since it makes it really clear that foo should be
special so care must be taken. I just think the changes should be
weighted much more heavily towards not introducing errors.
Ray