Search All of the Math Forum:
Views expressed in these public forums are not endorsed by
NCTM or The Math Forum.


Math Forum
»
Discussions
»
sci.math.*
»
sci.math
Notice: We are no longer accepting new posts, but the forums will continue to be readable.
Topic:
The Reason Why Tau Is Fundamental And Why Pi Is Not
Replies:
2
Last Post:
Jan 7, 2013 4:46 PM



Kaba
Posts:
289
Registered:
5/23/11


Re: The Reason Why Tau Is Fundamental And Why Pi Is Not
Posted:
Jan 7, 2013 4:46 PM


7.1.2013 22:00, Jesse F. Hughes wrote: >> That said, in my opinion the article makes a good case in favor of >> adopting tau instead of pi. The mathematics is anyway objective, even if >> described subjectively. > > It's all a matter of convention. Whether, as it happens, it's somewhat > more convenient to use 2pi as a constant, rather than pi, surely is one > of the least interesting mathematical points one can make, barely better > than insisting that the numeral seven ought to have a crossbar to better > distinguish it from one.
Essentially, you are making the claim that syntax does not matter.
<rant>
To see the significance of syntax, you have to pick a field where the effects of bad syntax are amplified so much that making progress beyond a given point becomes impossible. This then gives perspective also for the smaller scale (mathematics). That field is software engineering.
Software engineers have coined the terms accidental complexity and essential complexity. Accidental complexity is caused by choosing abstractions incorrectly, causing needless branching in the logic, to match the hidden underlying correct abstraction. Essential complexity is the minimum amount of complexity that needs to be introduced to make the thing work as it should (the ideal).
An essential problem in software engineering, and indeed in every other field including the composition of abstractions, is that these special cases combine combinatorially (and they occur multiplicatively, in the sense that it affects every point of use). Unless actively dealt with, in a very short time this makes the program incomphrehensible to the programmers themselves. What separates good programmers from the bad is that the former can keep the accidental complexity in control by actively making choices which minimize special cases (and repairing such errors in retrospect).
This underlines an important idea in controlling accidental complexity: in an abstraction, the uniformity of the corner cases with respect to the base case is the most important part of the abstraction. Perhaps mathematicians could resonate with the mental image that an abstraction should be continuous on the boundary points, _unless_ that discontinuity is an essential (and not accidental) part of the abstraction.
Up to now, I have described the great monster of bad syntax, that arising from the composition of bad abstractions, a kind of asymptotically bad complexity if you will. But part of accidental complexity are also smaller monsters, which cause only a constant amount of excessive work. Examples of such are reading this word sdrawkcab, presenting linear systems of equations by elements rather than matrices, or indeed the tau versus pi notation. Such constantpenalty complexity requires additional brain processing for nothing. It slows you down: consider the time it took to read the word backwards above.
It's only syntax, some people say, but I say they haven't actually been exposed enough to the monsters to recognize the problem, or never lived monsterfree. In a fantasy world of mine, everyone strives to minimize accidental complexity, whether it be constant or asymptotic.
</rant>
 http://kaba.hilvi.org



