This is discussed in a book Computer Science: An Overview (11th Edition) by J. Glenn Brookshear, in Chapter 5 Algorithms. To start with, author formally defines algorithm as follows:
An algorithm is an ordered set of unambiguous, executable steps that defines a terminating process
Further discussion is starting at page 189. Author explains the meaning of ambiguity in what you call "proposed algorithm" as follows:
requirement imposed by the definition... is that the steps in an algorithm be unambiguous. This means that during execution of an algorithm, the information in the state of the process must be sufficient to determine uniquely and completely the actions required by each step. In other words, the execution of each step in an algorithm does not require creative skills. Rather, it requires only the ability to follow directions.
For the sake of completeness, author points out that above requirement is intentionally narrowed: "In Chapter 12 we will learn that “algorithms,” called nondeterministic algorithms, that do not conform to this restriction are an important topic of research."
Ambiguity of algorithm representation is explained as follows:
It is important to emphasize the distinction between an algorithm and its representation — a distinction that is analogous to that between a story and a book. A story is abstract, or conceptual, in nature; a book is a physical representation of a story. If a book is translated into another language or republished in a different format, it is merely the representation of the story that changes — the story itself remains the same.
In the same manner, an algorithm is abstract and distinct from its representation. A single algorithm can be represented in many ways. As an example, the algorithm for converting temperature readings from Celsius to Fahrenheit is traditionally represented as the algebraic formula
F = (9/5)C + 32
But it could be represented by the instruction
Multiply the temperature reading in Celsius by 9/5
and then add 32 to the product
or even in the form of an electronic circuit. In each case the underlying algorithm is the same; only the representations differ.
The distinction between an algorithm and its representation presents a problem when we try to communicate algorithms. A common example involves the level of detail at which an algorithm must be described. Among meteorologists, the instruction “Convert the Celsius reading to its Fahrenheit equivalent” suffices, but a layperson, requiring a more detailed description, might argue that the instruction is ambiguous. The problem, however, is not with the underlying algorithm but that the algorithm is not represented in enough detail for the layperson.
Further in the chapter, author also explains how to resolve it:
the concept of primitives can be used to eliminate such ambiguity problems in an algorithm’s representation.
...A program is a representation of an algorithm. (Here we are using the term algorithm in its less formal sense in that many programs are representations of nonterminating “algorithms.”) In fact, within the computing community the term program usually refers to a formal representation of an algorithm designed for computer application.
...communication problems arise when the language used for an algorithm’s representation is not precisely defined or when information is not given in adequate detail.
Computer science approaches these problems by establishing a well-defined set of building blocks from which algorithm representations can be constructed. Such a building block is called a primitive. Assigning precise definitions to these primitives removes many problems of ambiguity, and requiring algorithms to be described in terms of these primitives establishes a uniform level of detail. A collection of primitives along with a collection of rules stating how the primitives can be combined to represent more complex ideas constitutes a programming language...
I believe the direct answer is simply that functions are not operators. From the page you linked:
If the token is a function token, then push it onto the stack.
This is all it needs to say, since the function case (prefix to postfix) is much simpler than the operator case (infix to postfix).
For the follow-up questions: The notions of precedence and associativity are only needed because of the inherit ambiguity in any expression with multiple infix operators. Function tokens are already using prefix notation, so they simply don't have that problem. You don't need to know whether sin
or max
has "higher precedence" to figure out that max
needs to be evaluated first; it's already clear from the order of the tokens. That's why computers prefer pre/postfix notation to begin with, and why we have this algorithm for converting infix to pre/postfix.
You do need to have some kind of rule for where a function's arguments start and end when no parenthesis are present, so you could say that functions "take precedence" over operators or vice versa. But unlike infix operators, a single consistent rule for all functions is enough to make their compositions completely unambiguous.
Best Answer
When looking for an "industry standard", one might look at the most popular programming languages. However, the problem you are describing occurs only in conjunction with the exponentiation operator. And languages like C, C++, Java, C# these languages don't have this operator, Javascript currently does not have one, but this is going to change (see below).
In most languages which have an exponentiation operator like PHP and Python and others, according to this source, the exp operator is defined to have a higher precedence than unary operators. The article mentions also a few exceptions like shell programming in Bash. The same source tells us the upcoming Javascript/ECMAScript version 2016 (ES7) will introduce the
**
operator in Javascript, but ambigouus usage will be forbidden.Note that "higher precedence" of the exp operator here only means "it binds more tightly to the left side" of the exp operator as described in the Python docs. An unary minus on the right side will be always applied first, but that is simply because the minus sign in such a case is next to the second argument, and the exponentiation sign isn't, so it is not really a matter of precedence (see one of the answers from the Math.SE question you gave a link to).
So I guess using the Python/PHP rules would be fine and not astonish anyone, but this is not mandatory, and if you think a different convention would serve you better, pick that.