|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 | Next > |
|
|
inconsistent condition numbers from cond, det, inv functionsoctave-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 functionsOn 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 functionsMy 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 functionsOn 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 functionsThanks 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 functionsRolf 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 functionsForgot 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 functionsOn 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 functionsOn 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 functionsIn 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 functionsIn my recent upload the quoted text was erroneously attributed
to David Bateman, but actually the citation refers to jwe :
Rolf Fabian
<r dot fabian at jacobs-university dot de> |
|
|
Re: inconsistent condition numbers from cond, det, inv functionsRolf 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? > 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 functionsOn 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 functionsOne 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 functionsOn 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 functionsBen 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 functionsOn 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 functionsOn 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()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 |
|
|
Re: inconsistent condition numbers from cond, det, inv functionsBen 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 > > 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 > |
| Free embeddable forum powered by Nabble | Forum Help |