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 math.tau #56554

Closed
ncoghlan opened this issue Jun 16, 2011 · 63 comments
Closed

Add math.tau #56554

ncoghlan opened this issue Jun 16, 2011 · 63 comments
Assignees
Labels
easy type-feature A feature request or enhancement

Comments

@ncoghlan
Copy link
Contributor

BPO 12345
Nosy @tim-one, @birkenfeld, @rhettinger, @pfalcon, @mdickinson, @ncoghlan, @abalkin, @vstinner, @benjaminp, @merwok, @asmeurer, @serhiy-storchaka, @vedgar, @Shredder13, @lisroach, @AraHaan
PRs
  • [3.6] bpo-34901 - add isolated (-I) flag to sys.flags (GH-9708) #9755
  • Files
  • tau.diff
  • tau2.diff
  • tau3.diff
  • tau4.diff
  • Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = 'https://github.com/gvanrossum'
    closed_at = <Date 2016-08-15.16:16:35.929>
    created_at = <Date 2011-06-16.03:10:29.721>
    labels = ['easy', 'type-feature']
    title = 'Add math.tau'
    updated_at = <Date 2018-10-08.22:18:18.242>
    user = 'https://github.com/ncoghlan'

    bugs.python.org fields:

    activity = <Date 2018-10-08.22:18:18.242>
    actor = 'danishprakash'
    assignee = 'gvanrossum'
    closed = True
    closed_date = <Date 2016-08-15.16:16:35.929>
    closer = 'gvanrossum'
    components = []
    creation = <Date 2011-06-16.03:10:29.721>
    creator = 'ncoghlan'
    dependencies = []
    files = ['44063', '44065', '44080', '44111']
    hgrepos = []
    issue_num = 12345
    keywords = ['patch', 'easy']
    message_count = 63.0
    messages = ['138412', '138414', '138416', '138419', '138421', '138422', '138423', '138431', '138548', '138551', '138553', '139338', '183004', '183198', '272287', '272299', '272301', '272304', '272319', '272325', '272373', '272374', '272375', '272376', '272377', '272422', '272457', '272465', '272467', '272469', '272470', '272472', '272473', '272476', '272478', '272483', '272484', '272485', '272487', '272493', '272505', '272507', '272509', '272533', '272555', '272561', '272566', '272592', '272598', '272601', '272617', '272618', '272627', '272671', '272679', '272682', '272714', '272770', '272775', '272777', '272802', '313664', '313668']
    nosy_count = 20.0
    nosy_names = ['tim.peters', 'georg.brandl', 'rhettinger', 'pfalcon', 'mark.dickinson', 'ncoghlan', 'belopolsky', 'vstinner', 'benjamin.peterson', 'stutzbach', 'eric.araujo', 'Aaron.Meurer', 'python-dev', 'serhiy.storchaka', 'waldir', 'xcombelle', 'veky', 'Nofar Schnider', 'lisroach', 'Decorater']
    pr_nums = ['9755']
    priority = 'normal'
    resolution = 'fixed'
    stage = 'commit review'
    status = 'closed'
    superseder = None
    type = 'enhancement'
    url = 'https://bugs.python.org/issue12345'
    versions = ['Python 3.6']

    @ncoghlan
    Copy link
    Contributor Author

    I'd like to add a new constant to the math module:

      tau = 2*math.pi

    Rather than repeating all the reasons for why tau makes more sense than pi as the fundamental circle constant, I'll just refer interested readers to http://tauday.com/

    @ncoghlan ncoghlan added easy type-feature A feature request or enhancement labels Jun 16, 2011
    @benjaminp
    Copy link
    Contributor

    Perhaps we should wait until \tau gains popularity larger than some impassioned physicist. \tau has been used to represent the golden ratio longer.

    @rhettinger
    Copy link
    Contributor

    -1

    @ncoghlan
    Copy link
    Contributor Author

    The golden ratio is more commonly denoted with phi (although tau does get used sometimes).

    Popularity isn't the point though, it's the fact that tau *makes geometric sense* in ways that 2*pi doesn't.

    @vstinner
    Copy link
    Member

    I like this issue number, but I don't think that Python needs this new constant: it's trivial to add it to your own project. We have pi and e, it's enough. If we begin to add a new constant, others will ask to add much more constants, and there are million of other constants (useful or not). You may want to create a library of some other common constants. You can use float.fromhex() to have a good accuracy.

    @pitrou
    Copy link
    Member

    pitrou commented Jun 16, 2011

    Nick, you just have to write: tau = 2 * math.pi
    and you're done.

    there are million of other constants

    Actually, I've heard there are an infinity of them.

    @vstinner
    Copy link
    Member

    Actually, I've heard there are an infinity of them.

    Can you prove that?

    @pitrou pitrou closed this as completed Jun 16, 2011
    @benjaminp
    Copy link
    Contributor

    2011/6/16 STINNER Victor <report@bugs.python.org>:

    STINNER Victor <victor.stinner@haypocalc.com> added the comment:

    > Actually, I've heard there are an infinity of them.

    Can you prove that?

    Don't have to. Axiom of infinity. :)

    @stutzbach
    Copy link
    Mannequin

    stutzbach mannequin commented Jun 17, 2011

    On Wed, Jun 15, 2011 at 8:10 PM, Nick Coghlan <report@bugs.python.org>wrote:

    I'd like to add a new constant to the math module:

    tau = 2*math.pi

    Rather than repeating all the reasons for why tau makes more sense than pi
    as the fundamental circle constant, I'll just refer interested readers to
    http://tauday.com/

    (The following is best if read aloud using your best pirate impression)

    I'd rather name the new constant "matey". Then we have:

    The circumference of a circle is: r matey
    The area of a circle is: one-quarter r r matey
    etc.

    @mdickinson
    Copy link
    Member

    Not to mention d(area of circle of radius r) = r dr matey.

    @birkenfeld
    Copy link
    Member

    http://tauday.com/

    And I thought putting "dx" directly next to the integral sign was audacious...

    @gvanrossum
    Copy link
    Member

    Uh, not until I've seen a lot more evidence that people are habitually writing "TAU = 2 * math.pi" in their programs...

    @waldir
    Copy link
    Mannequin

    waldir mannequin commented Feb 28, 2013

    Following-up sbaird's comment, I must point out that those aren't Python-specific results. Filtering them by appending &l=python to the urls yields:

    • "TAU = 2 * Math.PI": 6

    • "TAU = 2*Math.PI": 2

    • "TAU=2*Math.PI": 0

    • "TAU = Math.PI * 2": 0

    • "TAU = Math.PI*2": 2

    • "TAU=Math.PI*2": 1
      (total: 11)

    • "TAU = 2 * PI": 9

    • "TAU = 2*PI": 12

    • "TAU=2*PI": 0

    • "TAU = PI * 2": 2

    • "TAU = PI*2": 0

    • "TAU=PI*2": 0
      (total: 23)

    Then again, the results for all languages are still helpful to estimate the overall adoption of the notation in code, and indeed the global usage of these patterns (in github only) is in the hundreds.

    Also, it's worth taking a look at the usage of the twopi constant, which is already defined in several languages (http://en.wikipedia.org/w/index.php?oldid=509096802#Support_in_programming_languages), and has been manually defined in python quite often, proving its usefulness:

    @gvanrossum
    Copy link
    Member

    I'm just going to do this.

    @gvanrossum gvanrossum reopened this Aug 10, 2016
    @gvanrossum gvanrossum self-assigned this Aug 10, 2016
    @zware
    Copy link
    Member

    zware commented Aug 10, 2016

    Builds fine on Windows. Happily, math.tau == 2*math.pi is True.

    @gvanrossum
    Copy link
    Member

    OK, here's a diff with a test that math.tau ~~ 2*math.pi.

    @tim-one
    Copy link
    Member

    tim-one commented Aug 10, 2016

    Hmm. 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.

    @mdickinson
    Copy link
    Member

    I'd test that tau is exactly equal to 2*pi.

    +1

    @mdickinson
    Copy link
    Member

    At some point before 3.6, the docs should get updated, and cmath should get the tau constant too.

    @rhettinger
    Copy link
    Contributor

    Perhaps minds are already made up, but this may be the last chance to say that I think that this shouldn't go forward.

    • The push to use of "tau" has the flavor a political fad or wishful thinking that may or may not succeed. The math module should only implement established practice.

    • Since not everyone knows or uses tau, its use would tend to make code less clear. As a reviewer, I would ask that code like "from math import tau" to be changed to "from math import tau as twopi". The latter is more clear to most users (how many people would recognize "tau * r" when it occurs in the middle of a larger expression?).

    • I've surveyed engineers in my recent Python courses (often with Physics, EE, MaterialScience, DSP, or CompSci backgrounds and not a single one of them had heard of this constant).

    • If people really wanted this, we would be seeing more cases of "tau = 2.0 * math.pi" in code. Google searches and Github code search shows that this is very rare.

    • It is already trivial to write "tau=2.0*pi" so why bother?

    • Adding mysteriously named constants degrades the usability of the math module where many of the tools are currently self-evident but not all (
      tau is a number, gamma is a function, and what the heck is a frexp?).

    • Also, the name "tau" is already used for other purposes in various contexts (shear stress, proper time in relativity, torque, tau lepton, optical depth in astronomy, time contacts in RC circuits, etc).

    If needed, I can survey the audiences at the upcoming SF PyData conference and the SF PyBay conference to see if any of the participants have any clue what this is about and whether they would support the addition.

    @serhiy-storchaka
    Copy link
    Member

    +1 to Raymond.

    @gvanrossum
    Copy link
    Member

    Noted, but it doesn't change my decision. Obscure fact: did you know there
    are also branches of mathematics and engineering that define pi to for
    something else?

    @pitrou
    Copy link
    Member

    pitrou commented Aug 10, 2016

    Agreed with Raymond's arguments.

    @evelynmitchell
    Copy link
    Mannequin

    evelynmitchell mannequin commented Aug 10, 2016

    I also agree with Raymond's arguments. Adding tau doesn't add clarity to the math module, it just adds complexity.

    @gvanrossum
    Copy link
    Member

    Let those other libraries follow.

    @asmeurer
    Copy link
    Mannequin

    asmeurer mannequin commented Aug 11, 2016

    Emanuel Barry, that is both untrue and irrelevant (sorry to be blunt, but that's a total straw man on my and I believe other's argument). The fact that the only mathematical constants in math are pi and e (nan and inf aren't really "mathematical" constants) *does* indicate to me that only the really important ones are included.

    GvR, are you also in favor of adding more math constants/functions to the math module? I do see the value of Easter eggs in the language, but two real constants and one Easter egg constant seems weirder than ten real constants and one Easter egg constant. I'm +1/(2*pi) (because I still think tau in general is stupid) to add it if it also means the math module can be expanded. And before you ask, yes, I'll be happy to contribute once things move to GitHub.

    @gvanrossum
    Copy link
    Member

    FWIW I don't plan to have more constants there, at the current rate we'll
    be fine for centuries. :-)

    What worries me more is proposals to add Python functions to math...

    --Guido (mobile)

    @lisroach
    Copy link
    Contributor

    I've updated the test to assert tau is equal to 2*math.pi, as well as updated the docs and cmath.

    Let me know if I have made any errors!

    @mdickinson
    Copy link
    Member

    The unification of tau2.diff and tau3.diff LGTM; thanks, Lisa!

    My commit bit is broken at the moment; anyone in a position to apply those patches?

    @mdickinson
    Copy link
    Member

    BTW, if we're talking about useless constants in the math module, it's hard to get more useless than math.e: it's rare for e to turn up in formulas except in the form e**<something>, and the latter case is better catered for by the more accurate (and usually faster) expression exp(<something>. I'd even go so far as to call math.e worse than useless, since its presence leads people astray by encouraging them to write math.e**x instead of exp(x).

    To give just one example, on my machine, the result of exp(500) has an error of 0.42 ulps, while math.e**500 gives an error of over 150 ulps.

    @serhiy-storchaka
    Copy link
    Member

    To give just one example, on my machine, the result of exp(500) has an
    error of 0.42 ulps, while math.e**500 gives an error of over 150 ulps.

    How can it be? math.e**500 = math.exp(math.log(math.e)*500) and
    math.log(math.e) is 1.0.

    @vstinner
    Copy link
    Member

    math.e**500 = math.exp(math.log(math.e)*500)

    That's the theory if numbers have an infinite precision. In practice,
    intermediate results are rounded and have a limited precision.

    @tim-one
    Copy link
    Member

    tim-one commented Aug 12, 2016

    Serhiy's objection is a little subtler than that. The Python expression math.log(math.e) in fact yields exactly 1.0, so IF it were the case that x**y were implemented as

    math.exp(math.log(x) * y)

    THEN math.e**500 would be computed as math.exp(math.log(math.e) * 500) == math.exp(1.0 * 500) == math.exp(500.0).

    But that's not how x**y is implemented. Because the error in log() is multiplied by y, and then fed into exp() blowing it up even more, only a hopelessly naive library would implement pow() that way. In practice, library pow functions fake the effect of at least 15 more bits than native double precision to absorb these errors.

    Under the covers, then, a reasonable library pow computes math.log(math.e) to more than native double precision - and _that_ (internal, invisible) result is not 1.0. Because math.e isn't the mathematical e to begin with. The difference between math.e and the mathematical e is a difference quite visible to the internal log, which delivers an internal log not equal to 1, and its difference from 1 is "an error" multiplied by 500 and fed into the internal exp (blowing up the error even more).

    In the end, math.e500 returns a very good approximation to the true value, given that math.e is not e. There's no reason to hope that's close to exp(500), though - that delivers a very good approximation to e500 (where e is the true e). The larger the exponent, the more different math.ey should be from exp(y), and for the same fundamental reason 2y differs from 3**y (or plug in any other pair of distinct bases).

    All that said, I agree with Mark that math.e is at best an attractive nuisance. Still, I'm -1 on removing it - it's a traditional and universally embraced nuisance ;-)

    @pfalcon
    Copy link
    Mannequin

    pfalcon mannequin commented Aug 12, 2016

    What about rounding pi to 3 (and tau to 6)?

    https://en.wikipedia.org/wiki/Indiana_Pi_Bill (and I'm sure we can find a cute video about how cool to have pi as 3 to add it to the docs).

    @abalkin
    Copy link
    Member

    abalkin commented Aug 12, 2016

    All that said, I agree with Mark that math.e is at best an attractive nuisance.

    Why don't we fix the nuisance part without making it less attractive:

    class _E(float):
        def __pow__(self, other):
            if self is e:
                return exp(other)
            else:
                return pow(self, other)
    
    e = _E(2.718281828...)

    It's okay if Python occasionally shows its lighter side in unexpected places.

    I would rather see

    from math import π

    work in the future Pythons.

    I like Vi Hart, but I am firmly on the π side in the π vs. τ debate. The problem with τ is that it is visually smaller than π, actually twice smaller: π ≈ ττ, but the actual definition is the opposite.

    @xcombelle
    Copy link
    Mannequin

    xcombelle mannequin commented Aug 13, 2016

    Python will really follow the tau sort joke ? I never saw it mentioned in any serious math or programming document. All the github search result looks like people who are in this joke (kind of).

    The page http://tauday.com/state-of-the-tau list very little use of tau in relevant domains, the most relevant to our discussion would be the including of tau in modula-2 standard library.

    I don't see how the introduction of the unknown tau constant in python programs will make them clearer or better to the targeted public who will read them.

    I must confess however that 2*pi occurs frequently in formula and these formula would be simplified if tau was used. However an honest and non partisan web site would list all the use of pi without 2 where the formula would be more complicated. I don't see that so I'm still not convinced.

    I know that Guido van Rossum is the Benevolent dictator for life of python, but as I understand it until this point, the dictator position was used after all argument took place and not before.

    @vedgar
    Copy link
    Mannequin

    vedgar mannequin commented Aug 13, 2016

    However an honest and non partisan web site would list all the use of pi without 2 where the formula would be more complicated. I don't see that so I'm still not convinced.

    "non partisan" is probably hard to find, but if you want to see the other side of the story, http://www.thepimanifesto.com/ is probably most accessible.

    @birkenfeld
    Copy link
    Member

    Please folks. Stop taking this so seriously and remember that this is the language where you can type in

    >> import antigravity

    and it actually works. (Sort of.)

    @vedgar
    Copy link
    Mannequin

    vedgar mannequin commented Aug 13, 2016

    As an Easter egg, of course. I'm all for it. But please take a look at https://docs.python.org/3.5/search.html?q=antigravity&check_keywords=yes&area=default

    @AraHaan
    Copy link
    Mannequin

    AraHaan mannequin commented Aug 13, 2016

    not to mention I like to use the following expression myself.

    pie = 22 / 7  # because why not?
    tau = 2 * pie

    @pitrou
    Copy link
    Member

    pitrou commented Aug 14, 2016

    Unsubscribing from this ridiculous issue. Guido, do your thing.

    @yan12125
    Copy link
    Mannequin

    yan12125 mannequin commented Aug 14, 2016

    The documentation of tau should mention it's equal to 2 * pi.

    @vstinner
    Copy link
    Member

    Chi Hsuan Yen added the comment:

    The documentation of tau should mention it's equal to 2 * pi.

    According to this discussion, tau is very important. Maybe it's better to
    document pi as tau/2? :-)

    @yan12125
    Copy link
    Mannequin

    yan12125 mannequin commented Aug 14, 2016

    From http://tauday.com/

    No, really, pi is wrong...

    For me it's a sign that pi is (currently) more common than tau. One purpose of the documentation is helping newcomers understand what Python's built-in objects mean. "tau = 2 * pi" is better than "pi = tau / 2" as those who know pi only are more than those who know tau only.

    @lisroach
    Copy link
    Contributor

    I have added some more detail to the Tau documentation, including that Tau is 2 * pi, as well as some links to Tau Day and Vi Hart's video.

    That should give Python users enough to get started forming their own opinions on tau vs pi :)

    @gvanrossum
    Copy link
    Member

    Lisa, this LGTM. I'll commit it so we can put this behind us!

    @python-dev
    Copy link
    Mannequin

    python-dev mannequin commented Aug 15, 2016

    New changeset 68f2d6098be1 by Guido van Rossum in branch 'default':
    Issue bpo-12345: Add mathemathcal constant tau to math and cmath.
    https://hg.python.org/cpython/rev/68f2d6098be1

    @abalkin
    Copy link
    Member

    abalkin commented Aug 15, 2016

    There is a typo in the NEWS entry:

    "Issue bpo-12345: Add *mathemathcal* constant tau to math ..."

    @gvanrossum
    Copy link
    Member

    Thanks, fixed.

    @mdickinson
    Copy link
    Member

    Why does this issue keep ending up as the target of unrelated PR notifications?

    @serhiy-storchaka
    Copy link
    Member

    Because of its lucky number. See python/core-workflow#223 (fixed).

    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Labels
    easy type-feature A feature request or enhancement
    Projects
    None yet
    Development

    No branches or pull requests