Document that for spherical coordinates theta is going from x to y and phi is going from xy-plane to z

[zsoerenm]

Document that for spherical coordinates theta is going from x to y and phi is going from xy-plane to z.

This definition of phi differs from the mathematically defined phi:
https://en.wikipedia.org/wiki/Spherical_coordinate_system

[andyferris]

So phi is "backwards", more or less?

Is this pretty much universal, or just the convention wikipedia has chosen?

[c42f]

As discussed on the wikipedia page, there's no consensus on the symbols used, with theta and phi swapped in physics and mathematics.

We should choose the most common one if we can, and just document that. (Are we really using a latitude-like angle rather than a polar angle? That seems like a mistake to me!)

[andyferris]

Yes, it might be a mistake.

[zsoerenm]

I think the most common one is the mathematically one. Wolfram Alpha is also using the mathematical definition: http://mathworld.wolfram.com/SphericalCoordinates.html
And it is the same for mathinsight.org: http://mathinsight.org/spherical_coordinates

Unfortunately I can't upload a svg file here. But here you have got a png and a pdf file:

SphericalCoordinates.pdf
That is the current definition in CoordinationTransformation.jl. I'm happy to generate new pictures, if you change the definition.

[Joel-Dahne]

I realize that this issue is quite old but I thought I would something as well. I think it would be beneficial to use one of the versions mentioned in the above linked wikipedia article, instead of the currently used one which is a bit non-standard. If you should use "the mathematics" one or "the physics" one I'm not sure. However I would say that Wikipedia's categorization is not completely accurate, I have encountered "the physics" one several time in a mathematical context. For example The NIST Digital Library uses the physics convention as is seen here.

[c42f]

There's no great solution to this but clearly the current situation is bad.

Here's my suggested way forward:

1. Deprecate the use of Spherical and introduce MathSpherical and ISOSpherical (or perhaps PhysSpherical ? better names?).
2. Remove Spherical entirely after a deprecation cycle.
3. Possibly, at a later date, we could reintroduce const Spherical = ISOSpherical. Though it might be best to avoid the ambiguity entirely by just not doing this.

I'm sure a PR to implement step 1. would be gratefully received :-)

[Kolaru]

Maybe there is no need to change the internal representation of anything (after all, as long as the use is consistent, it doesn't matter what convention one uses to bother). For the (often painful) cases when this matters, I would advise the addition of helper function to get the angles in a unambiguous way, independently of the internal representation. According to mathworld, the naming could be e.g.

azimuth(s::Spherical) = s.θ
latitude(s::Spherical) = s.ϕ
colatitude(s::Spherical) = π - s.ϕ

[c42f]

An excellent point, thank you! Even simpler, I think we should just rename the internal fields to azimuth and colatitute, and be done with it. A getproperty implementation could provide a reasonable deprecation of the previous internal field names as aliases. The only issue is what to do with the constructor. I think we'd need to provide a keyword version during the transition and deprecate the positional args.

Actually I feel like this is a reasonable solution to the fundamental ambiguity in naming in symbols: simply use neither of the standard conventions :-)

In the future, we might consider re-introducing access to the internal fields via θ and ϕ, just documenting very clearly what the convention is.

[protogeezer]

I liked the suggestion to add an ISOSpherical type made last year by c42f - since I needed it for my own work I added it to a local copy of CT. If desired I can make a pull request. I was stymied earlier because the fork I made seems to be lacking the v0.5.1 tag. I'm not sure what I did wrong. Let me know how I can help!

[andyferris]

I just checked; all my physics and maths textbooks use what wikipedia calls the "ISO" standard. I'd suggest we change to that and add a picture to the README. :)

Personally I don't mind breaking changes so long as SemVer reflects this. Really these cooridnate systems were meant to be an "example" and perhaps helpful to people doing undergraduate excercises. But we can work around things with deprecations/name changes if people feel strongly.

[hcarlsso]

Wolfram have a summary table:

Given that the notation in greek letters as well as their order are sometimes similar sometimes not, I reckon any usage of greek letters will dissatisfy and surprise some people working in their own definition of spherical coordinates. However, both Wolfram and Wikipedia seems to have a consistent definition of a "polar angle" (measured from a fixed zenith direction), and "azimuthal angle" (orthogonal projection on a reference plane that passes through the origin and is orthogonal to the zenith, measured from a fixed reference direction on that plane). I would suggest skipping greek letters in the naming the fields and go for explicit descriptions, such as radius, azimuth, polar.

[wsshin]

I just started a project that heavily relies on the coordinate transformation between Cartesian and spherical, and I was glad to find out that this existing package already handles all the necessary transformations. However, I was very surprised by the convention of the spherical coordinate system adopted in this package.

I studied physics and mathematics in college and electrical engineering in grad school, and I have been working at the intersection of the three areas since then. Over the course of 25 years of education and career, I have never encountered conventions other than the ISO convention described in Wikipedia. Deviating from such a dominant convention will confuse many users...

If the dominance alone is not sufficient, maybe another reason to adopt the ISO convention is the spherical harmonics, the orthonormal basis functions Yₗᵐ(θ,ϕ) that span the function space defined on the unit sphere. They are an indispensable tool for studying functions and differential equations defined on the unit sphere. The θ and ϕ of the spherical harmonics follow the ISO convention. Using a convention other than ISO will diminish the usefulness of CoordinateTransformation.jl when used with the spherical harmonics.

Note that there are already Julia packages that incorporate the spherical harmonics, e.g., FastTransforms.jl and HarmonicOrthogonalPolynomials.jl (both from JuliaApproximation). It will be nice to have CoordinateTransformation.jl follow the same convention adopted in those packages.

[c42f]

This issue is stuck mainly on someone who cares about and needs this functionality doing the actual work. (I care about it, but don't need it ;-) )

If someone who needs it could implement an ISOSpherical coordinate type with radius, azimuth, polar field names (with greek aliases in getproperty) and make an ISOSphericalFromCartesian so we can cleanly deprecate Spherical, that would be amazing.

Certainly we can do some more renaming in 1.1 or something to recover the name Spherical for general use, but I can't see how to cleanly deprecate the Spherical positional constructor which expects a latitude.

[protogeezer]

I’ve implemented enough of an implementation of ISOSpherical for my use, so if that would help by passing it along, I will. What is the timeframe for the 1.1 release? Do I have to complete it (I think most of what’s missing are the conversions) before a pull request would be appropriate? Stephen aka the Protogeezer

…

On Jan 27, 2022, at 7:04 PM, Chris Foster ***@***.***> wrote: This issue is stuck mainly on someone who cares about and needs this functionality doing the actual work. (I care about it, but don't need it ;-) ) If someone who needs it could implement an ISOSpherical coordinate type with radius, azimuth, polar field names (with greek aliases in getproperty) and make an ISOSphericalFromCartesian so we can cleanly deprecate Spherical, that would be amazing. Certainly we can do some more renaming in 1.1 or something to recover the name Spherical for general use, but I can't see how to cleanly deprecate the Spherical positional constructor which expects a latitude. — Reply to this email directly, view it on GitHub <#25 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJLZFTFTTDCDVZ7FDFY3N3UYH2T3ANCNFSM4DC3FVUA>. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.

[c42f]

An early PR is welcome — just note what you think the TODOs might be in the description.

This package needs a new active maintainer so there's no concrete timeframe for releases right now. I'm semi-available to push out releases if people remind me, just can't promise to always be attentive...

[Ju-Rien]

I'm currently working on issue #85, and the question of convention is one that occupies me. I'm aiming to implement Wikipedia's Hyperspherical coordinates. Any pointers to conventions I should know about?

I'll make sure to document thoroughly whatever convention we end up choosing.

[protogeezer]

I have implemented enough of the so-called ISO version of spherical coordinates - not surprisingly called ISOSpherical - for the package. Adding that variant would eliminate the need to choose either the “Math” or “Physics” version of the spherical coordinates. If that is of interest, I can finish it as soon as possible and contribute it. Stephen On Aug 14, 2024, at 11:39 AM, Julien Corriveau-Trudel ***@***.***> wrote: I'm currently working on issue #85 <#85>, and the question of convention is one that occupies me. I'm aiming to implement Wikipedia's Hyperspherical coordinates <https://en.wikipedia.org/wiki/N-sphere#Spherical_coordinates>. Any pointers to conventions I should know about? I'll make sure to document thoroughly whatever convention we end up choosing. — Reply to this email directly, view it on GitHub <#25 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJLZFR56QNBGK3QXQBQKX3ZROI4XAVCNFSM6AAAAABMQZ3C4SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOBZGQZDSNZRGU>. You are receiving this because you commented.