Pi day is dead, long live Tau day

[David O'Meara]

Amusing, but I think the strongest argument is that if you follow this you get to eat two pies.

[Matthew Brown]

"Mathematics should be as elegant and simple as possible"

is about as elegant as it gets.

[Jesper de Jong]

Did you see the whole video - you could write this using tau as which looks as least as elegant as the version with pi.

[Matthew Brown]

Jesper de Jong wrote:Did you see the whole video - you could write this using tau as which looks as least as elegant as the version with pi.

Ah, no, sorry. I bailed out about half way through.

[David O'Meara]

yes, and you get two pies.

[Ernest Friedman-Hill]

Vi Hart is just way beyond awesome.

[fred rosenberger]

Jesper de Jong wrote:Did you see the whole video - you could write this using tau as which looks as least as elegant as the version with pi.

I think the point is that the first version uses five...note sure of the term...basic numbers:

e - natural logarithm base
i - square root of -1
pi - base circle constant
1 - multiplicative identity
0 - additive identity

Also, it uses one multiplication, one addition, and one power.

your new version only has 4, missing the additive identity. Yes, you could move the 1 to the other side, but now you're either adding -1 or subtracting +1, which either changed the addition to a subtraction, or changes the 1 to -1.

I can't watch the video at work, but I'm looking forward to it once I get home.

To me, the most exciting part about this is that it gets people to talk about math - something far too many people are loath to do.

[edit] I've had a chance to read more of the tauday.com web page, and see that he gets around this by making it

e^(i*tau) = 1 + 0

but I claim that is a cheat/hack. why not make it

e^(i*tau) + 0 = 1

or even

e^(i*tau) = 1 + 0 + 0 + 0 + 0 + 0 + 0 + 0 + 0 + 0 + 0 + 0 + 0 + 0 + 0

The original version (with pi) requires a zero. Yes, you could move the +1 to a -1 on the other side, but then you loose both the addition and the positive 1.

[Mike Simmons]

Really? I guess this all comes down to personal taste, but really, I think the presence of a + or 0 in the original Euler identity are easily the least interesting things about that formula, by several orders of magnitude. And the proposed tau form looks, frankly, simpler to me, which I think is more of a virtue than having a + or 0 is.

Regardless, how often do we need to write out the Euler identity? And in comparison, how many times do we write out 2π when we could have written τ instead? I think the tau proposal does a nice job of removing clutter from cases that are far more commonly used than the Euler identity.

[paul wheaton]

It could be fun to do something with the moose for june 28.

[Campbell Ritchie]

Would I believe anybody who uses canned fruit in her pies? I don't bake fruit pie this time of year; I reserve that for the Autumn and early Winter when I can get decent apples from the tree at the end of my garden

[Pat Farrell]

Speaking of semi-close approximations of pi, I asked this of my Java 108 class last week:


6. What is the value of number after the following is executed
double number = (1/7)*22;

A majority of my students got it wrong. Don't know if that reflects on them or on me.

[Jesper de Jong]

I'm reading the Dutch version of the book Alex's Adventures in NumberLand. An interesting book about the history of mathematics etc.

Ofcourse there's also something about π in that book. One thing that astonished me was Ramanujan's formula for π:



This series converges very rapidly. Ramanujan was a genius with an incredible intuition for numbers, who unfortunately died young.

What I find so intriguing about this is: how did he discover this formula? It isn't a simple formula, it shows that he indeed had an incredible insight into numbers.

[Mike Simmons]

Pat Farrell wrote:A majority of my students got it wrong. Don't know if that reflects on them or on me.

Eh, I'd blame Java, for mimicking C. Who probably got it from Algol or somewhere. But in my opinion, these languages make it too easy for people to use integer division (truncating) without realizing it. If it were up to me, the result of the division of two ints would be a real, by default, and if you want something else you should have to say so explicitly. Perhaps a new operator like # could be introduced to indicate truncating integer division when you actually want it:

1 / 3 --> 0.33333333333

1 # 3 --> 0

Sorry, the pi vs tau discussion has me in the mood to redefine things so they make more sense. Good question for your students, though.

[Stephan van Hulst]

While I would probably enjoy working with Tau, I have to disagree about the division operator :P

If # were to be used for integer division, most of my programs would end up using # over /. I think / is more clear, especially when you look from a discrete math point of view.

[Pat Farrell]

Mike Simmons wrote:Eh, I'd blame Java, for mimicking C. Who probably got it from Algol or somewhere.

Its been too long since I did any Algol to be sure, but I think there were no implicit conversions in Algol.

Java clearly got it from C. Since C is really just PDP-11 assembly language, it may have started there. In C, one doesn't use any stinking floating point numbers. I mean, everything is either a byte or an int, and we fake it from there.

Back slightly on topic, in all the years I wrote C, I never once used anything like the value of pi.

[Mike Simmons]

Thanks, Pat. I never used Algol; I just know C is in the Algol family, so figured it could have been a precedent for this behavior.

Looking through Google results a bit more - it seems that Fortran used the same sort of integer division, which sounds familiar. (I did use that a bit, but don't remember much about the details.) As for Algol, it seems the symbol ÷ was used for "integer division", but I didn't find a clear description of what this meant.

I suspect you're right that the idea of division by truncation derived from basic assembly instructions in some commonly-used system, whether PDP-11 or something earlier. Though I'm still a bit surprised that more conventional rounding (e.g. 1/3 --> 1, 2/3 --> 1) never seems to have been used by these early systems.

Stephan van Hulst wrote:If # were to be used for integer division, most of my programs would end up using # over /.

Hmmm, really? For me it seems very much the other way around. Perhaps it's our respective backgrounds: I studied physics and engineering in school, and most of my early programming was to perform calculations for those disciplines. Whereas I see you're studying computer science. Perhaps the problems I was given were biased towards real numbers, while yours were biased towards integers? I wonder which seems more natural to people coming from other backgrounds.

Stephan van Hulst wrote:I think / is more clear, especially when you look from a discrete math point of view.

Does discrete mathematics not include rational numbers? I don't remember ever being taught that 1/3 = 0 was an acceptable answer. Until computer programming, when I was taught that's simply what you get, regardless of whether it makes sense. But to the rest of the mathematically-inclined world (as far as I know), 1/3 is a ratio, very much NOT equal to 0. And 0.3333333333 is not exactly equal to 1/3, but it's at least a fairly close approximation, much better than 0 or 1. How does 1/3 = 0 make sense in general? I would certainly agree that's it's what you want, sometimes. But I don't see how it makes more sense than 0.3333333333, as a default. And if the result must be an int, in general I am just as likely to want Math.floor() as Math.ceil() or Math.round(). (And yes, I know none of these exactly maps to integer conversion when both positive and negative values are considered, but I'm ignoring that extra messiness as beside the point.)

I think it made sense in earlier days of computing, when people were striving to minimize execution time and/or memory use. Having an operation between ints result in a double must have seemed wasteful. But nowadays, I think those concerns are much reduced, and having an intuitively correct result, as a default, is much more valuable than having a fast or compact result is. Perhaps it's just me. But I'm a bit dismayed that the programming world still seems enamored of the division-by-truncation paradigm.

(And I feel much the same about numeric overflow being silently ignored when using ints. That's another discussion, but most of my arguments are the same in spirit, if not in detail.)

[Mike Simmons]

Back to the original topic: in order for tau to catch on (as it should!), someone really needs to make a Tau Song in the vein of this classic.

[Stephan van Hulst]

Mike Simmons wrote:Hmmm, really? For me it seems very much the other way around. Perhaps it's our respective backgrounds: I studied physics and engineering in school, and most of my early programming was to perform calculations for those disciplines. Whereas I see you're studying computer science. Perhaps the problems I was given were biased towards real numbers, while yours were biased towards integers?

Yeah, this is most likely the case.

Does discrete mathematics not include rational numbers? I don't remember ever being taught that 1/3 = 0 was an acceptable answer. Until computer programming, when I was taught that's simply what you get, regardless of whether it makes sense. But to the rest of the mathematically-inclined world (as far as I know), 1/3 is a ratio, very much NOT equal to 0. And 0.3333333333 is not exactly equal to 1/3, but it's at least a fairly close approximation, much better than 0 or 1. How does 1/3 = 0 make sense in general? I would certainly agree that's it's what you want, sometimes. But I don't see how it makes more sense than 0.3333333333, as a default. And if the result must be an int, in general I am just as likely to want Math.floor() as Math.ceil() or Math.round(). (And yes, I know none of these exactly maps to integer conversion when both positive and negative values are considered, but I'm ignoring that extra messiness as beside the point.)

Discrete mathematics does indeed include rational numbers, like 1/3. However, if you want to continue to do any work on this value in the discrete realm, you usually have to work with the quotient and the remainder.
I think casting one of the values to a floating point number in order to shift the calculation out of the discrete realm is preferable to defining a whole new operator to get the quotient of a fraction. But again, as you pointed out, this is probably because of our respective backgrounds.

(And I feel much the same about numeric overflow being silently ignored when using ints. That's another discussion, but most of my arguments are the same in spirit, if not in detail.)

I fully agree with you there. I don't think arithmetic operators should be allowed to overflow silently.

[Hussein Baghdadi]

The sound of Pi
http://www.youtube.com/watch?v=iOjsRyxL7Rs

[Jesper de Jong]

Happy Tau Day!

[Stephan van Hulst]

[fred rosenberger]

what Tau sounds like

Note: I can't access youTube from work, so I have no idea what this is. I found it on the tauday web site.

[Jesper de Jong]

It actually sounds like a real, relaxed piece of music. Not just some wild sequence of notes.

[Pat Farrell]

I'm against Tau. I'm in the PI is great religion.

Sure, for something things, you can trivially s/2 pi/tau/ not not always.
How are you going to have a nice clean formula for the area of a circle? With PI, its easy

 area = Math.pi * r * r;      // pi r^2

How do you do this cleanly with tau?

 Math.tau/2.0d * r * r;

You call that clean?

Most of the examples given about how "better" tau is show it as limits to an integral. What is more fundamental to integration than the area of a circle? Integration is all about areas.

I say Fooey to Tau.

[Mike Simmons]

Pat Farrell wrote:I say Phooey to Tau.

Fixed.

[Mike Simmons]

(I was wearing my Tau Day Shirt at work today. So you know where I stand.)