ARCTAN2 errors out when X is 0

[RyanBurnside]

Describe the bug
Currently ARCTAN2 is implemented using FQUOTIENT division that does no zero check.
I came across this when it was throwing errors during my game project.
Unfortunately it also means it considers perfectly valid parameters errors.

To Reproduce
In your Exec for Interlisp try
(ARCTAN2 -1 0)
You'll see an error followed by 0.0.

Expected behavior
It should return a computation for that parameter set without error.
(ARCTAN2 0 0) /may/ be considered undefined but currently the function is erroring on ALL cases where X is 0 and Y is not due to the immediate division.

Screenshots

Context (please complete the following information):

• Are you using online.interlisp.org? [no]
• OS: [Linux]
• OS Version: [Kubuntu 24]
• Display/window system: [X11]
• Host arch: [x86_64]
• Maiko version: [e.g. commit ID from git log | head]
• IL:MAKESYSDATE: [8-Oct-2025]

[RyanBurnside]

This piecewise formula seems like it might do the trick...

[nbriggs]

You can also use (ATAN y x radiansflg) if you're OK with (ATAN 0 0) being 45 degrees. It doesn't have any problem with x being 0.

[nbriggs]

And... there's (CL:ATAN y x) which only (I think) errors if both y and x are 0.0

[RyanBurnside]

Nick, thanks for the insight.

I had a bit of fun. I believe my function is faster for degrees (slightly slower for radians) and gives the correct value for (Y X=0). However the CL function (CL:ATAN Y X) is MUCH faster. I tried to keep mine in pure Interlisp but I think the PI constants may be leaking from something else (How can I check?). Also I need to triple check my function.

Anyway...

(LAMBDA (Y X RADIANSFLG)
       (TIMES (COND (RADIANSFLG 1)
                    (T 180/PI))
              (if (GREATERP X 0.0)
                  then
                  (ARCTAN (FQUOTIENT Y X)
                         T)
                  elseif
                  (LESSP X 0.0)
                  then
                  (PLUS (ARCTAN (FQUOTIENT Y X)
                               T)
                        (if (GEQ Y 0.0)
                            then
                            (MINUS -PI)
                            else -PI))
                  elseif
                  (GREATERP Y 0.0)
                  then PI/2 elseif (LESSP Y 0.0)
                  then -PI/2 

                  (* ;; 
          "This is usually an error case, but Interlisp seems to treat 0 0 like 0 in other trig fns.")

                  else 0.0)))

[psilord]

A minor comment. According to CLHS, the ATAN function takes x first, then y next: (CL:ATAN x y) when it is functioning in the atan2 mode.

CLHS describes:

 atan number1 &optional number2 => radians

Then later in the CLHS:

For [atan](http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/fun_asincm_acoscm_atan.html#atan), the signs of number1 (indicated as x) and number2 (indicated as y) are used to derive quadrant information.

CLHS ATAN Function

So, I suggest to be careful not to blindly copy the IL:ARCTAN2 lambda-list ordering for CL:ATAN.

[psilord]

Though, curiously, SBCL thinks that the signature of common lisp's atan is:

(defun atan (y &optional (x nil xp))
  "Return the arc tangent of Y if X is omitted or Y/X if X is supplied."
  ...)

So there appears to be a difference between CLHS's description and SBCL's implementation.

Sadly, the ANSI Common Lisp Errata, on cliki.net, seems to be down, but I found it in the wayback machine:

Wayback Machine CLHS Errata

It makes no mention of ATAN, so I wonder if it is an unrecorded bug in the CLHS.

[nbriggs]

@psilord - Note that the CLHS says when both arguments are given, it calculates the arctangent of number1 / number2, or, as SBCL and Medley state it, the arguments are Y and X and it's calculating arctangent of Y / X - so I don't see an issue.

[psilord]

Ok, after more inspection, I now think the CLHS is either wrong or very misunderstandable. CL's atan indeed takes y first then x next when computing atan2. Thank you for checking!

[RyanBurnside]

I had some downtime today to write a test "suite" that shows more of the nature of this thing.
CL seems to match in both direction (same rotation) and also doesn't error on X being 0 EXCEPT in the case that it gets 0 0 - different behavior than IL:ARCTAN2.

[nbriggs]

Nice. I'd note that the following π-related constants are already defined in the system (in AARITH) -- so I'd avoid causing allocation and arithmetic for these values where possible:

(RPAQQ 2PI 6.283185)
(RPAQQ CL:PI 3.141593)
(RPAQQ -PI -3.141593)
(RPAQQ -PI/2 -1.570796)
(RPAQQ PI/2 1.570796)
(RPAQQ 4/PI 1.273239)
(RPAQQ 3PI/2 4.712389)
(RPAQQ PI/4 0.7853982)
(RPAQQ -PI/4 -0.7853982)
(RPAQQ PI/180 0.01745329)
(RPAQQ 180/PI 57.29578)
(RPAQQ -PI/2 -1.570796)

Also worth looking at the code for %ATAN-FLOAT (in CMLFLOAT) to see the use of unboxed float ops.

[RyanBurnside]

Ok, I'll go ahead and get them placed back in.
Then run my tests and hopefully this can be fixed.

[RyanBurnside]

@nbriggs I attempted to load the file CMLFLOAT and it seems to be throwing an error

Undefined car of form 
IL:\\FLOATBOX

Maybe it depends on something else being present?
I'm using MANAGER as recently suggested. Maybe I'm not using the right workflow...

[pamoroso]

Try (FILESLOAD SYSEDIT), which loads some definitions needed when doing system development.

[pamoroso]

Never mind, SYSEDIT doesn't help.