I was wondering if adding tau (= 2π) to the kotlin.math package was considered? A few languages have added it in the recent years, like Python and Rust.
Why? Because this constant is needed very often, sometimes even more than pi. In fact nearly every piece of code that needs PI eventually needs 2.0 * PI.
There are many arguments on why tau makes more sense from a mathematical perspective, most can be seen on https://tauday.com/. However, counter arguments (http://www.thepimanifesto.com/) are just as good. Proving which side of the debate is right is not the point here. The point is that it would be convenient, because every second project eventually needs it to define it globally.
2 Likes
The only argument to have it is a possible performance improvement. I use it as well in some projects, but I never measured if it actually gives something in JVM (it is possible that JIT is smart enough to inline and remember the value). If you could make some benchmarks to prove that it actually improves something, it would be nice.
1 Like
I would be extremely surprised if using TAU instead of 2 * PI has any measureable performance impact. Especially since PI is a constant so the kotlin compiler(I’m not actually sure if the kotlin compiler simplifies numerical expressions that only contain constants) or the JIT compiler will just calculate that expression once.
I think if you want to argue about including TAU it is mostly a readability argument. Some people/teams might prefer TAU. That alone might be reason enough to add it. But then you could also argue that it will decrease the readability because formulas normally are written using PI instead and less people are familiar with TAU.
2 Likes
I’ve introduced it only for performance.Actually never seen it used in papers or books in my area.
The greek letter tau is commonly used for many different things in different fields. It’s definition as 2*PI is not nearly as universal as the definition if PI itself.
To avoid the ambiguity of using the symbol “tau”, I suggest that we adopt a different syntax for this constant that makes it clear what is meant, even in fields where “tau” has a different common definition. I suggest (2.0*PI)
We thought about introducing TAU constant along with PI when designing kotlin.math package, but considered it was not so widespread to justify its inclusion.
The point is that it would be convenient, because every second project eventually needs it to define it globally.
If that’s the case and you can somehow prove that it’s needed to every second project (that works with math), maybe we should reconsider this decision.
1 Like
If that’s the case and you can somehow prove that it’s needed to every second project (that works with math)
I don’t have a lot of examples to prove my point unfortunately. Here’s what I have on github, both cases and very similar, it’s for working with radians:
Other than that if you look at Python (which introduced math.tau in 3.6), there’s 16k usages of math.tau and 338k usages of math.pi on Github.
I suggest that we adopt a different syntax for this constant that makes it clear what is meant, even in fields where “tau” has a different common definition. I suggest (2.0*PI)
So you suggest not adding it? Because that’s already the syntax to make 2π/tau. Also I don’t really like something like kotlin.math.PI_2, but I guess it’s better than nothing.
I would agree that a lot of projects need the concept of 2π, but doubt seriously that many of them would know that there exists a constant that is equal to this value (I certainly didn’t). Consider if you asked some number of people, “how do you compute the area of a circle?”. I am quite sure that 99% of the people will come up with 2π r and not τr.
It wouldn’t really hurt anything to add it, but I doubt it would be used very often.
1 Like