bugGNU Octave - Bugs: bug #67186, cross returns incorrect result for...

 
 

bug #67186: cross returns incorrect result for complex inputs?

Submitter:  A.R. Burgers <arb>
Submitted:  Tue 03 Jun 2025 11:11:23 AM UTC
   
 
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Documentation
Status:  In Progress Assigned to:  None
Originator Name:  Open/Closed:  * Open
Release:  * dev Release: 
Operating System:  * Any Fixed Release:  None
Planned Release:  10.3.0 (current stable)
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 06 Jun 2025 05:30:39 PM UTC, comment #12: 

Thanks for the proposed wording.

I was thinking that the formulation with the sum of the element-wise product could be written more nicely as an inner product after using the transpose-operator. But then I realized that cross also works for column vectors and I added `(:)` to give the example a consistent orientation. So, not sure if this is any better now.
Also, `cross` works with matrix input. So, I added a "for vector input" to the sentence with that example. (The original with `sum` wasn't correct in general either - depending on which dimension was the first with three elements.)

I also adjusted to Octave's coding conventions (e.g., line breaks before 80 characters, spaces after function names and around operators, ...).

Does the attached modified version of your patch look good to you?

Maybe, it would also make sense to add a BIST that checks the orthogonality of a set of complex vectors with the current convention? That might make it clearer in the future that the current convention is used on purpose. Your example from comment #0 could probably be used for that.

What do you think?

(file #57279)

Markus Mützel <mmuetzel>
Group administrator
Fri 06 Jun 2025 10:21:08 AM UTC, comment #11: 

see attached cset for a proposal to expand the comment for the complex case

(file #57277)

A.R. Burgers <arb>
Wed 04 Jun 2025 02:21:57 PM UTC, comment #10: 

@arb: Please DO NOT examine Matlab internals or base any Octave contributions on MathWorks code that you may have access to view.

John W. Eaton <jwe>
Group administrator
Wed 04 Jun 2025 12:06:09 PM UTC, comment #9: 

Yep, that's fair to back out the change.

Also, for the doc note, the conj is being introduced by dot itself as documented in its help text. Calling "sum (c .* a)" gives zero correctly.

Arun Giridhar <arungiridhar>
Group Member
Wed 04 Jun 2025 10:47:41 AM UTC, comment #8: 


> we could add a heads-up in the complex case, if the user wants a result c=cross(a,b) that satisfies orthogonality dot(a,c)=dot(b,c)=0, user should conjugate c.



That sounds reasonable.
Would you like to suggest a patch with that additional explanation in the docstring of the `cross` function?

Markus Mützel <mmuetzel>
Group administrator
Wed 04 Jun 2025 10:19:31 AM UTC, comment #7: 

Yes, the change should be reverted.

TMW considers the introduction of conjugation to be a bug, and I just happened to stumble on one of the 3 affected releases ...

we could add a heads-up in the complex case, if the user wants a result c=cross(a,b) that satisfies orthogonality dot(a,c)=dot(b,c)=0, user should conjugate c.

A.R. Burgers <arb>
Wed 04 Jun 2025 09:38:35 AM UTC, comment #6: 

In Matlab R2025a:

>> a = [1 + i, 1-i, 2];
>> b = [1 - i, 2-i, 1 + i];
>> c=cross(a,b)

c =

  -2.0000 + 2.0000i   2.0000 - 4.0000i   3.0000 + 3.0000i

>> dot(c,a)

ans =

  12.0000 - 8.0000i

>> dot(c,b)

ans =

  10.0000 + 6.0000i

>>


Imho, the recent change for this report should be reverted.

In general, I'm no fan of changing the behavior between dot-releases. Especially, if it is just a matter of convention. So, if at all, this should have gone on the default branch.

Done here:
https://hg.savannah.gnu.org/hgweb/octave/rev/25fc4bdf6e77

Markus Mützel <mmuetzel>
Group administrator
Wed 04 Jun 2025 08:02:33 AM UTC, comment #5: 

From the bugreport https://nl.mathworks.com/support/bugreports/details/2088279

  • the conjugation was introduced in R2019B, and apparently was in effect only for R2019B and R2019B updates 1 and 2.
  • The recommendation is to use R2019B update 3 or later, which reverted to not conjugating the result.


A.R. Burgers <arb>
Wed 04 Jun 2025 07:27:29 AM UTC, comment #4: 

I verified the behavior in matlab online, which is R2024b.

There the result is not conjugated, and the dot products do not evaluate to 0 ...

I double checked, also inspecting the m-code with type command, and R2019B does conjugate.

2024B transcript:


>> a = [1 + i, 1-i, 2];
>> b = [1 - i, 2-i, 1 + i];
>> c=cross(a,b)
c =
  -2.0000 + 2.0000i   2.0000 - 4.0000i   3.0000 + 3.0000i
>> dot(c,a)
ans =
  12.0000 - 8.0000i
>> dot(c,b)
ans =
  10.0000 + 6.0000i
>> version
ans =
    '24.2.0.2871072 (R2024b) Update 5'


A.R. Burgers <arb>
Tue 03 Jun 2025 04:25:09 PM UTC, comment #3: 

Thanks for finding that change in Matlab. Since the change is over five years old at this point, I went ahead and pushed the change in Octave to the stable branch as a compatibility fix. It should show up in Octave 10.3.0.

Marking as ready for test.

(I didn't update the planned release / fixed release fields because they still show 10.2.0).

Arun Giridhar <arungiridhar>
Group Member
Tue 03 Jun 2025 02:49:02 PM UTC, comment #2: 

actually the conjugation seems to have been introduced in matlab relatively recently.

See https://nl.mathworks.com/matlabcentral/answers/491760-change-for-cross-function-from-r2019a-to-r2019b

See https://nl.mathworks.com/support/bugreports/2088279 (requires a sign-in)

A.R. Burgers <arb>
Tue 03 Jun 2025 01:30:32 PM UTC, comment #1: 

Extension of vector products to complex numbers has always been controversial. There are multiple mutually incompatible definitions of that operation. Two common ones are:

  • If a and b are both complex numbers in the complex plane, then axb is perpendicular to both, hence leaves the plane entirely. There are connections to quaternions and octonions from this definition.


  • Restricting it to the plane, some authors define axb = (conj(a) b - a conj(b)) / 2, which works out to be inside the plane (purely imaginary if I recall correctly), but then the dot product of that result with either a or b is not zero, since it cannot be perpendicular to both while still being in the plane.


I am inclined to classify this as a Matlab compatibility bug instead of incorrect result, and conjugate Octave's output to agree with Matlab.

Arun Giridhar <arungiridhar>
Group Member
Tue 03 Jun 2025 11:11:23 AM UTC, original submission:  

at the risk of making a fool of myself, as it seems unlikely there is such a pretty fundamental mistake:

It seems the cross function should conjugate the result in case of a complex result:


a = [1 + i, 1-i, 2];
b = [1 - i, 2-i, 1 + i];
c_cross = cross(a,b)
check_cross = [dot(c_cross, a), dot(c_cross, b)]
check_dot = dot(a,b)


output with octave:

c_cross = -2 + 2i   2 - 4i   3 + 3i
check_cross =  12 -  8i   10 +  6i


output with matlab R2019B


c_cross = -2.0000 - 2.0000i   2.0000 + 4.0000i   3.0000 - 3.0000i
check_cross =    0     0


A.R. Burgers <arb>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #57277:  b67186.cset added by arb (2KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by arungiridhar (Posted a comment)
  • -email is unavailable- added by arb (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2025-06-06 mmuetzel StatusReady For Test In Progress
        Planned ReleaseNone 10.3.0 (current stable)
    2025-06-06 mmuetzel Attached File- Added bug67186-cross-complex-v2.patch, #57279
        Item GroupMatlab Compatibility Documentation
    2025-06-06 arb Attached File- Added b67186.cset, #57277
    2025-06-03 arungiridhar StatusNone Ready For Test
    2025-06-03 arungiridhar Item GroupIncorrect Result Matlab Compatibility

    Back to the top

    Powered by Savane 3.15-26b0.
    Corresponding source code