Stream: ideas

Topic: trigonometry builtins or no?

Richard Feldman (Sep 26 2022 at 20:57):

https://www.computerenhance.com/p/turns-are-better-than-radians makes me wonder whether having (for example) Num.sin as a builtin is actually the best design, especially considering it's not going to use the native CPU instruction anyway (since it's faster to implement it in Zig - which could just as easily be Roc, since Roc has the same low-level arithmetic primitives as Zig)

Richard Feldman (Sep 26 2022 at 21:00):

the idea feels innately weird to me, but it could have some benefits:

• could have different userspace libraries built on radians vs turns, which could let some people go with what's familiar (radians) and others go with what's more performant (turns). This is harder to do if the stdlib provides a strong default, because the ecosystem will have a strong gravitational pull towards following that.
• less Zig code needed in the builtins speeds up compile times for everyone

Brendan Hansknecht (Sep 26 2022 at 22:42):

I don't think point 2 matters. If Num.sin could be performant in a roc library, we could just port it to a roc built-in instead of a zig built-in. That also reduces zig compile time while keeping it as a roc built-in.

Brendan Hansknecht (Sep 26 2022 at 22:42):

Otherwise, interesting idea, never heard of turns before. Feels crazy to do, but i can see how it makes sense

Anton (Sep 27 2022 at 07:58):

Unless people happen to read some blog post that talks about the two userspace libraries I don't think they'd be aware that both options exist.
If instead of the sin builtin we create sinRadians and sinTurns builtins I think users would be more likely to investigate this.

jan kili (Sep 27 2022 at 11:53):

Units are always nice, especially since that opens up the also useful Num.sinDegrees

Last updated: Jun 16 2026 at 16:19 UTC