Multiplication of complex conjugate numbers wrong in Octave 3.0.5 mingw32

[FélixB]

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

[Benjamin Lindner]

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@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[FélixB]

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
[e-mail]
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

[Jaroslav Hajek-2]

On Sat, May 23, 2009 at 5:40 PM, FélixB
<felix.buehlmann@...> 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@...
>> 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@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[FélixB]

Jaroslav Hajek-2 wrote:

On Sat, May 23, 2009 at 5:40 PM, FélixB
<[e-mail]> 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
>> [e-mail]
>> 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
[e-mail]
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. I have now  some .m files which fail because the result is complex.  

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

I don't known if it's easy to change it, but if the answer is yes, I think it will be worth to avoid different results for different platforms. I would also except clean calculation for other operation for example  with the FFT(  the inverse FFT of the FFT of a real signal should be real, ...).

BR

Félix

[Jaroslav Hajek-2]

On Mon, May 25, 2009 at 12:18 PM, FélixB
<felix.buehlmann@...> wrote:

>
>
>
> Jaroslav Hajek-2 wrote:
>>
>> On Sat, May 23, 2009 at 5:40 PM, FélixB
>> <felix.buehlmann@...> 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@...
>>>> 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@...
>> 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

_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave