Closed mileslucas closed 2 years ago
yeah, thanks for taking a look- no worries about the delay!
I wondered whether you could get away with a super simple Degrees{T} wrapper number type for the A parameter of Polar, rather than making a new type.
I definitely think this is the correct approach for a more thorough implementation that includes degree-based coordinates for the cylindrical and spherical coordinates, too. I really only want Polard
for my package, so I tried writing something up that would be the least breaking/touch the least code.
Using Unitful is definitely valid, but I don't necessarily want to bundle that with my package or make it a soft-dependency (not bundled but basically required). Also I don't think there's a good way to go from cartesian to Polard
using Unitful. Overall Polard
is definitely just a quality of life improvement, but hey, it's simple enough that I think it was worth making the PR :)
this adds the
Polard
type which is a polar representation using degrees instead of radians. Internally the angle is stored as a degree and converted to radians before calculating conversions.Internally, this adds an abstract
PolarType
and anangle
function. Correspondinglyisapprox
has been updated to work with both types and conversion methods have been written for both.Additionally, I've altered the
PolarFromCartesian
struct to have a type parameter for the polar type. The singletonsPolarFromCartesian()
andPolardFromCartesian()
dispatch to this and the conversion functions and jacobians have been updated.Unit tests have been added and I took the liberty of adding some helper functions to tidy up the jacobian testing. I've added a blip in the README and also bumped the version to
0.6.2
.