bug in continued fraction expansion ? / applying patches

On 6/1/2012 9:36 AM, Rupert Swarbrick wrote:
> Richard Fateman<fateman at eecs.berkeley.edu>  writes:
>> I continue to object generally to patches and files whose authorship
>> can be discerned only by examining the separate change logs, so any
>> alterations to pre-existing functions should have comments identifying
>> authors, too.
> A serious (and hopefully non-flaming) question: Why should you care who
> wrote lines 245 - 283 of the source-file foo.lisp?
>
> Vaguely plausible answers I can think of:
>
>   (1) I want to rely on the author's authority in the field to be able to
>       assume the code is right.
or the reverse:
  knowing that the author is perhaps not known for checking his/her code 
carefully.
or knowing that the author is distinctly lacking in authority (e.g. 
changes made by a
high school student who thinks he/she knows calculus "better".)
>
>   (2) I want to know when a function changed from the version that was in
>       commercial Macysma.
sure, except we don't have that version in source code.  The fork was 
back in 1982 or so,
and both threads have changed code.
>
>   (3) I don't want to run any code written by<someone>.
well, I haven't experienced that.
>
> Am I missing your motivation here?
I assume that with sufficient effort I can find out who last made a 
change to a line in the
source code, and with more effort who was previously the author of that 
line, if the
line still exists.
I would like to be able to take a file and print it out, and take it 
somewhere away from
a computer, and see if someone has recently over-written a piece of code 
near where
I think there is a bug, and who that someone is.
>   I would say that none of these cases
> support your call for littering source files with attribution
> comments for the following reasons:
>
>   (a) They generally end up out of sync with the actual author of the
>       line at hand.
Huh?  if the author marks the lines as I suggest, it would not be out of 
sync.  I
would not mind a minimal set of attributions that look like this  (in 
fact I sometimes
do this myself to avoid having to put simple tasks under source control)...

;;; the old version prior to 5/28/12
#+ignore
  (defun foo ...)
;;; the improved version 5/28/12 2PM RJF
(defun foo ...)

>
>   (b) If a minor bug gets fixed in an algorithm, should there be an
>       attribution note in the source file?
definitely.  As is well known, simple fixes to minor problems are 
sometimes sources
of new bugs.  If I can look at a piece of code and see that there was a 
recent bug
fix (esp. by someone I consider unreliable), I will look first at the 
bug fix to see if
has introduced (another) bug.

>
>   (c) What about if someone ports an existing function to use a new
>       interface to other code that's changed?
I'm not sure what you are saying, but if there was an act of authorship 
involved,
I think the author should take responsibility, meaning both the claim 
and blame.
>
> To me, (b) and (c) are problems that are both practical and theoretical
> and (a) is merely practical. Note that if you are willing to use a
> version control system (which Maxima has done for some decades now), all
> of these problems are solved for you, without the need to leave
> uninformative comments all over a code base which is distinctive by its
> lack of explanatory comments. Grr.

A version control system is important when there are many workers 
potentially altering
the same code at about the same time.
It makes sense when the natural division of code is a file.

For Maxima, I suspect that there are rarely people simultaneously 
modifying the same file;
checking out/in files is potentially useful.

However, the natural division of code in Maxima and Lisp is a 
definition  (defun .. ..)
or some other similar expression like defvar, defmacro defmfun defprop.

Checking files in and out is therefore a poor fit.

There is a history of "environmental" development systems esp. for Lisp, 
as used
in interlisp or bbn-lisp.  This mode of operation, in which a system is 
incrementally
defined interactively, edited and tested WITHOUT LEAVING LISP.
It has not prevailed in the market, but the model that has prevailed, namely
source-code-control-edit / compile/ load /make-dump/ debug/ ... is clumsy.

It would be totally unacceptable except for the fact that computers are so
damned fast that it doesn't take long to recompile fairly large code 
collections.

RJF




>
> Right, rant over. Will go back to my algebra code now.
>
>
> Rupert
>
>
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima