ENH: Add to numpy simple functions for transform coordinate systems

[espdev]

It would be convenient to have these functions as a part of numpy mathematical routines.

cart2pol -- Transform Cartesian to polar coordinates

def cart2pol(x, y):
    theta = np.arctan2(y, x)
    rho = np.hypot(x, y)
    return theta, rho

pol2cart -- Transform polar to Cartesian coordinates

def pol2cart(theta, rho):
    x = rho * np.cos(theta)
    y = rho * np.sin(theta)
    return x, y

cart2sph -- Transform Cartesian to spherical coordinates

def cart2sph(x, y, z):
    hxy = np.hypot(x, y)
    r = np.hypot(hxy, z)
    el = np.arctan2(z, hxy)
    az = np.arctan2(y, x)
    return az, el, r

sph2cart -- Transform spherical to Cartesian coordinates

def sph2cart(az, el, r):
    rcos_theta = r * np.cos(el)
    x = rcos_theta * np.cos(az)
    y = rcos_theta * np.sin(az)
    z = r * np.sin(el)
    return x, y, z

[juliantaylor]

I'm not sure this is something that needs to be in numpy, the functions are simple enough to implement yourself optimally.
If we add them were do we draw the line on which transformations to add? there are an infinite amount of them.

[rkern]

Even if we draw the line at just the spherical transformations, there are a number of different conventions that are not represented here. I believe that these functions are more appropriate to a package that actually uses them internally (e.g. astropy) and follows a particular convention through its code.

[espdev]

I understand what you are talking about. However, these functions are used very often while working with the coordinate systems in geometric algorithms, computer graphics software, etc. Generalization on n-dimensions is required infrequently. In MATLAB these functions exist and, I should say, they are rather convenient. I consider these functions as simple mathematical routines, for example, functions rad2deg and deg2rad. These functions, as you know, are frequently used functions and exist in numpy.

[njsmith]

As a general rule there's certainly a place in numpy for basic utility
stuff. Obviously there is a question about where exactly to draw the line,
but we do and should include at least some stuff like this. (As an extreme
example, why do we export np.pi? It's trivial for users to reimplement if
they need it... but forcing them to do so would be an annoying waste of
their time.)

So if we're going to draw a line we should actually do that based on some
principles IMO.

Some potential criteria to consider for these kinds of simple helpers:

• do they address a broad class of users?
• do these users use the same set of conventions?
• is there just one obvious api?
• is there just one optimal implementation?
• is there any fiddly annoyingness in achieving this optimal
  implementation? (Note that the OP's pol2cart makes unnecessary copies.)
• will they be an ongoing maintenance burden on us? (This is kinda a
  superset of several of the above points.)

I think these functions score pretty well on these criteria. Everyone uses
polar coordinates sometimes, no-one's going to complain that we implemented
them wrong, double-checking the formula every time you need them is an
annoying waste of time, etc.

One thing I'm uncertain about is whether everyone uses the same conventions
for mapping between spherical and Cartesian coordinates - does anyone know?
I could imagine different communities having different sign conventions or
whatever, and I hardly use them myself.
On 24 Oct 2014 21:04, "Evgeny Prilepin" notifications@github.com wrote:

I understand what you are talking about. However, these functions are used
very often while working with the coordinate systems in geometric
algorithms, computer graphics software, etc. Generalization on n-dimensions
is required infrequently. In MATLAB these functions exist
http://www.mathworks.com/help/matlab/cartesian-coordinate-system-conversion.html
and, I should say, they are rather convenient. I consider these functions
as simple mathimatical routines, for example, functions rad2deg and
deg2rad. These functions, as you know, are freqently used functions and
exist
http://docs.scipy.org/doc/numpy/reference/generated/numpy.rad2deg.html#numpy.rad2deg
in numpy.

—
Reply to this email directly or view it on GitHub
#5228 (comment).

[shoyer]

Unfortunately, there are indeed quite a few conventions used for handling spherical coordinates: http://en.wikipedia.org/wiki/Spherical_coordinate_system

I think it is better to let users define the specific spherical coordinate transforms they want themselves.

[jaimefrio]

There is also an ISO standard that specifies what the "proper" format is... I don't think that multiple conventions are really an issue, as long as what gets returned is clearly documented: switching from one convention to another is much easier than transforming cartesian coordinates to any one of the possible spherical coordinate systems.

On the other hand, I don't see this fitting in numpy as a handful of standalone functions. Polar coordinates, especially as related to complex numbers, maybe, but spherical coordinates, not really.

[espdev]

Well, I am rather inclined to agree with you. Let’s not discuss the function of spherical coordinates now. However, functions of polar coordinates may be applied in many cases.

[michaelaye]

There's 5 different norms implemented in np.linalg.norm? I don't see why it then is not also possible to add a few coordinate transformations. Even if done without options, I don't think there's any serious discussion about the validity of the usefulness of a simple x,y -> r*cos(theta),sin(theta) and its inverse. I would be surprised if this would not be the most used and straight forward coordinate transformation in the world.

[rgommers]

On the other hand, I don't see this fitting in numpy as a handful of standalone functions. Polar coordinates, especially as related to complex numbers, maybe, but spherical coordinates, not really.

Agree with this. Most people seem to be neutral to positive for adding the polar coordinate transforms. So if someone wants to make a concrete proposal and then work on implementing, I think that's welcome.

Some other thoughts:

• Even for polar, there's some conventions that needs to be clearly documented (angle in degrees or radians, and in interval [0, 2pi) or [-pi, pi)). I'd probably prefer [-pi, pi).
• We may consider putting the functions in the numpy.lib namespace instead of the top level numpy one.

[mhvk]

Found this as we were discussing speed-ups of coordinate transformations in astropy (astropy/astropy#5735) and I wondered what happened with sincos (#2626) and "exponent of just an imaginary number" (#5625).

One suggestion might be to start by following cmath [1] and introduce np.rect and np.polar, and work from those (currently, we cover all but these two and np.phase of cmath).

[1] https://docs.python.org/3.5/library/cmath.html#conversions-to-and-from-polar-coordinates

[felixdivo]

3D versions of these helpers would also be helpful.

[fdkssdks]

Hello, I am new here and since I am into deep learning, I have this question.
I am using tensorflow to detect objects with USB HD Camera which is stationary.
I get the coordinates of the center of objects and I want the robot to go to those coordinates, which conversion should I use for this purpose?
On robot I am using XYZ coordinates that is Cartesian per manual. Not sure what coordinates I get from tensorflow, cartesian, pixel or what ?

Thanks

[charris]

@fdkssdks Wrong place to ask those questions, try stackoverflow.

[felixdivo]

Or here: Tensorflow API Documentation.

[tengfeixue-victor]

Hi,

Should "el = np.arctan2(z, hxy)" be "el = np.arctan2(hxy,z)" in cart2sph of #5228 (comment)?

Thanks

[mattip]

I think we should close this as "good idea, the API should be worked out in a package outside of NumPy and then we can think about merging in". Please reopen (or ask for it to be reopened) if you disagree.

[s-m-e]

There are a couple of Python packages in this space providing all sorts of bits and pieces. I keep collecting what I need for each project from multiple packages - or implement the conversions myself. The weak spot, other than that this is time consuming, is literally performance. Implementing this sort of thing in pure Python with a bunch of calls into numpy ufuncs introduces significant overhead. This is what is suggested here and this is also what most packages tend to do. I usually compile this stuff down with numba, though again this solution is less than ideal.

If someone tries to implement this as "actual" ufuncs (in just any compiled language) with all bells and whistles of a ufunc (such as the out parameter), I could see some serious value - despite the "simplicity" of some of the proposed functions. In either case, if anyone is working on something along those lines, please drop a note here.