From bug-request at octave dot org Mon Nov 14 09:52:48 2005 Subject: Unpredictable behavior of -Inf * 0 From: "John W. Eaton" To: "Michael O'Brien" Cc: bug at octave dot org Date: Mon, 14 Nov 2005 10:52:39 -0500 On 13-Nov-2005, Michael O'Brien wrote: | Bug report for Octave 2.1.71 configured for i686-pc-linux-gnu | | Description: | ----------- | | Having unpredictable behavior with product of -Inf*0. | | If done as scalar multiplication | (-Inf*0)=NaN (should be the result, according to IEEE754) | | | One day, when I did a vector multiplication similar to the following, I | got something like | log([0,1,2]')*[0,1,2,3] | ans = | | NaN -Inf -Inf -Inf | 0.00000 0.00000 0.00000 0.00000 | 0.00000 0.69315 1.38629 2.07944 | | Which is correct according to IEEE754, although not what I wanted | (I wanted a zero in the (1,1) spot. This told me I had a bug in my algoritm | and needed to approach it from a different way. | | I rebooted a couple days later to take another crack at the algorithm, | but THIS time the behavior was quite different. | | log([0,1,2]')*[0,1,2,3] | ans = | | 0.00000 -Inf -Inf -Inf | 0.00000 0.00000 0.00000 0.00000 | 0.00000 0.69315 1.38629 2.07944 | | | And note the difference between | | [0;1;2;3]*[-Inf,-2,-1,0] | ans = | | NaN 0 0 0 | -Inf -2 -1 0 | -Inf -4 -2 0 | -Inf -6 -3 0 | | and (from the same octave session) | | [-Inf;-2;-1;0]*[0,1,2,3] | ans = | | 0 -Inf -Inf -Inf | 0 -2 -4 -6 | 0 -1 -2 -3 | 0 0 0 0 | | | Scalars behave according to IEEE754. | | log([0]')*[0,1,2,3] | ans = | | NaN -Inf -Inf -Inf | | | | Repeat-By: | --------- | | I cannot explain why the matrix multiplication yeilded NaN one day and 0 the | other, or how to repeat it. You can, however, see the inconsistencies | within a single octave session according to the examples above. | BLAS_LIBS: It looks like you are using the reference BLAS that is distributed with Octave. As I recall, that version has some questionable optimizations when multiplying by zero. Instead of doing the multiplication, it simply fills with zero. Maybe that could cause the result you see. You could diagnose the problem by looking at the source for dgemm.f to see what it is doing. As far as I know, ATLAS simply does the operations, so it will return the right (in the IEEE754 sense) thing for 0*Inf. The scalar times a matrix operation does not use the BLAS. jwe ------------------------------------------------------------- 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 -------------------------------------------------------------