• Can you say a bit about your motivation for adding these? They're just equivalent to a % (2*np.pi) and a % (2*np.pi) - np.pi, right?
• Why implement both wrap_to_pi and wrap_to_2pi?
• Assuming we decide the functions are useful overall:
  • Needs tests
  • Should have "see also" notes added to np.wrap and vice-versa.

The basic motivation behind these functions is the same as behind rad2deg, which could also be easily written as a / np.pi * 180 - just for convenience. But to be precise it's actually not the same as a % (2*np.pi):

>>> np.array([1, 2, -2*np.pi, 2*np.pi]) % (2*np.pi)
array([ 1.,  2., -0.,  0.])
>>> np.wrap_to_2pi([1, 2, -2*np.pi, 2*np.pi])
array([ 1.        ,  2.        ,  0.        ,  6.28318531])

>>> np.array([1, 2, 2*np.pi, -np.pi, np.pi, -3]) % np.pi
array([ 1.,  2.,  0., -0.,  0., 0.14159265])
>>> np.wrap_to_pi([1, 2, 2*np.pi, -np.pi, np.pi, -3])
array([ 1.        ,  2.        ,  0.        , -3.14159265,  3.14159265, -3])

But some more detailed description about the exact behavior has to be added for sure. As well as test cases, but please let me know what you think about it before I spend more time on this.

That's a good point about rad2deg.

I don't understand your point about wrap_to_2pi being different from a % (2*np.pi) -- your example just looks like some meaningless difference in floating point rounding? Or am I missing something? (And obviously wrap_to_pi is different than a % np.pi, that's why I said it was the same as a % (2*np.pi) - np.pi ;-).)

You didn't answer the question about why you think both of these functions are needed. Though I guess if we have one, then we might want both, just because if we only have a single function named np.wrap then people will never be able to remember which convention it uses, whereas the current names have a reminder right in the name.

I guess I'm +0 on this idea given the increase in readability and the precedent set by np.unwrap, np.rad2deg. Anyone else?

@njsmith This is especially useful if you deal with some kind of polar or spherical coordinates. Here you don't want 360deg wrap to 0deg.

Hmm, if what you're saying is that it is critical that you wrap to the closed interval [0, 2pi] rather than the half-open interval [0, 2pi), then this actually makes me more nervous about this code, not less. It seems very likely that there are users who will expect the half-open interval behaviour and find the closed-interval behaviour very confusing -- will we need to add another pair of functions later for them? And the actual behaviour you're worried about -- the handling of the floating point number which is exactly equal (in floating point) to 2pi -- is the sort of behaviour that you can't really handle correctly in floating point in the first place. It's entirely possible that where you expected 360 degrees your calculation instead produces 360.00000000000006 degrees (error of 1 unit-in-the-last-place) -- now what? Should that wrap around to 0? If the user was depending on the behaviour that you're talking about, then will their code break whenever this happens?

This is more questions than I like to have about code that's proposed for merging into numpy, given that numpy is supposed to be the core set of operations that everyone relies on.

Sorry for the late reply. I just had a look at what Matlab does and they seem to do the same as I implemented here.

Nevertheless feel free to decide whether this is useful at all or if you wish any modified version of this.

@ahojnnes This should probably be discussed on the list as it is a new function. I tend to agree with @njsmith about the interval, I'm not sure why Matlab does it that way except Matlab tends to use closed intervals.

I think we should close this - both operations are easy to spell as x % (2*pi) and (x - pi) % (2*pi) + pi respectively. If we want to make the second easier to spell, then #9963 would allow it to be spelt np.remainder_ieee(x, 2*pi). Defining this as part of numpy directly means we have to make difficult choices about open and closed ranges, which are probably best left to the user.

Thanks for the suggestion anyway @ahojnnes!