See this discussion and the very nice paper they mention.
4 Likes
Thanks for that paper!
Since complex angles are not entirely impossible, I don’t see why I should limit the scope of an Angle to only real numbers. I agree that it’s not super-common, but why limit it to reals if there might be a few users that want/need these to be imaginary?
@Tamas_Papp While searching for complex angles I stumbled on that page, but saw only the first answer (which says what I was expecting), my fault. Thanks for pointing to that, very nice indeed!
Ok, there seems to be an interpretation (though it’s not widespread), but even interpreting complex numbers as hyperbolic angles, would you measure such “hyperbolic angles” in “degrees”?
If you were going to define most mathematical functions for a real type (in particular for AbstractFloat), you would automatically gain full support for complex numbers, because most complex functions in Julia standard library (except for special functions) are defined in terms of the real and imaginary part of the complex number. But probably this goes beyond the scope of this package.
For the record, this is what I do in Measurements.jl: the type defined in the package, Measurement, is subtype of AbstractFloat and I didn’t have to overload any complex-argument function, yet most complex functions happily accept Complex{Measurement} argument, including all trigonometric functions, both circular and hyperbolic.
Anyway, that was just a suggestion, I think I already extensively explained my point, I don’t want to push further the discussion, the package is your and the decision is up to you 
Thanks for pointing out what you did (I might bother you with questions on the details of how). I’m super grateful for any input anyone might have. I need it. Your way sounds cool, so I’m sure I’ll look into it. Thanks again!
Overall, I am fine with radians and multiples of π, so I wouldn’t, but for me the same applies to “real” angles. However, since the extension is basically costless, I would not hesitate to include it. It is hard to foresee all uses of a library, and when there are no tradeoffs, I would err on the side of generality.
The described solution for Measurements.jl is probably more useful.
Hmm, I added a “proportion” type to the Angle package (to complement and use the sinpi functions), but I now realize that I should have maybe named this new type “Multiple” instead… Thanks!
Done!
This way lies madness. For centuries, people argued about whether negative numbers are “physical”. Nowadays mathematicians prefer to ask whether something is applicable/useful and (or at least) logically consistent (so far as we know). Complex angles satisfy both of those tests.
For example, suppose you are integrating a function of angle (e.g. for a Fourier series) and you want to exploit the residue theorem, so you plug a complex angle (the location of a pole) into your function. Should it fail because you were representing your angles with an Angle type? Or because you were using degrees and call deg2rad somewhere?
I didn’t realize that; they should be. (define deg2rad and rad2deg for any Number by stevengj · Pull Request #22811 · JuliaLang/julia · GitHub)
1 Like
At least I don’t have problems with negative numbers
In Julia, making Angle <: Real wouldn’t prevent the use of Complex{Angle}, actually it might be even easier to work with complex quantities, so my proposal doesn’t limit anything 
Funnily enough, it was you who suggested me to make Measurement <: Real instead of Number just for this reason. I was wondering whether taking into account complex measurements, it turned out that in Julia it’s much easier to define the type as subtype of Real, support for complex numbers follows naturally 