Find the coterminal angle on [0, 2π)

Question

This challenge is very simple:

Given an angle measure in degrees or radians (your choice), output the angle between 0 and 2π non-inclusive [0º, 360º) that is coterminal with it.

Input

A positive or negative angle measure. You can pick if you want to take it in degrees or in radians.

Output

The angle on [0, 2π) that is coterminal with the input angle. If you take the input in degrees, the output must also be in degrees; if you take it in radians, the output must be in radians too. The coterminal angle is essentially a the angle mod 360°.

Examples (in degrees)

745 -> 25
1728 -> 288
90 -> 90
0 -> 0
360 -> 0
-50 -> 310
-543.21 -> 176.79

Answer 1

05AB1E, 4 bytes

360%

Try it online!

360  # push 360
   % # pop a,b: push (a % b)

Answer 2

Python 3, 14 bytes

lambda n:n%360

Try it online!

Answer 3

R, 11 bytes

takes input from stdin in degrees

scan()%%360

Try it online!

Answer 4

MATL, 5 4 bytes

360\

Try it online!

My first attempt with MATL!

-1 byte, just realised i is not necessary for recording the input...

Answer 5

Python 3, 13 bytes

360..__rmod__

Explanation: num.__rmod__(x) is equivalent to x%num (rmod is modulo from the right.).

Answer 6

05AB1E, 4 bytes

Just because there were no answers using radians.

žq·%

Try it online!

Answer 7

CJam, 12 bytes

rd360:X%X+X%

All those extra bytes because CJam gives negative results for mods...

Try it online!

Answer 8

Jelly, 4 bytes

%360

Try it online!

I was kind of hoping Æ°° would do it for 3.

Answer 9

Java 7, 44 43 bytes

_{Crossed out 44 is still regular 44 ;(}

float c(float n){return(n%=360)<0?n+360:n;}

Explanation:

Java uses remainder instead of actual modulo for negative numbers (source). So we'll have to manually fix the negative cases.

float c(float n){    // Method with float input and float return-type
  return(n%=360)<0?  //  If input mod-360 is negative
   n+360             //   Return input mod-360 + 360
  :                  //  Else:
   n;                //   Return input mod-360
}                    // End of method

Test code:

Try it here.

class M{
  static float c(float n){return(n%=360)<0?n+360:n;}

  public static void main(String[] a){
    System.out.print(c(745) + "; ");
    System.out.print(c(1728) + "; ");
    System.out.print(c(90) + "; ");
    System.out.print(c(0) + "; ");
    System.out.print(c(360) + "; ");
    System.out.print(c(-50) + "; ");
    System.out.print(c(-543.21f));
  }
}

Output:

25.0; 288.0; 90.0; 0.0; 0.0; 310.0; 176.78998

Answer 10

Japt, 14 11 10 4 bytes

u#Ũ

Try it online!

Takes input in degrees.

Explanation

 u#Ũ
Uu360
U     # (implicit input)
 u    # modulo
  360 # 360
      # (implicit output)

Answer 11

C, 69 43 bytes

This seems like an excessively trivial challenge, and indeed in many languages it is. The trick is in the implementation details of the modulo operator.

When both modulo operands are positive, nothing interesting happens. But when one of the operands is negative, then the results start depending on your interpretation of what should happen. You can either always return a positive result, return a result whose sign depends on the dividend, or return a result whose sign depends on the divisor.

Programming languages are quite divided on which behavior they choose to implement. The lucky ones for this challenge are the ones that always return a positive result, since that's what the test cases call for.

If you happen to be golfing in a language that implements modulo dependent on the sign of the dividend, then you have to do extra work to compensate for negative inputs—and to make sure that this compensation does not break positive inputs!

Here's a further golfed implementation in C (thanks to ais523):

f(double*n){*n=fmod(fmod(*n,360)+360,360);}

Try it online!

Notice that C is also hobbled here by the unfortunate omission of a modulo operator (a la %) for floating-point operations. Instead, you have to call a library function.

Answer 12

JavaScript (ES6), 21 19 18 bytes

Takes input in degrees.

n=>(n%360+360)%360

• Saved 2 bytes thanks to Luke.
• Saved 1 byte thanks to Neil.

---

Try it

f=
n=>(n%360+360)%360
i.addEventListener("input",_=>o.innerText=f(+i.value))
console.log(f(745)) // 25
console.log(f(1728)) // 288
console.log(f(90)) // 90
console.log(f(0)) // 0
console.log(f(360)) // 0
console.log(f(-50)) // 310
console.log(f(-543.21)) // 176.79

<input id=i type=number><pre id=o>

Answer 13

Fourier, 22 14 6 bytes

I%360o

Try it online!

Simply outputs the input modulo 360.

Note that since the interpreter for TIO is written in Python, this will not work on http://beta-decay.github.io/editor

Answer 14

Mathematica, 10 bytes

#~Mod~360&

Pure function taking any type of numerical input in degrees. Does what it says on the tin.

Answer 15

x86 Assembly (targeting the x87 FPU), 23 bytes

As is standard with 32-bit calling conventions, the double-precision floating-point parameter is passed on the stack, and returned at the top of the x87 FPU stack. Assemble with MASM:

.MODEL flat
.686                              ; fucomip requires a Pentium Pro or later CPU

CONST SEGMENT
divisor  DD  043b40000r           ; 360.0f
CONST ENDS

PUBLIC _CoterminalAngle
_TEXT SEGMENT
_CoterminalAngle PROC
   fld      DWORD PTR [divisor]   ; single-precision takes fewer bytes to store; we don't need the precision
   fld      QWORD PTR [esp + 4]   ; load parameter from stack

   fprem                          ; st(0) = parameter % 360
                                  ; st(1) = 360

   fldz
   fucomip  st(0), st(1)          ; st(0) < 0?
   jbe      Finished
   fadd     st(0), st(1)          ; fixup negative modulo by adding 360
Finished:

    fstp    st(1)                 ; discard st(1); result is left in st(0)
    ret
_CoterminalAngle ENDP
_TEXT ENDS

END 

To call from C:

extern double CoterminalAngle(double value);

In bytes:

43B40000

D9 05 00 00 00 00
DD 44 24 04
D9 F8
D9 EE
DF E9
76 02
D8 C1
DD D9
C3

Notes:

As the comment indicates, to minimize code size, I've stored the divisor constant (360.0f) as a single-precision floating-point value. This means it is half the length it would be if it were a double-precision value, and we don't need the precision to store a proper representation of the value. Upon loading, the x87 FPU will implicitly extend it to its native ten-byte extended-precision format.

We're also playing it fast-and-lose with the FPREM instruction for golfing purposes, assuming it does not need to reduce the exponent of the input value by more than 63. The careful (read: correct) way to call it would be iteratively, in a loop, continuing to execute it as long as the "parity" flag is set.
For example:

RemainderLoop:
   fprem
   fstsw  ax
   sahf
   jp     RemainderLoop

That would add 6 bytes to the total.

---

x86 Assembly (targeting AVX), 47 bytes

By way of comparison (and for completeness), here's an AVX implementation. It's more bytes, but also more efficient. The parameter is passed in XMM0, and the result is returned in the same register, as with any x86-64 or vector x86-32 calling convention.

43 B4 00 00    | divisor  DD  043b40000r           ; 360.0f

               | ; Load single-precision FP value, and convert it to double-precision.
C5 EA 5A 15 00 | vcvtss2sd  xmm2, xmm2, DWORD PTR [divisor]
    00 00 00   |
               | ; Divide input parameter (XMM0) by divisor (XMM2), and store result in XMM1.
C5 FB 5E CA    | vdivsd     xmm1, xmm0, xmm2
               |
               | ; Truncate the result of the division to the nearest integer.
C5 FB 2C C1    | vcvttsd2si eax, xmm1
C5 F3 2A C8    | vcvtsi2sd  xmm1, xmm1, eax
               |
               | ; Multiply the truncated result by divisor (XMM2).
C5 F3 59 CA    | vmulsd     xmm1, xmm1, xmm2
               |
               | ; Subtract this temporary value (XMM1) from the original input (XMM0).
C5 FB 5C C1    | vsubsd     xmm0, xmm0, xmm1
               |
               | ; See if the result is negative.
C5 F1 57 C9    | vxorpd     xmm1, xmm1, xmm1   ; xmm1 = 0
C5 F9 2F C8    | vcomisd    xmm1, xmm0         ; result < 0?
76 04          | jbe        Finished
C5 FB 58 C2    | vaddsd     xmm0, xmm0, xmm2   ; fixup negative modulo by adding divisor (XMM2)
               | 
               | Finished:
C3             | ret

Of course, it would be even more efficient to multiply by the reciprocal, instead of dividing. But that means more precision is required to store the divisor, and would thus slightly increase the size of the code.

Answer 16

PHP, 29 Bytes

<?=($v=$argn%360)>=0?:$v+360;

Answer 17

Python 2 REPL - 11 bytes

input()%360

If we've got a wierd input function, we might as well abuse it, right?

Answer 18

Pyth - 5 bytes

%Q360

Would be shorter if %360 meant Q%360 instead of 360%Q, but oh well...