Add constants based on Archimedes' original circle constant

[bugQ]

It's a little-known fact that Archimedes' original proof and calculations on the circle constant were not of π, i.e. the ratio of circumference to diameter, but of the ratio of circumference to radius, since the radius is the actual defining characteristic of the circle. It is therefore perplexing that he would then proceed to use π as the basis for many further proofs, a tradition carried forward by Leonard Euler.

Nonetheless, this isn't a math history lesson, just a very minor patch to rectify said history. The symbol τ has been promoted in recent years to represent the ratio mentioned (equal to 2π), having a variety of practical, aesthetic, and pedagogical benefits. If anyone is still curious as to why this is an issue at all, I encourage reading the Tau Manifesto at http://tauday.com, although I would be happy to answer questions myself.

[adrientetar]

http://www.thepimanifesto.com/

[bugQ]

I'd thank you to leave a more constructive comment. I will respond just as flippantly by refering to the Tau Manifesto once again, which has a complete rebuttal of all of the Pi Manifesto's relevant points.

[adrientetar]

It comes itself in response to that Tau thing, the point being that there's no sheer advantage to one or the other because there are formulas involving both in various domains. If anything, pi avoids having to divide by two in a number of formulas and most of all, it's what everyone uses.
So what's the point of Tau besides bikeshedding? The historical argument that Tau should be what's been used originally that makes most of your words does not sound convincing... yes things changed in more than 20 centuries, but why should we go back to B.C. tradition?

[bluss]

Please keep the discussion focused on why this is a good addition to Rust. It has a cost by increasing the size of the API -- without adding any utility, only (unproven) convenience.

[bugQ]

@adrientetar, the Tau Manifesto was updated last year with the aforementioned rebuttals. @blake2-ppc is correct that this is not the place for such rhetoric, as it's been talked to death elsewhere. That said, I would not submit this pull request if I did not think that it had value beyond a historical oddity.

The significance of τ to any programming language is simply in the intuitiveness of calculations involving radian measure. There are a growing number of practitioners, educators and students who have embraced it as the more natural and intuitive choice for practically every application, already finding use even in engineering and science publications. Again, I have no need of making this case here, as it is has already been laid out in considerable detail at http://tauday.com.

The patch contains almost no actual additional constants (aside from τ/3 ≡ 2π/3 and 1/τ ≡ 1/(2π) for completeness), and instead defines many of them in terms of their equivalencies, e.g. FRAC_2_TAU ≡ FRAC_1_PI. The documentation also makes clear the equivalence. There is no need for Rust to make any sort of stance on their relative usefulness to include them; in fact, it would be the most neutral stance to accommodate both. Programmers accustomed to π need not make any new life decisions, and project managers are also free to enforce the exclusive use of either constant in their style guide, although the equivalence is rudimentary.

If the primary remaining concern is API bloat, it is my understanding that dividing by powers of two is not only trivial, but preserves floating-point precision on all target platforms, and that many of the constants defined in f32 and f64 could be removed without significant inconvenience. Assuming Rust already optimizes inline literal arithmetic (of which I am not certain), removing all circle constants but τ ≡ 2π, π ≡ τ/2, τ/3 ≡ 2π/3, π/3 ≡ τ/6, 1/τ ≡ 1/(2π), and 1/π ≡ 2/τ (that's 12 constants, 6 equivalence pairs) would not visibly add programmer inconvenience nor runtime inefficiency, and may instead make trigonometric calculations clearer and more intuitive for users of either constant family. The constant FRAC_2_SQRTPI := 2/√π could be retained if desired, although I have come to understand that it is merely a holdover from C99's "math.h", for use in the already available error functions erf() and erfc(). Most of the factors/multiples of 2 also appear to be holdovers.

I already considered making the above changes, but decided I would defer to opinion first.

[lilyball]

I see no problem with adding tau. Adding extra API normally carries the cost of maintenance, but these aren't functions/types, they're constants that are, well, constant. They'll never change.

[bugQ]

Thanks for the input @kballard. Nevertheless, do you have any thoughts about trimming down the list of constants? I just confirmed with #rust that LLVM has very good constant folding, so it's likely that the only issue with removing some powers-of-two redundancy would be their use in existing code. Would that constitute excessive refactoring (whether within or without Rust itself)?

[lilyball]

I don't know. I'm not sure why we have so many constants for this. In C (in math.h), there's M_PI/M_PI_2/M_2_PI`/etc but we have even more than C does.

[brson]

I'm not particularly opposed to adding tau, since as @kballard says there's not a lot of overhead to doing so, and there seems to be a growing consensus about its usefulness. If we do that we should recognize and understand the ideological implications (there's no 'need' for tau in std).

I agree there are too many constants here.

I know @nikomatsakis is a tau fan.

[bugQ]

Alright, since the verdict is "too many constants", I made some very aggressive cuts, removing every factor of 2, resulting in fewer constants than we started with. Factors of 3 remain in order to avoid a slight rounding error that occurs in double precision. Recreating any of the missing values such as FRAC_PI_6 is of course very simple (FRAC_PI_3 / 2.0).

I split the removals into two commits so that the last commit can be cherry-picked out of the merge if it's deemed too aggressive. I did however note that none of the multiples or divisions of π are even used anywhere in this codebase, only Float::pi() itself (or more commonly, in many of the tests, a locally defined approximation of π, for some reason).

I also removed FRAC_2_SQRTPI, because as mentioned previously, it seems to be defined by C99 only for use in the Gaussian error function, which is implemented by erf() (and its complement erfc()). This function is not currently exposed by the Rust API, but it would be trivial to expose if it found relevance to Rust users. I would instead be in favor of adding SQRTPI, SQRTTAU, FRAC_1_SQRTPI and FRAC_1_SQRTTAU, in order to cover the majority of uses of the circle constant in formulas, but that's not really in the scope of this ticket.

[huonw]

In several years of tertiary mathematics education (at universities on both sides of the world) I've never seen anyone use τ = 2π in reality.

I would mildly prefer that we wait a while before adding such constants, as it would be weird for Rust to be left with these TAU constants forever if the use of τ is a fad (I'm not saying it is fad, just talking about the possibility that it is one; modern use of τ is very recent and π is deeply entrenched in the current technical world).

That said, I don't have strong objections.

[alexchandel]

There is zero mathematical consensus that τ is more useful. If there were, or if the issue were even being debated, one would expect a search of a reputable journal to yield a single journal article about tau. But this is not the case. There is not a single mention of replacing pi or using tau. Moreover, the first page of articles in both the "tau" and "tau pi" search results all use π!

And π is more fundamental anyways. The general, n-dimensional formula for the volume of an n-ball is V_n = π^(n/2) / Γ(n/2 + 1) * R^n. For the first few n, the constant before R^n is (V_1, V_2, V_3, V_4) = (2, π, 4π/3, π^2/2). The boundary of the n-ball, the (n-1)-sphere, has an (n-1)-volume equal to the derivative of this volume with respect to R, and is S_(n-1) = n π^(n/2) / Γ(n/2 + 1) * R^(n-1). For the first few n, the constant before R^(n-1) is (S_0, S_1, S_2, S_3) = (2, 2π, 4π, 2π^2). Notice that τ only helps in a single dimensional case, and only with area. And when rewritten with τ, the general equations gain a factor of 2^(n/2) to cancel out τ's stupid 2, and become too ugly to write.

If Rust were to add "TAU_*" constants, we'd become "that language with tau". These constants would be used by no one: not engineers, not scientists, not mathematicians, just people who follow the Tau Manifesto. I would be dismayed if Rust joined the τ-people, or even commented on such a marginal issue. It would be like if MIT started giving equal time to phlogiston theory in their freshmen chemistry classes, or equal time to intelligent design in their biology classes, out of respect for the controversy. When the Journal of Mathematical Physics publishes a secondary analysis acknowledging the usefulness/betterness of τ (or even a single damn article about it), let me know. Until then, keep it out of Rust. π is more fundamental, and is used by actual mathematicians and scientists. Let's not fan this flame.

[steveklabnik]

I am also pretty 👎 on Tau.

[adrientetar]

In several years of tertiary mathematics education (at universities on both sides of the world) I've never seen anyone use τ = 2π in reality.

In one year of Mathematics and Engineering, I haven't heard about that either.

[bugQ]

@alexchandel I do wish more people would choose to spend as much time reading this very comprehensive, easily digested and repeatedly linked manifesto as they do making arguments in ignorance of it. Since this is apparently the forum for such arguments now, though, I'd be happy to oblige:

It's actually true that τ is not particularly fundamental to n-ball geometry, but neither is π. Section 5 of the article decomposes the Gamma function in the n-ball volume formula to find that the fundamental constant behind it is actually the measure of a right angle, τ/4 = π/2. This makes geometric sense, since every new dimension added to the n-space is orthogonal to the last. Nonetheless, it seems much sillier to suggest that we use that number in every formula than either π or τ. In fact, the entire above argument is a red herring; the fact remains that τ is the most fundamental number with respect to the circle (2-ball), which is precisely why it lends itself to more natural radian representations than π. The constant we are debating is called the circle constant, after all.

Frankly, it's insulting to compare this idea, something that should just be mathematical common sense, to things like phlogiston theory, but not as degrading as hearing the same flawed arguments about π's specialness repeatedly. I do however accept the dilemma that Rust might not be ready to accept τ until wider acceptance is reached elsewhere (re: @huonw). I also realize that examples of this may be difficult to find, even if they do exist (and yes, even in reputable journals). That's precisely why I had hoped to appeal to logic and intuition, rather than sentiment and politics, although I perhaps overestimated the patience of other people to simply read the manifesto and let it do the talking for me.

Either way, putting this merge on hold is understandable. I can wait.

[steveklabnik]

Anyone who wants Tau and Tau-based math can write a Cargo package for it.

[adrientetar]

logic and intuition, rather than sentiment and politics

It's just a constant, there's not much logic behind the scenes. Likewise my intuition is what's been taught to me at school: pi. As the pi manifesto shows, there is also a handful of formulas that are better expressed with pi so that's just a matter of cherry-picking.

[bugQ]

@steveklabnik Unlikely; most would simply put the following in their global/module space:

static TAU: f64 = Float::two_pi();

This alone is adequate for most practical uses, uses exactly as many lines as including a package, and shouldn't conflict with other modules. Since it is already necessary to go through the helper functions in Float and supply a type annotation to get to the constants, it's fairly arbitrary what they are named by the programmer. Admittedly, this largely explains why I am not particularly attached to this merge; the only advantage would be a standardized location for the constant. If acceptance reaches critical mass through independent means, then I'm sure this topic will come up again.

My only disappointment is in the poor rhetoric displayed here. I'm growing a little tired of it...

[alexchandel]

@bugQ I've read that before, and the section in the Tau Manifesto you reference doesn't make your case. It begins by replacing Gamma, a uniquely constrained meromorphic function, with the discontinuous floor function, the almost-nowhere-defined double factorial, a 2^n, and a piecewise factor. It manages to eliminates the piecewise factor by substituting in pi/2, a smart move. It then asserts V[n] == S[n-1] / n, therefore τ is preferred (even though this rule fails to give the volume of a 0-ball). But I can just as easily say that S[n-1] == V_n * n, therefore π is preferred (and mine does give the volume of a 0-ball, since it begins with V's). So this route of argument is moot. In either case, it's clear that this isn't "mathematical common sense". A Cargo package for all the TAU_* constants or a variable like "static TAU: f64 = Float::two_pi();" addresses any minority needs.

[bugQ]

@alexchandel You apparently ignored everything I wrote after the words "Section 5". I suppose it's too much to ask to read both; it's only either one or the other at a time. You'll note that I already explained that this particular line of argumentation is irrelevant to the purpose of introducing τ in the first place. Please let sleeping dogs lie.

[alexchandel]

@bugQ There's no need to be combative; this is a courteous, listening community. You said that my point was refuted in the Tau Manifesto, and I showed this wasn't the case. Dismissing my point as irrelevant isn't correct either: You emphasize the 2-dimensional embedding, and argue τ is the fundamental circle constant, being the ratio of S_1 to r^1. I could just as easily argue that π is the fundamental circle constant, being the ratio of V_2 to r^2. But both of these numbers have meaning beyond the 2D case, and when you derive the general formulae, all of the integrals except the first are from 0 to π, and the end results are simplest with π. I would disagree that π/2 is simpler, since that requires replacing the Γ with a floor, a !!, and a 2^n. I expect most mathematicians would argue that Γ has greater mathematical beauty than the double factorial; it's certainly simpler.
As I said before, no one would object to a τ Cargo package, and it might help those who use τ for angles. It would certainly increase the footprint of the language in a noncontroversial fashion. Feel free to make one.

[lilyball]

@alexchandel Can you please drop this? @bugQ has already closed this issue and stated multiple times that he's ok with waiting for more widespread traction before trying to get TAU into Rust, and that he wants this issue to be put to rest.

[alexchandel]

fine by me. Edit to avoid email spam. @bugQ if you want to continue our conversation, want to repost at alexchandel/wall?

[bugQ]

Actually, I feel like I deserve @alexchandel an explanation, since the answer to their question is apparently subtle. As I said before (twice), you are correct that the generalizations of S and V do not reveal any aesthetic preference for either τ or π, but they do reveal a point against π: that its importance is incidental, rather than fundamental. The underlying reason is quite simple: as long as π is defined by a circle's diameter, it remains incongruous with the entirety of geometry. In fact, I can't think of a single formula outside of the definition π = C/d that forgoes r in favor of d. This simple fact is what underlies every single failing of π, from calculus to particle physics. I would encourage you to reread Section 5.2 (and perhaps the others as well) with that in mind.

There is one last ray of hope, though: it follows that π would finally earn its stars if we were to define circles in a way that employed the diameter in a non-trivial way and endeavored to use d in place of r in all of geometry. Disregarding the havok it would wreak on the concept of "radians" and who knows what else, I submit that even if such a non-trivial use of d were found, it would not match the simplicity of the current definition. Either way, the far easier method of resolving this incongruency is to replace the circle constant, instead of r.

[JonasOlson]

@bugQ

Nevertheless, do you have any thoughts about trimming down the list of constants?

We could remove PI. :-)

[bugQ]

oh goodness. this PR is embarrassing. please leave it be.

Not that I wouldn't still like to see the constant introduced, but I'd hope whoever does would have better decorum than the me of 3 years ago.

[steveklabnik]

please leave it be.

I can do that!