inconsistent condition numbers from cond, det, inv functions

Rolf Fabian Rolf.Fabian at gmx.de
Fri Feb 8 03:32:17 CST 2008




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?

Assume somebody has implemented the following
fictious erroneous code into Octave in its 'dark ages',
intending to provide a cube function.

## Author: A
function y = cube(x)
     y = x;
endfunction

Later on contributor B remarked that
the cube function is only valid for x==1 and
hopelessly failing for any other input. 
Thus B sends the following path
to the Octave list.

## Authors: A, B
function y = cube(x)
     if (x==1)
         y = x;
     else
         y = x.^3;
     endif
endfunction

Octave maintainers agree that A's code is
really buggy and take the goodies out of B's
patch. Because the number of line changes
is small, they categorize  the change in code
as 'not essential'. Consequently they remove
the coauthorship request from the cube patch
and continue to distribute it still under the single
authorship of A.

This is really curious because the original
cube function is actually nothing more than
a stub and useful only for a single particular
input value.

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.

But that's exactly the way how things evolved
for Octave's polyvalm implementation.

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.

One possible way to get the polyvalm candidate
into Octave might be to contact Tony and ask him
whether he still insists on keeping single copyrigth
on the file code (but I'll not do that).

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.








-----
Rolf Fabian
<r dot fabian at jacobs-university dot de>

-- 
View this message in context: http://www.nabble.com/inconsistent-condition-numbers-from-cond%2C-det%2C-inv-functions-tp15330097p15351732.html
Sent from the Octave - Bugs mailing list archive at Nabble.com.



More information about the Bug-octave mailing list