inconsistent condition numbers from cond, det, inv functions

View: New views
20 Messages — Rating Filter:   Alert me  
< Prev | 1 - 2 | Next >

inconsistent condition numbers from cond, det, inv functions

by Rolf Fabian :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

octave-3.0.0.exe:> version, computer
ans = 3.0.0
i686-pc-msdosmsvc

# a singular matrix
octave-3.0.0.exe:> x=[1,2,3;2,3,4;3,4,5]
x =
   1   2   3
   2   3   4
   3   4   5

octave-3.0.0.exe:> [dum,rc1]=det(x)
dum = 0
rc1 = 2.3130e-018

octave-3.0.0.exe:> [dum,rc2]=inv(x); rc2
rc2 = 2.3130e-018

octave-3.0.0.exe:> rc3 = 1./cond(x)
rc3 = 4.1351e-017

The help parts of 'det' and 'inv' do not explain
whether a different definition of condition
number than 'cond' is used during evaluation.

Thus all results of 'rc' are expected to be
identical, but result from 1/cond(x) differs
unfortunately. Needs to be fixed.

No idea what MatLab returns for the
three cases. Probably somebody has the
time to check it.

Rolf Fabian

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

Re: inconsistent condition numbers from cond, det, inv functions

by Ben Abbott :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


On Feb 7, 2008, at 4:28 AM, Rolf Fabian wrote:

>
> octave-3.0.0.exe:> version, computer
> ans = 3.0.0
> i686-pc-msdosmsvc
>
> # a singular matrix
> octave-3.0.0.exe:> x=[1,2,3;2,3,4;3,4,5]
> x =
>   1   2   3
>   2   3   4
>   3   4   5
>
> octave-3.0.0.exe:> [dum,rc1]=det(x)
> dum = 0
> rc1 = 2.3130e-018
>
> octave-3.0.0.exe:> [dum,rc2]=inv(x); rc2
> rc2 = 2.3130e-018
>
> octave-3.0.0.exe:> rc3 = 1./cond(x)
> rc3 = 4.1351e-017
>
> The help parts of 'det' and 'inv' do not explain
> whether a different definition of condition
> number than 'cond' is used during evaluation.
>
> Thus all results of 'rc' are expected to be
> identical, but result from 1/cond(x) differs
> unfortunately. Needs to be fixed.
>
> No idea what MatLab returns for the
> three cases. Probably somebody has the
> time to check it.

Matlab's det() and inv() only supply one output.

 >> x=[1,2,3;2,3,4;3,4,5]

x =

      1     2     3
      2     3     4
      3     4     5

 >>  [dum,rc1]=det(x)
??? Error using ==> det
Too many output arguments.

 >> help det
  DET    Determinant.
     DET(X) is the determinant of the square matrix X.

     Use COND instead of DET to test for matrix singularity.

     See also cond.

     Reference page in Help browser
        doc det

 >> [dum,rc2]=inv(x); rc2
??? Error using ==> inv
Too many output arguments.

 >> help inv
  INV    Matrix inverse.
     INV(X) is the inverse of the square matrix X.
     A warning message is printed if X is badly scaled or
     nearly singular.

     See also slash, pinv, cond, condest, lsqnonneg, lscov.

     Overloaded methods:
        scmapinv/inv
        scmap/inv
        moebius/inv
        composite/inv

     Reference page in Help browser
        doc inv

 >>  rc3 = 1./cond(x)

rc3 =

    3.1013e-17

My octave gives the same answer as yours.

octave:48> x=[1,2,3;2,3,4;3,4,5]
x =

    1   2   3
    2   3   4
    3   4   5

octave:49> 1/cond(x)
ans =  4.1351e-17
octave:50>

Ben
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave

Re: inconsistent condition numbers from cond, det, inv functions

by Rolf Fabian :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

My personal condh.m function accepts a 2nd argument
p = 1, 2, 'fro', 'inf', Inf, ...
accounting for the different matrix norms provided by 'norm.m'
which is used in evaluation of condition number.

octave-3.0.0.exe:> 1./condh(x,1)
ans = 2.3130e-018
octave-3.0.0.exe:> 1./condh(x,2)
ans = 4.1351e-017
octave-3.0.0.exe:44> 1/condh(x,'fro')
ans = 3.8375e-018
octave-3.0.0.exe:> 1./condh(x,Inf)
ans = 2.3130e-018
octave-3.0.0.exe:> 1./condh(x,'inf')
ans = 2.3130e-018

We conclude that Octave's
[dum,rc] = det()  and  [dum,rc] = inv()
both return rc using either 1-norm or infinity norm,
whereas cond() defines rc via 2-norm.
Furthermore MatLabs result seems
to be unexplainable.

Unfortunately example matrix x was choosen to be symmetric.
This wasn't a good choice  because Inf- and 1-norms are
idential in this case.

Using instead the asymmetric matrix
octave-3.0.0.exe:> y=[7,2,3;1,3,4;6,4,5]
y =
   7   2   3
   1   3   4
   6   4   5

octave-3.0.0.exe:> 1/condh(y,1)
ans =  0.017460
octave-3.0.0.exe:> 1/condh(y,2)
ans =  0.019597
octave-3.0.0.exe:> 1/condh(y,'fro')
ans =  0.018714
octave-3.0.0.exe:> 1/condh(y,'inf')
ans =  0.012022
octave-3.0.0.exe:> 1/condh(y,Inf)
ans =  0.012022

octave-3.0.0.exe:37> [dum,rc1]=det(y)
rc1 =  0.017460
octave-3.0.0.exe:38> [dum,rc2]=inv(y)
rc2 =  0.017460
octave-3.0.0.exe:39> rc3 = 1/cond(y)
rc3 =  0.019597

allows to differentiate between 1- and Inf -norm.

Ben, what' s the result for 1./cond(y) ?
Does Matlabs cond() have a similar argument 'p' too?

Summary and Conclusion:
(1) Octave's det() and inv() return condition number rc defined via 1-norm,
(2) whereas cond() defines condition number via 2-norm.
(3) MatLabs result is not understandable in the framework of
     different modes of norms. Maybe they mix norm-modes ?
     ( 'norm' is called 2 times by cond ). Obviously further studies
     are required.

Suggestion
(1) and (2) should be aligned, preferentially using 1-norm, Inf-norm or Fro-norm
but definitely not 2-norm, because this requires svd and may leads to
performance deficits for large mats.

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

Re: inconsistent condition numbers from cond, det, inv functions

by Ben Abbott :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Feb 7, 2008, at 7:00 AM, Rolf Fabian wrote:

> [...]
>
> Unfortunately example matrix x was choosen to be symmetric.
> This wasn't a good choice  because Inf- and 1-norms are
> idential in this case.
>
> Using instead the asymmetric matrix
> octave-3.0.0.exe:> y=[7,2,3;1,3,4;6,4,5]
> y =
>   7   2   3
>   1   3   4
>   6   4   5
>
> octave-3.0.0.exe:> 1/condh(y,1)
> ans =  0.017460
> octave-3.0.0.exe:> 1/condh(y,2)
> ans =  0.019597
> octave-3.0.0.exe:> 1/condh(y,'fro')
> ans =  0.018714
> octave-3.0.0.exe:> 1/condh(y,'inf')
> ans =  0.012022
> octave-3.0.0.exe:> 1/condh(y,Inf)
> ans =  0.012022
>
> octave-3.0.0.exe:37> [dum,rc1]=det(y)
> rc1 =  0.017460
> octave-3.0.0.exe:38> [dum,rc2]=inv(y)
> rc2 =  0.017460
> octave-3.0.0.exe:39> rc3 = 1/cond(y)
> rc3 =  0.019597
>
> allows to differentiate between 1- and Inf -norm.
>
> Ben, what' s the result for 1./cond(y) ?
> Does Matlabs cond() have a similar argument 'p' too?

Yes!

 >> y=[7,2,3;1,3,4;6,4,5]

y =

      7     2     3
      1     3     4
      6     4     5

 >> 1/cond(y)

ans =

     0.0196

 >> help cond
  COND   Condition number with respect to inversion.
     COND(X) returns the 2-norm condition number (the ratio of the
     largest singular value of X to the smallest).  Large condition
     numbers indicate a nearly singular matrix.

     COND(X,P) returns the condition number of X in P-norm:

        NORM(X,P) * NORM(INV(X),P).

     where P = 1, 2, inf, or 'fro'.

     Class support for input X:
        float: double, single

     See also rcond, condest, condeig, norm, normest.

     Reference page in Help browser
        doc cond

 >> 1/cond(y,1)

ans =

     0.0175

 >> 1/cond(y,2)

ans =

     0.0196

 >> 1/cond(y,inf)

ans =

     0.0120

 >> 1/cond(y,'fro')

ans =

     0.0187

Ben
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave

Re: inconsistent condition numbers from cond, det, inv functions

by Rolf Fabian :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


Ben Abbott wrote:
On Feb 7, 2008, at 7:00 AM, Rolf Fabian wrote:

> Ben, what' s the result for 1./cond(y) ?
> Does Matlabs cond() have a similar argument 'p' too?

Yes!

Ben
Thanks Ben. From your results I conclude that MatLab
is actually doing something very similar than I did for my
condh-function. I personally have good reasons not to
send any code any more to any Octave list. So, if you like,
make jwe happy by sending him a patched version of 'cond.m'
implementing a 2nd argument p which defines the mode of
(both) calls to 'norm.m'. In order to conform to ML, the default
mode should be p=2 as long as input matrix is regular (non-singular).

I've no idea why the ML-result for the 1st (singular) testmatrix x
from cond() differs from the 2-norm algorithm. This needs further
test with ML using singular input to cond(), but ML is not available
for me.

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

Re: inconsistent condition numbers from cond, det, inv functions

by David Bateman :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Rolf Fabian wrote:
> Thanks Ben. From your results I conclude that MatLab
> is actually doing something very similar than I did for my
> condh-function. I personally have good reasons not to
> send any code any more to any Octave list.
Ralf,

I believe you are referring to the message

http://www.nabble.com/polyvalm-problems-for-defective-matrix-input-to15183200.html#a15269047

I can tell you I've made some major changes to many Octave files without
changing the attribution of the copyright/authorship at all in the files
themselves. Look through the changelogs and compare against the files if
you don't believe, me.. I hope to explain to you why I'm comfortable
with this position, and not surprised that this happened in your case.

However, you are essentially making a claim of plagarism and all such
claims need to be taken serious. I was not involved at all in the Octave
project in 1997 and so I believe I can be fairly neutral analysis of the
situation. The change you are referring to can be seen in the Octave
version control system at

http://velveeta.che.wisc.edu/cgi-bin/cvsweb.cgi/octave/scripts/polynomial/polyvalm.m.diff?r1=1.11;r2=1.12

and essentially comes down to the change

--- octave/scripts/polynomial/polyvalm.m 1997/03/27 16:19:15 1.11
+++ octave/scripts/polynomial/polyvalm.m 1997/09/19 22:07:32 1.12
@@ -61,6 +61,10 @@ function y = polyvalm (c, x)

[v, d] = eig (x);

- y = v * diag (polyval (c, diag (d))) * v';
+ if (is_symmetric (x))
+ y = v * diag (polyval (c, diag (d))) * v';
+ else
+ y = v * (diag (polyval (c, diag (d))) / v);
+ endif

endfunction

with the rest being layout/whitespace changes. Yes the attribution in
the file that you included in your patch is missing, so on face value
you are right.

This might be justified by the size of the patch being small (-1 line
and +5 lines of essential code), however I don't take that position. A
change is a change and appropriate citation is necessary. However what
is appropriate citation for a software project? We could include every
person that ever touched a file in a list of authors of all files in
octave. However, as many people have touch many files with Octave that
is unwieldy. In fact there are many projects where individual files have
no authorship attributions. This does not mean that the citation of the
author is not performed. Its just done differently.

Unfortunately, for reasons I don't quite understand, Octave has many
files with copyright assigned to individual authors and this has lead
people contributing to Octave to also include author lines. As we can't
change that now in any sane way, newly contributed files have typically
had the authorship/copyright assigned to the original author, and people
who modify the file aren't cited in the file themselves....

So where are they cited, and in particular where is your contribution of
the Aug 19, 1997 cited? Looking through the file scripts/Changelog
you'll find the following entry

Thu Aug 28 15:31:20 1997  Rolf Fabian  <fabian@...>

        * polynomial/polyvalm.m: Don't assume orthogonal eigenvectors for
        nonsymmetric matrices.

        * general/tril.m: Fix usage message.

        * polynomial/polyvalm.m: Fix error messages.
        * polynomial/polyderiv.m: Likewise.
        * polynomial/polyval.m: Likewise.

which is the citation of your authorship of the modifications, what was
changed and the date the change was applied to Octave itself. Also
you'll find in

http://www.gnu.org/software/octave/doc/interpreter/Acknowledgements.html#Acknowledgements

your name listed as a contributor to Octave itself, as are all people
who have contributed a modification to Octave. This is the way Octave
has handled all contributions that I've seen. So I believe your implied
claim to plagarism is unfounded. The move to mercurial will help here if
authors contribute their patches as mercurial changesets. In that case
the version control log will also contain the name of the person
responsible for the change.

I hope I have addressed your complaint and that you'll reconsider your
position..

Regards
David

--
David Bateman                                David.Bateman@...
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

_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave

Re: inconsistent condition numbers from cond, det, inv functions

by Rolf Fabian :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Forgot to mention my conclusions about the subject title:

Because ML seems to use (2 times) 2-norm for cond() by default
(if input is regular) as also does Octave, we shouldn't change
the cond() default in order to conform to ML. Unfortunately
this default uses the slowest flavour of norm (even two times).

But as soon as cond() accepts also a 2nd (p) input, everbody is
free to speed it up for larger matrices by using p=1 or p=Inf or 'Inf'
or even 'fro'.

Reciprocal condition number rcond from 2nd output of
det() and inv() are obviously determined via 1-norm which is
much faster than 2-norm. One might discuss whether 'inf' or 'fro'
might be a better choice than 1-norm. But this is off-topic at the
moment. Somebody should fix help parts of  det() and
inv() by cleary specifying that 1-norm reciprocal condition number
is used in order to prevent further confusion.

IMHO the help part of 'cond' also needs to be fixed because
usually mathematicians do not use 'two-norm' while
refering to '2-norm'.

Rolf Fabian




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

Re: inconsistent condition numbers from cond, det, inv functions

by Ben Abbott :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Thursday, February 07, 2008, at 08:09AM, "Rolf Fabian" <Rolf.Fabian@...> wrote:

>
>Ben Abbott wrote:
>>
>> On Feb 7, 2008, at 7:00 AM, Rolf Fabian wrote:
>>
>>> Ben, what' s the result for 1./cond(y) ?
>>> Does Matlabs cond() have a similar argument 'p' too?
>>
>> Yes!
>>
>> Ben
>
>Thanks Ben. From your results I conclude that MatLab
>is actually doing something very similar than I did for my
>condh-function. I personally have good reasons not to
>send any code any more to any Octave list. So, if you like,
>make jwe happy by sending him a patched version of 'cond.m'
>implementing a 2nd argument p which defines the mode of
>(both) calls to 'norm.m'. In order to conform to ML, the default
>mode should be p=2 as long as input matrix is regular (non-singular).
>
>I've no idea why the ML-result for the 1st (singular) testmatrix x
>from cond() differs from the 2-norm algorithm. This needs further
>test with ML using singular input to cond(), but ML is not available
>for me.
>
>Rolf Fabian

Rolf,

I happy to help out. Can you email me the modified files?

Ben


_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave

Re: inconsistent condition numbers from cond, det, inv functions

by John W. Eaton :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On  7-Feb-2008, David Bateman wrote:

| Unfortunately, for reasons I don't quite understand, Octave has many
| files with copyright assigned to individual authors

I agree with all that you've posted, but I should probably explain
this point.

Up until about 1996, I asked people who contributed non-trivial
changes to either disclaim copyright or assign copyright to me, same
as the FSF requires for projects for which the FSF holds the
copyright.  The only difference being that I was the sole copyright
holder instead of the FSF.  Then I stopped doing it, primarily because
it is a slow process, especially given that Octave contributors are
widely distributed geographically, and also because I noticed that
other projects (notably the Linux kernel) were not asking for signed
disclaimers/assignments either, and they were getting along just
fine without the extra paperwork.

Once I stopped asking for disclaimers/assignments, I couldn't very
claim copyright on files I didn't write, so I decided to leave the
primary author as the copyright holder for new files.

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.

jwe
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave

Re: inconsistent condition numbers from cond, det, inv functions

by Rolf Fabian :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


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>

Re: inconsistent condition numbers from cond, det, inv functions

by Rolf Fabian :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

In my recent upload the quoted text was erroneously attributed
to David Bateman, but actually the citation refers to jwe :

John W. Eaton 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.
Rolf Fabian
<r dot fabian at jacobs-university dot de>

Re: inconsistent condition numbers from cond, det, inv functions

by David Bateman :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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@...
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

_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave

Re: inconsistent condition numbers from cond, det, inv functions

by John W. Eaton :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On  8-Feb-2008, David Bateman wrote:

| 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.

I'm not opposed to a change like this.  Believe it or not, it has
occurred to me that as we have more people making significant and
sizeable contributions, it makes less sense for the startup message to
have my name only.  Recently I added "and others" though that still
doesn't seem quite right.

I don't see that there should be a problem to changing the copyright
to be inclusive of all contributors (no contributor loses a copyright
claim on any file where they were originally listed, though now others
also have a claim).  In any case, given that the code is distrubted
under the temrs of GPL and written by many people, it seems to me that
we essentially have this situation now anyway.  For example, my
understanding is we can't change the license or even add an exception
clause in addition to the terms of the GPL without agreement from all
copyright holders.  Of course, I'm not a lawyer, so this could all be
complete nonsense from a legal point of view.

One practical problem would be how to legally state that all the
contributors hold the copyright.  I know that the R group made a
change like this at some point, and R now starts with a message that
says

  Copyright (C) YYYY The R Foundation for Statistical Computing

As I understand it, The R Foundation for Statistical Computing is an
actual legal entity of some sort, not just a name they made up.  You
can find their charter here: http://www.r-project.org/foundation .

jwe
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave

Re: inconsistent condition numbers from cond, det, inv functions

by John W. Eaton :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

One thing I should also add is that I started putting Author tags in
.m files for the same reasons I believe they are in Emacs Lisp files,
and that's so that when there is a bug it is easy to send mail to the
author of the file to ask for help in fixing the bug.  The Emacs
maintainers actually do use these tags in their files, but that's not
the way things typically work for Octave.  Also, the author
information is usually available somewhere else (ChangeLog or revision
control system) so having the tags in the .m files themselves is
probably not that important now.

jwe
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave

Re: inconsistent condition numbers from cond, det, inv functions

by Ben Abbott :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


On Feb 8, 2008, at 6:13 AM, John W. Eaton wrote:

> On  8-Feb-2008, David Bateman wrote:
>
> | 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.
>
> I'm not opposed to a change like this.  Believe it or not, it has
> occurred to me that as we have more people making significant and
> sizeable contributions, it makes less sense for the startup message to
> have my name only.  Recently I added "and others" though that still
> doesn't seem quite right.

fwiw, I am in complete support for such a change.

> I don't see that there should be a problem to changing the copyright
> to be inclusive of all contributors (no contributor loses a copyright
> claim on any file where they were originally listed, though now others
> also have a claim).  In any case, given that the code is distrubted
> under the temrs of GPL and written by many people, it seems to me that
> we essentially have this situation now anyway.  For example, my
> understanding is we can't change the license or even add an exception
> clause in addition to the terms of the GPL without agreement from all
> copyright holders.  Of course, I'm not a lawyer, so this could all be
> complete nonsense from a legal point of view.
>
> One practical problem would be how to legally state that all the
> contributors hold the copyright.  I know that the R group made a
> change like this at some point, and R now starts with a message that
> says
>
>  Copyright (C) YYYY The R Foundation for Statistical Computing
>
> As I understand it, The R Foundation for Statistical Computing is an
> actual legal entity of some sort, not just a name they made up.  You
> can find their charter here: http://www.r-project.org/foundation .


There have been many functions "adapted" (for octave-forge etc) over  
the years. I would presume there would be a legal problem with  
stripping the individual's copyright and adding a collective copyright  
(?)

Ben

_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave

Re: inconsistent condition numbers from cond, det, inv functions

by David Bateman :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Ben Abbott wrote:
>
> There have been many functions "adapted" (for octave-forge etc) over
> the years. I would presume there would be a legal problem with
> stripping the individual's copyright and adding a collective copyright
> (?)

Why? The original author looses nothing and gains copyright to the whole
of Octave. Why is this an issue?

D.

--
David Bateman                                David.Bateman@...
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

_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave

Re: inconsistent condition numbers from cond, det, inv functions

by Ben Abbott :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


On Feb 8, 2008, at 6:21 AM, John W. Eaton wrote:

> One thing I should also add is that I started putting Author tags in
> .m files for the same reasons I believe they are in Emacs Lisp files,
> and that's so that when there is a bug it is easy to send mail to the
> author of the file to ask for help in fixing the bug.  The Emacs
> maintainers actually do use these tags in their files, but that's not
> the way things typically work for Octave.  Also, the author
> information is usually available somewhere else (ChangeLog or revision
> control system) so having the tags in the .m files themselves is
> probably not that important now.
>
> jwe

John,

I've used the authorship lines in the past to get help fixing bugs/
features. I'd like to preserver that capability. Any reason why  
additional names can't be included, along with a change from "Author"  
to "Contributor(s)" or such?

Ben

_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave

Re: inconsistent condition numbers from cond, det, inv functions

by Ben Abbott :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


On Feb 8, 2008, at 6:35 AM, David Bateman wrote:

> Ben Abbott wrote:
>>
>> There have been many functions "adapted" (for octave-forge etc) over
>> the years. I would presume there would be a legal problem with
>> stripping the individual's copyright and adding a collective  
>> copyright
>> (?)
>
> Why? The original author looses nothing and gains copyright to the  
> whole
> of Octave. Why is this an issue?
>
> D.

I'm not saying there is a legal problem, and it is not a problem for  
me. However, there may be some who are endeared to their contributions  
and may debate the point.

Did R have a similar problem?

Ben
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave

PATCH for cond()

by Ben Abbott :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

I've attached a patch respecting Rolf's change to cond().

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

        * linear-algebra/cond.m: Changed to respect a second argument used to
        optionally specify 1-norm, inf-norm, or frobenius-norm.
 

--- /Users/bpabbott/Development/cvs/octave/scripts/linear-algebra/cond.m 2008-01-22 16:52:25.000000000 -0500
+++ cond.m 2008-02-08 09:59:38.000000000 -0500
@@ -1,5 +1,5 @@
 ## Copyright (C) 1993, 1994, 1995, 1996, 1997, 1999, 2000, 2003, 2004,
-##               2005, 2006, 2007 John W. Eaton
+##               2005, 2006, 2007, 2008 John W. Eaton
 ##
 ## This file is part of Octave.
 ##
@@ -18,37 +18,49 @@
 ## <http://www.gnu.org/licenses/>.
 
 ## -*- texinfo -*-
-## @deftypefn {Function File} {} cond (@var{a})
-## Compute the (two-norm) condition number of a matrix. @code{cond (a)} is
-## defined as @code{norm (a) * norm (inv (a))}, and is computed via a
-## singular value decomposition.
-## @seealso{norm, svd, rank}
+## @deftypefn {Function File} {} cond (@var{a},@var{p})
+## Compute the @var{p}-norm condition number of a matrix. @code{cond (@var{a})} is
+## defined as @code{norm (@var{a}, @var{p}) * norm (inv (@var{a}), @var{p})}.
+## By default @code{@var{p}=2} is used which implies a (relatively slow)
+## singular value decomposition. Other possible selections are
+## @code{@var{p}= 1, Inf, inf, 'Inf', 'fro'} which are generally faster.
+## @seealso{norm, inv, det, svd, rank}
 ## @end deftypefn
 
 ## Author: jwe
 
-function retval = cond (a)
+function retval = cond (a,p)
 
-  if (nargin == 1)
+  if (nargin && nargin < 3)
     if (ndims (a) > 2)
       error ("cond: Only valid on 2-D objects")
     endif
 
-    [nr, nc] = size (a);
-    if (nr == 0 || nc == 0)
-      retval = 0.0;
+    if (nargin <2)
+      p = 2;
     endif
-    if (any (any (isinf (a) | isnan (a))))
-      error ("cond: argument must not contain Inf or NaN values");
+
+    if (!isstr(p) && p == 2)
+       [nr, nc] = size (a);
+       if (nr == 0 || nc == 0)
+           retval = 0.0;
+           return;
+       endif
+
+       if (any (any (isinf (a) | isnan (a))))
+          error ("cond: argument must not contain Inf or NaN values");
+       else
+          sigma   = svd (a);
+          sigma_1 = sigma(1);
+          sigma_n = sigma(end);
+          if (sigma_1 == 0 || sigma_n == 0)
+             retval = Inf;
+          else
+             retval = sigma_1 / sigma_n;
+          endif
+       endif
     else
-      sigma = svd (a);
-      sigma_1 = sigma(1);
-      sigma_n = sigma(length (sigma));
-      if (sigma_1 == 0 || sigma_n == 0)
-        retval = Inf;
-      else
-        retval = sigma_1 / sigma_n;
-      endif
+       retval = norm (a, p) * norm (inv (a), p);  
     endif
   else
     print_usage ();
@@ -56,11 +68,20 @@
 
 endfunction
 
-%!assert(abs (cond ([1, 2; 2, 1]) - 3) < sqrt (eps));
+%!test
+%! y= [7, 2, 3; 1, 3, 4; 6, 4, 5];
+%! tol = 1e-6;
+%! type = {1, 2, 'fro', 'inf', inf};
+%! for n = 1:numel(type)
+%!   rcondition(n) = 1 / cond (y, type{n});
+%! endfor
+%! assert (rcondition, [0.017460, 0.019597, 0.018714, 0.012022, 0.012022], tol);
+
+%!assert (abs (cond ([1, 2; 2, 1]) - 3) < sqrt (eps));
 
-%!assert(cond ([1, 2, 3; 4, 5, 6; 7, 8, 9]) > 1.0e+16);
+%!assert (cond ([1, 2, 3; 4, 5, 6; 7, 8, 9]) > 1.0e+16);
 
 %!error cond ();
 
-%!error cond (1, 2);
+%!error cond (1, 2, 3);
 



_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave

cond.diff (3K) Download Attachment

Re: inconsistent condition numbers from cond, det, inv functions

by David Bateman :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Ben Abbott wrote:

>
> John,
>
> I've used the authorship lines in the past to get help fixing
> bugs/features. I'd like to preserver that capability. Any reason why
> additional names can't be included, along with a change from "Author"
> to "Contributor(s)" or such?
>
> Ben
>
>
If we decide to get rid of attribution on a per file basis, then the
Author lines can't stay in the file in any case. However, if we respect
the authors name with the mercurial changesets, then the same ability
will be maintained through mercurial itself.. I'd prefer to have no
attribution in the files themselves..

Do this mean we need an "Octave Foundation" that represents all
contributors that holds the copyright? Probably, but IANAL..

D.

--
David Bateman                                David.Bateman@...
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

_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave
< Prev | 1 - 2 | Next >