Multiplication of complex conjugate numbers wrong in Octave 3.0.5 mingw32

[Jaroslav Hajek]

On Mon, May 25, 2009 at 12:18 PM, FélixB
<felix.buehlmann at acousticimplants.com> wrote:
>
>
>
> Jaroslav Hajek-2 wrote:
>>
>> On Sat, May 23, 2009 at 5:40 PM, FélixB
>> <felix.buehlmann at acousticimplants.com> wrote:
>>>
>>>
>>> Benjamin Lindner wrote:
>>>>
>>>> FélixB wrote:
>>>>> Hello,
>>>>>
>>>>> I get an error when multiplying complex conjugate numbers (see example
>>>>> below). The diagonal of the matrix should be real. I have not this
>>>>> error
>>>>> with version 3.0.3 (MSVC).
>>>>>
>>>>> octave:5> a = rand(10000,2)+j*rand(10000,2);
>>>>> octave:6> imag(diag(a'*a))
>>>>> ans =
>>>>>
>>>>>   -2.6396e-014
>>>>>   -2.2185e-014
>>>>>
>>>>> Félix
>>>>>
>>>>
>>>> Octave is not a symbolic math tool, it's a numerical math tool.
>>>> Thus it uses floating-point arithmetic.
>>>> Floating-point arithmetic shows roundoff errors like the ones you
>>>> describe here, it's inherent.
>>>> So it's not an error, this is floating point arithmetic.
>>>>
>>>> benjamin
>>>> _______________________________________________
>>>> Bug-octave mailing list
>>>> Bug-octave at octave.org
>>>> https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave
>>>>
>>>>
>>> Thank's Benjamin for your answer, but I think there is a bug. As said
>>> before, I get the correct answer in version 3.0.3 (i.e no imaginary
>>> part).
>>> See please the example below which give the correct answer with a matrix
>>> of
>>> 10000x1, but a different result when duplicated in a 10000x2 matrix .
>>>
>>> I never seen such an error in previous version.
>>>
>>> Thank's for you help.
>>>
>>> octave:15> a=rand(10000,1)+j*rand(10000,1);
>>> octave:16> imag(a'*a)
>>> ans = 0
>>> octave:17> b=[a,a];
>>> octave:18> imag(b'*b)
>>> ans =
>>>
>>>  -2.4536e-014  -2.4536e-014
>>>  -2.4536e-014  -2.4536e-014
>>> --
>>
>> Matrix multiplication is handled by the BLAS library, so if the two
>> versions come with different BLASes, the difference is understandable.
>> Floating point multiplication is not associative, so reordering
>> operations may break expectations.
>> Example:
>> octave:1> a = complex(rand(4,1),rand(4,1));
>> octave:2> imag(a'*a)
>> ans = 0
>> octave:3> sum([imag(a).*real(a); -real(a).*imag(a)])
>> ans = -1.1102e-16
>> octave:4>
>>
>> Is there any real problem you're having with this?
>>
>>
>> --
>> RNDr. Jaroslav Hajek
>> computing expert & GNU Octave developer
>> Aeronautical Research and Test Institute (VZLU)
>> Prague, Czech Republic
>> url: www.highegg.matfyz.cz
>>
>> _______________________________________________
>> Bug-octave mailing list
>> Bug-octave at octave.org
>> https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave
>>
>>
>
> Hi Jaroslav,
>
> Thank's for you answer. I used before Matlab for 20 years and I never seen
> such a behavior.

Even Matlab computes in floating point - just some things are computed
differently.

> I have now  some .m files which fail because the result is
> complex.

Can you be more specific? What fails?

> This behavior can also be a compatibility issue with some Matlab script.

Possibly, but there's little we can do on Octave's side - this is,
unless I'm missing something, just a difference in the BLAS libraries'
behavior.

cheers

-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz