From bug-octave-request at bevo dot che dot wisc dot edu Thu Sep 11 10:05:22 2003 Subject: Re: NaN-test of octave-2.1.50a-inst.exe on WinXP From: Alois Schloegl To: "John W. Eaton" CC: bug-octave at bevo dot che dot wisc dot edu Date: Thu, 11 Sep 2003 03:22:36 -0500 I was testing the prerelease octave-2.1.50a-inst.exe from octave-forge. And I thought the Octave-mailinglists are also for discussing Octave-Forge. No reason to be offensive - I'm just trying to help. John W. Eaton wrote: >On 10-Sep-2003, Alois Schloegl wrote: > >| I've tested the pre-release of the octave-2.1.50, octave-forge, gnuplot, >| and epstk. >| octave-2.1.50a-inst.exe >| >| on WinXP. I found the following undesired features/bugs(?): >| >| (a) MIN and MAX do not skip NaN's. >| see: >| http://www.octave.org/octave-lists/archive/bug-octave.2003/msg00283.html > >This seems to be fixed in my 2.1.50 version running on Debian: > > octave:1> isnan(sort([3,4,NaN,3,4,NaN]))==[0,0,0,0,1,1] > ans = > > 1 1 1 1 1 1 > > octave:2> sort([3,4,NaN,3,4,NaN]) > ans = > > 3 3 4 4 NaN NaN > >Is there some reason that the check for NaN in sort.cc doesn't work on >Windows XP? If so, then I wouldn't expect Octave's isnan function to >work either, but if that were true, then I don't think many of your >tests would work. Hmm. Can you please investigate why this is not >working for you? > > Its a problem of MIN and MAX in the prerelease of octave-2.1.50-windows. I guess its fine with the latest release for Debian. I do not see any problem with SORT. >| (b) >| WARNING: 0*NaN within matrix multiplication is not commutative >| WARNING: matrix multiplication inf*0 does not result in NaN >| - see: >| http://www.octave.org/octave-lists/archive/bug-octave.2002/msg00293.html >| Replacing BLAS by ATLAS should solve the problem. > >Since Octave offers ATLAS as an option, I don't see how this can be >considered a bug. I have no plans to try to rewrite the reference >version of Lapack when using ATLAS will fix the problem, but if you >can get the necessary fixes into the standard Lapack sources, then >Octave will eventually get them as well. Note that this problem is >also not limited to the reference version of Lapack, since your vendor >version may also have this bug. So, using ATLAS with Octave is >definitely recommended, but given that ATLAS is somewhat difficult to >install, it seems to me that requiring it in order to allow Octave to >build is probably not a good idea. > I'm not saying that core-octave needs any changes. But it would be great if the final release of Octave4Windows could use ATLAS instead of BLAS. >| (c) >| WARNING: matrix division 0/0 does not result in NaN >| WARNING: matrix division 0\0 does not result in NaN >| - do not know where this comes from. > >These warnings come from your tests. Duh! :-) > > Of course, the warnings indicate that zeros(2)/zeros(2) returns an array with zeros instead of NaN's. What I do not know is, whether octave or BLAS/ATLAS, or both need to be changed. >The reason for these warnings is that for things like > > A \ B > >when A is singular (your tests use A and B == zeros (2, 2)), Octave >computes a minimum-norm solution. Matlab only does this when A is not >square and B is a column vector. Other than bug-for-bug >compatibility, why should Octave not compute a minimum-norm solution >when A is square and/or B is not a column vector? > > I guess there is no unique solution (also no minimum-norm solution) to zeros(2)/zeros(2). To be more accurate, an array of zeros does not describe the manifold of solutions in an appropriate way. I'd expect a result of NaNs, like in the scalar division 0/0. Alois ------------------------------------------------------------- Octave is freely available under the terms of the GNU GPL. Octave's home on the web: http://www.octave.org How to fund new projects: http://www.octave.org/funding.html Subscription information: http://www.octave.org/archive.html -------------------------------------------------------------