Numpy: Solicitação de recurso: adicione funções simples numpy para sistemas de coordenadas de transformação

Criado em 24 out. 2014 · 14Comentários · Fonte: numpy/numpy

Seria conveniente ter essas funções como parte de rotinas matemáticas numpy.

cart2pol -- Transforma coordenadas cartesianas em polares

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

pol2cart -- Transforma coordenadas polares em cartesianas

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

cart2sph -- Transforma coordenadas cartesianas em esféricas

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 -- Transforma coordenadas esféricas em cartesianas

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

01 - Enhancement numpy.lib

Fonte

espdev

👍22

Comentários muito úteis

Eu entendo o que você está falando. No entanto, essas funções são usadas com muita frequência ao trabalhar com os sistemas de coordenadas em algoritmos geométricos, software de computação gráfica, etc. A generalização em n-dimensões raramente é necessária. No MATLAB essas funções existem e, devo dizer, são bastante convenientes. Considero essas funções como simples rotinas matemáticas, por exemplo, as funções rad2deg e deg2rad. Essas funções, como você sabe, são funções usadas com frequência e existem em numpy.

espdev em 24 out. 2014

👍7

Todos 14 comentários

Não tenho certeza se isso é algo que precisa estar em numpy, as funções são simples o suficiente para serem implementadas de maneira ideal.
Se as somarmos, traçamos a linha sobre quais transformações adicionar? há uma quantidade infinita deles.

juliantaylor em 24 out. 2014

👎2 😕1

Mesmo se traçarmos a linha apenas nas transformações esféricas, existem várias convenções diferentes que não são representadas aqui. Acredito que essas funções sejam mais apropriadas para um pacote que realmente as utiliza internamente (ex. astropy) e segue uma convenção particular através de seu código.

rkern em 24 out. 2014

👍2

espdev em 24 out. 2014

👍7

Como regra geral, certamente há um lugar em numpy para utilidade básica
coisa. Obviamente, há uma pergunta sobre onde exatamente traçar a linha,
mas nós incluímos e devemos incluir pelo menos algumas coisas assim. (como um extremo
exemplo, por que exportamos np.pi? É trivial para os usuários reimplementar se
eles precisam disso... mas forçá-los a fazer isso seria um desperdício irritante de
seu tempo.)

Então, se vamos desenhar uma linha, devemos fazer isso com base em alguns
princípios OMI.

Alguns critérios potenciais a serem considerados para esses tipos de ajudantes simples:

eles atendem a uma ampla classe de usuários?
esses usuários usam o mesmo conjunto de convenções?
existe apenas uma API óbvia?
existe apenas uma implementação ideal?
existe alguma inconveniência complicada em alcançar este ótimo
implementação? (Observe que o pol2cart do OP faz cópias desnecessárias.)
eles serão um fardo de manutenção contínua para nós? (Isso é meio
superconjunto de vários dos pontos acima.)

Eu acho que essas funções pontuam muito bem nesses critérios. Todo mundo usa
coordenadas polares às vezes, ninguém vai reclamar que implementamos
eles estão errados, checar a fórmula toda vez que você precisar deles é um
perda de tempo irritante, etc.

Uma coisa que não tenho certeza é se todos usam as mesmas convenções
para mapeamento entre coordenadas esféricas e cartesianas - alguém sabe?
Eu poderia imaginar diferentes comunidades tendo diferentes convenções de sinais ou
seja o que for, e eu quase não os uso.
Em 24 de outubro de 2014 21:04, "Evgeny Prilepin" [email protected] escreveu:

Eu entendo o que você está falando. No entanto, essas funções são usadas
muitas vezes ao trabalhar com os sistemas de coordenadas em geometria
algoritmos, software de computação gráfica, etc. Generalização em n-dimensões
é necessário com pouca frequência. No MATLAB existem essas funções
http://www.mathworks.com/help/matlab/cartesian-coordinate-system-conversion.html
e, devo dizer, são bastante convenientes. Eu considero essas funções
como simples rotinas matemáticas, por exemplo, funções rad2deg e
deg2rad. Essas funções, como você sabe, são funções frequentemente usadas e
existir
http://docs.scipy.org/doc/numpy/reference/generated/numpy.rad2deg.html#numpy.rad2deg
em numpy.
—
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/numpy/numpy/issues/5228#issuecomment -60441622.

njsmith em 25 out. 2014

👍1

Infelizmente, existem algumas convenções usadas para lidar com coordenadas esféricas: http://en.wikipedia.org/wiki/Spherical_coordinate_system

Eu acho que é melhor deixar os usuários definirem as transformações de coordenadas esféricas específicas que eles querem.

shoyer em 30 out. 2014

Há também um padrão ISO que especifica qual é o formato "adequado"... Eu não acho que várias convenções sejam realmente um problema, desde que o que é retornado esteja claramente documentado: mudar de uma convenção para outra é muito mais fácil do que transformar coordenadas cartesianas em qualquer um dos possíveis sistemas de coordenadas esféricas.

Por outro lado, não vejo isso se encaixando no numpy como um punhado de funções independentes. Coordenadas polares, especialmente relacionadas a números complexos, talvez, mas coordenadas esféricas, não realmente.

jaimefrio em 30 out. 2014

Bem, estou bastante inclinado a concordar com você. Não vamos discutir a função das coordenadas esféricas agora. No entanto, funções de coordenadas polares podem ser aplicadas em muitos casos.

espdev em 31 out. 2014

Existem 5 normas diferentes implementadas em np.linalg.norm ? Não vejo por que também não é possível adicionar algumas transformações de coordenadas. Mesmo se feito sem opções, não acho que haja qualquer discussão séria sobre a validade da utilidade de um simples x,y -> r*cos(theta),sin(theta) e seu inverso. Eu ficaria surpreso se esta não fosse a transformação de coordenadas mais usada e direta no mundo.

michaelaye em 20 fev. 2016

Por outro lado, não vejo isso se encaixando no numpy como um punhado de funções independentes. Coordenadas polares, especialmente relacionadas a números complexos, talvez, mas coordenadas esféricas, não realmente.

Concorde com isso. A maioria das pessoas parece ser neutra a positiva para adicionar as transformadas de coordenadas polares. Então, se alguém quiser fazer uma proposta concreta e depois trabalhar na implementação, acho que é bem-vindo.

Alguns outros pensamentos:

Mesmo para polar, existem algumas convenções que precisam ser claramente documentadas (ângulo em graus ou radianos, e no intervalo [0, 2pi) ou [-pi, pi) ). Eu provavelmente preferiria [-pi, pi) .
Podemos considerar colocar as funções no namespace numpy.lib em vez do numpy de nível superior.

rgommers em 20 fev. 2016

Encontrei isso enquanto estávamos discutindo acelerações de transformações de coordenadas em astropy (https://github.com/astropy/astropy/pull/5735) e me perguntei o que aconteceu com sincos (#2626) e "expoente de apenas um número imaginário" (#5625).

Uma sugestão pode ser começar seguindo cmath [1] e introduzir np.rect e np.polar , e trabalhar a partir deles (atualmente, cobrimos todos, exceto esses dois e np.phase de cmath ).

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

mhvk em 25 jan. 2017

👍2

Versões 3D desses ajudantes também seriam úteis.

felixdivo em 30 mai. 2018

👍3

Olá, sou novo aqui e como estou em deep learning, tenho essa dúvida.
Estou usando o tensorflow para detectar objetos com a câmera USB HD que está estacionária.
Recebo as coordenadas do centro dos objetos e quero que o robô vá para essas coordenadas, qual conversão devo usar para isso?
No robô, estou usando as coordenadas XYZ que são cartesianas por manual. Não tenho certeza de quais coordenadas recebo de tensorflow, cartesian, pixel ou o quê?

Obrigado