Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add tau to racket/math #2180

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

add tau to racket/math #2180

wants to merge 1 commit into from

Conversation

willghatch
Copy link
Contributor

I want to add tau to racket/math.

For an in-depth look at why tau is better than pi, see the tau manifesto. The biggest obvious and practical benefit for Racket users is probably doing rotations and such. A quarter turn of an image is τ/4 rather than π/2, so you don't have to keep track of the extra factor of 2, or whether to multiply it or divide it.

The biggest potential problem is that people could already be using the name tau in modules using racket/math. Perhaps it would be better to use the unicode symbol τ, but that could also be used.

This PR isn't really ready. I haven't added documentation and I'm not really sure that this is the best way to calculate tau. But I want to float the idea and see what people think, especially of the naming issue.

@bennn
Copy link
Contributor

bennn commented Jul 22, 2018

If pkg-build doesn't report a name conflict, then my 2c is to go ahead and add tau to racket/math.

A safe alternative would be to make a new module, like racket/math/constants racket/math/constant or racket/math/extra. I don't dislike this alternative.

@LeifAndersen
Copy link
Member

I agree with Ben. I honestly don't care one way or the other about adding tau to racket, but if tau, then why not phi, e (besides in just mzlib, or exp), avagadro's constant, G, c, or one of the many many other super useful constants. At that point, it probably makes sense to put them in a 'constants' module. :)

@rfindler
Copy link
Member

If we're going to go crazy with these things, then somewhere in math is probably better. For tau, racket/math seems acceptable (pending the check suggested above).

Locally (researchwise), however, tau has a different meaning, that maybe we might worry about. :)

@soegaard
Copy link
Member

soegaard commented Jul 22, 2018 via email

@lexi-lambda
Copy link
Member

As a purely anecdotal data point, I was personally already familiar with the use of tau to mean “twice pi”, and I would personally find such a definition useful. Including that definition in the standard library of a programming language is rare, but it is also not completely unheard of: Python has included math.tau since version 3.6, and Processing includes a TAU constant.

@samth
Copy link
Member

samth commented Jul 23, 2018

tau seems very likely to be used in some module that also imports racket, since all of racket/math is already exported by racket.

@willghatch
Copy link
Contributor Author

I'm not terribly worried about modules that use #lang racket, since a user's definition or import of tau would shadow the module language import. But I can easily imagine many modules that (require racket/math) also define tau at the top-level, which would cause an error.

Honestly, I think it would be best to have a constants module that includes numbers like tau, pi, etc. The main reason I would want it in racket/math is that pi is already there. Essentially, I'm on a quixotic quest to put tau on equal standing with pi. Every time in my life that I've used pi, tau would have been easier to use as well as more revealing of the underlying mathematical concepts I was working with. I think it's a pedagogical slam dunk. But perhaps tau in a constants module and pi and tau having cross-references between each other in the documentation it would be just as good.

@LeifAndersen
Copy link
Member

Honestly, I suspect Pi being in racket/math rather than math is just a historical accident. If math existed earlier (and it wasn't a TR focused lib), it would probably have been in there. But ¯_(ツ)_/¯, I'm just as happy with racket/math/constants as I would be with math/constants.

@LiberalArtist
Copy link
Contributor

LiberalArtist commented Jul 28, 2018

In terms of "the best way to calculate tau", this observation is from the discussion of adding math.tau to Python:

I'd test that tau is exactly equal to 2*pi. All Python platforms (past, present, and plausible future ones) have binary C doubles, so the only difference between pi and 2*pi should be in the exponent (multiplication by 2 is exact). Else we screwed up one or both mantissas (typed the constant wrong, and/or the C compiler is rounding incorrectly) - which would be bad.

@mnieper
Copy link
Contributor

mnieper commented Oct 17, 2018

Being a professional mathematician, I can confirm that tau is not a well-established mathematical constant and that their is no major move in mathematics to replace (* 2 pi) with tau. To be honest, adding such a constant to the Racket standard library looks like nonsense to me.

@AlexKnauth
Copy link
Member

As a non-mathematician, but someone who occasionally programs games in Racket for fun, I often define tau, or sometimes turn, as (* 2 pi) and then use turn to do rotation and trigonometry calculations for the game. It's much easier to see that something is being rotated a 1/4 turn when it says (* 1/4 turn), and using tau (* 1/4 tau) is just as easy.

@soegaard
Copy link
Member

soegaard commented Oct 18, 2018 via email

@LiberalArtist
Copy link
Contributor

LiberalArtist commented Oct 18, 2018

I didn't explicitly say this earlier, but I was also previously familiar with tau and have written (define tau (* 2 pi)) in various programs. I have particularly heard about tau in pedagogical contexts, which resonates with Racket's roots.

I also see a practical benefit to including tau in #lang racket, rather than some library that must be imported specially. If the main benefit of having tau in the standard library is convenience (given that defining tao is trivial), having to write (require math/tau) (to take an extreme I don't think anyone is proposing) would provide little convenience over having to write (define tau (* 2 pi)). Including it in a module of other mathematical constants would be better, but I often want tau when I don't need other mathematical constants: especially, as @willghatch and @AlexKnauth have mentioned, for expressing rotations.

On the other hand, I do know tau has other meanings in other contexts. (What Greek letter doesn't?) I would mostly second @bennn's suggestion to try adding it and see what the impact actually is: if adding tau to racket/math doesn't break any existing packages, then it seems safe to me.

@LiberalArtist
Copy link
Contributor

As another point in the design space, the Elm standard library includes a function turns equivalent to (λ (x) (* tau x)).

@gfbee
Copy link

gfbee commented Mar 28, 2019

As a compromise, how about just naming it 2pi and/or ?

@willghatch
Copy link
Contributor Author

@LiberalArtist I think the turns function is a great idea. It is perhaps more convenient as a function than a value -- (turns 1/4) seems slightly easier than (* tau 1/4), I guess, and you rarely want to use tau/pi without multiplying it by some value. It seems like it might be better for name collisions as well, though I really have no idea.

@LeifAndersen
Copy link
Member

I mean, I frequently find myself wanting to multiply it by i...
https://en.wikipedia.org/wiki/Euler%27s_formula

@AlexKnauth
Copy link
Member

AlexKnauth commented Apr 3, 2019

Even when you're multiplying by i for Euler's formula, you'd probably be multiplying i·τ·x in most cases, so (* +i (turns x)) still fits, just one extra pair of parens relative to (* +i tau x).

@LeifAndersen
Copy link
Member

The point is that turns makes sense in a drawing library (like racket/draw. Much less so in a generic math library.)

@LeifAndersen
Copy link
Member

(By turns I mean the name turns.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.