bugGNU Octave - Bugs: bug #59934, Unexpected complex result from acos

 
 

bug #59934: Unexpected complex result from acos

Submitter:  None
Submitted:  Sun 24 Jan 2021 01:43:39 AM UTC
   
 
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Missed Error or Warning
Status:  Invalid / Not an Octave Bug Assigned to:  None
Originator Name:  Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * 6.1.0
Operating System:  * Microsoft Windows Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Fri 29 Jan 2021 08:25:52 PM UTC, comment #4: 

Should we also document that sqrt(-1) returns complex instead of a domain error?

John W. Eaton <jwe>
Group administrator
Sun 24 Jan 2021 09:53:03 PM UTC, comment #3: 

This isn't just Matlab compatibility.  This is the natural extension of the function outside the domain |x| < 1.  See, for example, Wolfram Alpha (https://www.wolframalpha.com/input/?i=acos+%281.5%29) as well.

Rik <rik5>
Group administrator
Sun 24 Jan 2021 08:47:28 PM UTC, comment #2: 

If x complex, acos and asin will return complex as well.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Sun 24 Jan 2021 07:52:48 PM UTC, comment #1: 

This is done for Matlab compatibility. For |x| <= 1, acos(x) and asin(x) will return their expected values as described in IEC 60559 or IEEE 754. But unlike the standards, which require a domain error for |x| > 1, Matlab returns a complex number as described in Example 1 here: https://ximera.osu.edu/math/complexBook/complexBook/complexTrig/complexTrig

This is probably already known to anyone who came to Octave from a Matlab background, but yes, it could be documented in acos and asin for new users. Documentation patch here:


diff -r 7bb6a7cbb65e libinterp/corefcn/mappers.cc
--- a/libinterp/corefcn/mappers.cc      Sat Jan 23 17:28:14 2021 +0100
+++ b/libinterp/corefcn/mappers.cc      Sun Jan 24 14:50:55 2021 -0500
@@ -88,6 +88,7 @@
        doc: /* -*- texinfo -*-
 @deftypefn {} {} acos (@var{x})
 Compute the inverse cosine in radians for each element of @var{x}.
+For |x| > 1, the return value will be complex.
 @seealso{cos, acosd}
 @end deftypefn */)
 {
@@ -292,6 +293,7 @@
        doc: /* -*- texinfo -*-
 @deftypefn {} {} asin (@var{x})
 Compute the inverse sine in radians for each element of @var{x}.
+For |x| > 1, the return value will be complex.
 @seealso{sin, asind}
 @end deftypefn */)
 {


Anonymous
Sun 24 Jan 2021 01:43:39 AM UTC, original submission:  

Running acos(x) unexpectedly gives complex numbers if x exceeds +1 due to numerical roundoff, instead of giving a domain error. This unexpected and undocumented behavior is not listed by "help acos". The workaround now is to say "acos(max(min(1,x),-1))" to artificially force it to [-1 +1]. Any thoughts why it returns a complex number?

Anonymous

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

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 rik5 (Posted a comment)
  • -email is unavailable- added by dasergatskov (Posted a comment)
  •  

    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 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-01-29 jwe StatusWorks For Me Invalid / Not an Octave Bug
        Open/ClosedOpen Closed
    2021-01-24 rik5 CategoryNone Octave Function
        StatusNone Works For Me

    Back to the top

    Powered by Savane 3.13-4b48.
    Corresponding source code