I have experimented with Abstracts for Radians but it’s not an easy thing to get right and I feel that Haxe could easily put a bit more focus on Maths support generally like the miss opportunity with operators on abstracts, given the strong Game developer user base it seems very sensible that Haxe could have a Radian class, perhaps even a Radian16 Radian32 Radian64 !
The concept is that Radians would be a Type in just the same way as Float this would make working with angles much simpler and robust within Haxe and save many hours spent with strange angle bugs!
If we consider Maths as part of nature then it make sense to consider how Haxe can make it simpler to work with Maths, beyond just providing Sine and Cosine, and I think a first step would be a basic Radian type.
I have not added this to evolution because I don’t yet know the best implementation.
If you want to avoid passing any random numbers you can do:
abstract Radian(Float){
public inline function new (value:Float) this = value;
public inline function toDegree() return this * 180 / Math.PI;
@:op(A + B) inline function add(b:Radian):Radian;
@:op(A - B) inline function sub(b:Radian):Radian;
@:op(A / B) inline function div(b:Float):Radian;
@:op(A * B) inline function mul(b:Float):Radian;
}
use this as parameter in your functions and have the +-/* operators on it.
I think you missed my real point, conversion to degrees is fairly simple, the problem is the wrapping behaviour.
So for instance ideally you would want to be able to choose to limit the between different ranges:
-π -> π
0 -> 2 π
-2 π -> 0
I have experimented and even had it so you could specify as a fraction of pi but that’s probably rather obtuse and will likely change.
But the point is really to have an approach where operations with angles don’t end up being rather convoluted because regularly people do stuff like add angles and then have logic to rationalize them to a number. Floats are really not a useful fit, you can’t tween around an angle simply. Now many here will consider it trivial but they forget how much time was wasted working with floats when we could work with a radian basic that wraps cleanly so that angles are always valid.
My proposal is to add an optimised approach to Radians to the core library, we seem to think this is a library issue, but angles are at the very core of programming games, science software, statistics probably etc…api graphics, movement and if they are not standard then every framework and toolkit reinvents dealing with them.
From a code view point a Wrapped Float might make more sense but really mostly we only care about Angles and only Radians- since that is the natural measure implicit in Maths and the way nature ( and graphics work ).
Degrees should not be taught in schools to begin with as they are a completely contrived concept, so while conversion function should be provided for simplicity, a generalized Wrapped Float is not really a vital abstraction, it’s far more important that Radians are fast and efficient to use, or at least mostly fast enough perhaps using some macros to cheat some extra speed where possible.
While we can copy features of other programming languages something like adding Radians if implemented really well help to continue to set Haxe apart. We need to consider the language from pragmatic users perspective and to me Radians [a wrapping Float] seems a really valuable detail.
Yes completely I was wondering why a radian class was useful.
While indeed it looks nice I’m not sure if it should be in the std,
lately its goal is only the core stuff, that’s why several classes have been moved out of the std for haxe 4.
I was wondering why a radian class was useful.