On 25-Aug-2008, Benjamin Lindner wrote:
| 3)
| >>>>> processing
| d:\files\admin\octaveforge_svn\trunk\octave-forge\admin\Windows\mingw32\octave\octave-3.0.2\scripts/strings\mat2str.m
| ***** assert (mat2str ([-1/3 +i/7; 1/3 -i/7], [4 2]),
| "[-0.3333+0i,0+0.14i;0.3333+0i,-0-0.14i]")
| !!!!! test failed
| error: assert (mat2str ([-1 / 3, +i / 7; 1 / 3, -i / 7], [4,
| 2]),"[-0.3333+0i,0+0.14i;0.3333+0i,-0-0.14i]") expected
| [-0.3333+0i,0+0.14i;0.3333+0i,-0-0.14i]
| but got
| [-0.3333+0i,0+0.14i;0.3333+0i,0-0.14i]
|
| Now this one, I don't consider a bug, rather a stange test.
| Why would I expect that -i has a real part of -0 (mind the sign!)?
| Doing
| real(-i)
| yields
| ans = 0
| as expected, and
| sprintf("%f", real(-i))
| yields
| 0.00000
| also as expected.
On my system:
octave:1> -i
ans = -0 - 1i
octave:2> real (-i)
ans = -0
Remember that Octave does not have any pure imaginary data type. So i
is stored as (0,1). Negating that will result in (-0,-1) unless we
have a special case. Is that justified? I'm not sure. If you want
to create (0,-1), then you have to write complex(0,-1).
jwe