inconsistent condition numbers from cond, det, inv functions

[David Bateman]

Rolf Fabian wrote:
>
> John W. Eaton wrote:
>   
>> On  7-Feb-2008, David Bateman wrote:
>> If someone makes major changes to a file, then I think it is
>> reasonable to add them as a copyright holder for the file, and there
>> are a number of files in Octave that have multiple names listed in the
>> copyright lines.  If we missed some, it is not intentional.  But at
>> the same time, a few lines changed doesn't seem like a sufficient
>> reason to change the copyright notice.  Credit is certainly given in
>> the ChangeLog files.
>>
>>     
>
> In the case under consideration the change done by me was
> much more than essential. Judging the importance of
> a code change simply based on the number of changed lines
> is not appropriate at all. Or should a lengthy code really be
> considered better than a short comprehensive elegant code?
>   
I don't believe it should be judged at all on the number of lines of
code but consistent in all case... Yes there have been cases where
authorship/copyright has been later attributed to a second author in the
file itself and that in my mind is regrettable as it leads to the type
of complaint that you have, and is a valid justification for your
complaint. However, I'd prefer to see no authorship on a per file basis
and the authorship noted in the Changelog, and the author list in the
Octave manual. The changelog is then the master list of what files have
been touched by whom, and all authors are compensated by their names
listed in the manual.

Think about this a bit further, you made a change to polyvalm.m and if
your authorship was marked in the code the user could see if with "type
polyval.m". I then make a change to kron.cc and have my authorship
marked in the file. However as most users get a binary of Octave they
have no means of knowing that I made a change to kron.cc. Why should a
authorship of an m-file be more visible than a c++ file that is arguably
harder to write and maintain? It is therefore a mistake to assume that
source code change are readable by the standard user or even read at
all. This is why all contributors to Octave must be listed in the manual
that is distributed and readable with all distributions of Octave.

Rolf, I think this is a bit of a non issue, if it makes you happy I see
no reason not to include you're authorship in polyvalm.m, but don't see
the point given what the general policy of citation of contributions has
been recently..

> After B complains about the discarded coauthorship
> notice, Octave's maintainers even try to make him
> believe that everything went correctly because
> his code change was 'not essential' at all.
> This is much more than absurd.
>   
At no point was it claimed that your change was "non essential". What I
stated was that your change was cited in the manner that was consistent
with all other changes that have been made to Octave. Please examine the
change

http://velveeta.che.wisc.edu/cgi-bin/cvsweb.cgi/octave/src/data.cc.diff?r1=1.197;r2=1.198

for an example that I found quickly (there are many many others and
certainly larger ones than this) in the CVS, and then look at the
attribution at the top of data.cc..

> Ten years later I really like to implement an even
> more spohisticated essential change
> (correct handling of defective input matrices)
> into polyvalm (see 'polyvalmh.m'). But I definitely
> refuse to put my code under the statement
> "Author: Tony Richardson" because his
> original code doesn't have anything to do 
> anymore with my proposed polyvalm-candidate.
>   

Essentially what you are now proposing is a complete rewrite of the
polyvalm function.. This is no longer the original authors code, and so
if there is an author attribution it is yours and not the original authors..

> If this wouldn't happen I should probably take some
> quiet time and think a little bit deeper about the
> sense of supporting projects which are maintained in
> such a disrespectful way.
>   

There was no disrepect as far as I can see as there was consistent
treatment of your polyvalm.m patch in 1997 and there was with any other
patch I've seen. That is attribution in the changelog and including in
the contributors list in the Octave manual. You can not assume that the
code can or will be read as I stated above and so the attribution line
is in most cases of less value than the inclusion in the contributors
list in the much more visible manual.

If possible, though it really isn't now, I'd be all for stripping all
individual authorship and copyright from individual file in Octave
(John's included) and state in the manual that the contributors hold
joint copyright to all of Octave, and then this would no longer be an issue.

D.

-- 
David Bateman                                David.Bateman at motorola.com
Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 6 72 01 06 33 (Mob) 
91193 Gif-Sur-Yvette FRANCE                  +33 1 69 35 77 01 (Fax) 

The information contained in this communication has been classified as: 

[x] General Business Information 
[ ] Motorola Internal Use Only 
[ ] Motorola Confidential Proprietary