P: n/a

Hello Experts!
I'm reading i a book about C++ and they mention infix with telling what it
is.
I hope you out there can do so.
Many thanks!
//Tony  
Share this Question
P: n/a

"Tony Johansson" writes: I'm reading i a book about C++ and they mention infix with telling what it is. I hope you out there can do so.
Infix means the operators are between the operands, just the ordinary way
you learned in school. There is also postfix and prefix which you may be
exposed to later..  
P: n/a

osmium wrote: "Tony Johansson" writes:
I'm reading i a book about C++ and they mention infix with telling what it is. I hope you out there can do so.
Infix means the operators are between the operands, just the ordinary way you learned in school. There is also postfix and prefix which you may be exposed to later..
Actually, isn't prefix notation used in C++ for function calls,
essentially? Name of the function comes first, then the list of
the arguments...
V  
P: n/a

Victor Bazarov wrote: osmium wrote: "Tony Johansson" writes:
I'm reading i a book about C++ and they mention infix with telling what it is. I hope you out there can do so.
Infix means the operators are between the operands, just the ordinary way
^^^^^^^^^
you learned in school. There is also postfix and prefix which you may be exposed to later..
Actually, isn't prefix notation used in C++ for function calls, essentially?
Yes, but for binary operators usually not. Unary ones are prefix or postfix,
depending on the operator.  
P: n/a

Victor Bazarov skrev: osmium wrote:
"Tony Johansson" writes:
I'm reading i a book about C++ and they mention infix with telling what it is. I hope you out there can do so. Infix means the operators are between the operands, just the ordinary way you learned in school. There is also postfix and prefix which you may be exposed to later..
Actually, isn't prefix notation used in C++ for function calls, essentially? Name of the function comes first, then the list of the arguments...
V
I'd say it's the other way around  functions are called by
the ()operator which is postfix.
On the other hand the ()operator takes arguments inside it...
 Pelle  
P: n/a

Pelle Beckman wrote: [...] I'd say it's the other way around  functions are called by the ()operator which is postfix.
On the other hand the ()operator takes arguments inside it...
So, if it's not infix or postfix or prefix, what is it? Outfix?  
P: n/a

Pelle Beckman wrote: Victor Bazarov skrev:
osmium wrote:
"Tony Johansson" writes:
I'm reading i a book about C++ and they mention infix with[out] telling what it is. I hope you out there can do so.
Infix means the operators are between the operands, just the ordinary way you learned in school. There is also postfix and prefix which you may be exposed to later..
Actually, isn't prefix notation used in C++ for function calls, essentially? Name of the function comes first, then the list of the arguments...
I'd say it's the other way around  functions are called by the ()operator which is postfix.
You probably mean operator().
The function name itself is a prefix operator.
Consider
sin(x); // sin x
cos(x); // cos x
for example.
You might think of a function invocation
as the application of a postfix operator()
to a function name but the real reason is that,
unlike some other computer programming languages,
C++ does *not* recognize juxtaposition of two identifiers
as the application of an operator (function). On the other hand the ()operator takes arguments inside it...
 Pelle  
P: n/a

On Wed, 06 Apr 2005 15:53:54 GMT, "Tony Johansson"
<jo*****************@telia.com> wrote: Hello Experts!
I'm reading i a book about C++ and they mention infix with telling what it is. I hope you out there can do so.
Many thanks! //Tony
Infix, prefix and postfix are about the relative positioning of an
operator and its operand(s). For binary operators (two operands) this
looks like:
prefix: + 1 2
infix: 1 + 2
postfix: 1 2 + (sometimes called "reverse Polish notation")
HTH
rossum
The ultimate truth is that there is no ultimate truth  
P: n/a

Victor Bazarov wrote: osmium wrote: "Tony Johansson" writes:
I'm reading i a book about C++ and they mention infix with telling
what itis. I hope you out there can do so.
Infix means the operators are between the operands, just the
ordinary way you learned in school. There is also postfix and prefix which you
may be exposed to later..
Actually, isn't prefix notation used in C++ for function calls, essentially? Name of the function comes first, then the list of the arguments...
RTFS ;)
5.2
"A function call is a postfix expression", it's the third form in the
grammar given for postfixexpression's.  
P: n/a

Mike Wahler wrote: "Victor Bazarov" <v.********@comAcast.net> wrote in message news:PY*******************@newsread1.mlpsca01.us.t o.verio.net... Pelle Beckman wrote: [...] I'd say it's the other way around  functions are called by the ()operator which is postfix.
On the other hand the ()operator takes arguments inside it...
So, if it's not infix or postfix or prefix, what is it? Outfix?
It's broken. Fix it. :)
So we call a function now as:
function () parameter;
Then () becomes an infix operator.  
P: n/a

Andre Caldas wrote: prefix: + 1 2 infix: 1 + 2 postfix: 1 2 + (sometimes called "reverse Polish notation")
Whats "standard Polish notation" then? ordinary prefix ( + 1 2)?
Sorry, I don't really know the "formal definition" of "Standard Polish Notation". But I guess this is one example:
1 2 3 + 4 * +
That's postfix, i.e. RPN. It is used in some pocket calculators, like HP 48,
which I have. It's actually superior to the infix notation in this case,
but you have to get used to it.
1 + 4 * (2 + 3)
That'd be infix.
PN would be:
+ 1 * + 2 3 4  
P: n/a

Rolf Magnus wrote: Mike Wahler wrote:
"Victor Bazarov" <v.********@comAcast.net> wrote in message news:PY*******************@newsread1.mlpsca01.us .to.verio.net...
Pelle Beckman wrote:
[...] I'd say it's the other way around  functions are called by the ()operator which is postfix.
On the other hand the ()operator takes arguments inside it...
So, if it's not infix or postfix or prefix, what is it? Outfix?
It's broken. Fix it. :)
So we call a function now as:
function () parameter;
Then () becomes an infix operator.
Does that mean that for more than one argument we need to do
function () argument1 () argument2 () argument3
to be infix? Seems lame.
V  
P: n/a

Victor Bazarov wrote: Rolf Magnus wrote: Mike Wahler wrote:
"Victor Bazarov" <v.********@comAcast.net> wrote in message news:PY*******************@newsread1.mlpsca01.u s.to.verio.net...
Pelle Beckman wrote:
>[...] >I'd say it's the other way around  functions are called by >the ()operator which is postfix. > >On the other hand the ()operator takes arguments inside it...
So, if it's not infix or postfix or prefix, what is it? Outfix?
It's broken. Fix it. :)
So we call a function now as:
function () parameter;
Then () becomes an infix operator.
Does that mean that for more than one argument we need to do
function () argument1 () argument2 () argument3
to be infix? Seems lame.
However, it doesn't look much different from how streaming is done in C++:
std::cout << "Hell" << "o world" << std::endl;
Is that lame, too? (Actually, IMHO, it is).  
P: n/a

Rolf Magnus wrote: Victor Bazarov wrote:
Rolf Magnus wrote:
Mike Wahler wrote: "Victor Bazarov" <v.********@comAcast.net> wrote in message news:PY*******************@newsread1.mlpsca01. us.to.verio.net...
>Pelle Beckman wrote: > > >>[...] >>I'd say it's the other way around  functions are called by >>the ()operator which is postfix. >> >>On the other hand the ()operator takes arguments inside it... > >So, if it's not infix or postfix or prefix, what is it? Outfix?
It's broken. Fix it. :)
So we call a function now as:
function () parameter;
Then () becomes an infix operator.
Does that mean that for more than one argument we need to do
function () argument1 () argument2 () argument3
to be infix? Seems lame. However, it doesn't look much different from how streaming is done in C++:
std::cout << "Hell" << "o world" << std::endl;
Is that lame, too? (Actually, IMHO, it is).
The bid difference here is that operator << takes only two arguments and
returns something that can be used as another left argument (operand) for
the next operator <<. The meaning of
func () arg1 () arg2 () arg3
is not "Call 'func' with 'arg1' then treat the return value as another
function which you call with 'arg2', etc." I would like it to mean "call
'func' with three arguments". Never mind...
V  
P: n/a

>>1 2 3 + 4 * + That's postfix, i.e. RPN. It is used in some pocket calculators, like HP 48,
I think that for you to have "postfix", or "watheverfix", you need:
* One operator
* One or more operands
What are the operands for the last "+" in the expression?
This is just the same as:
push 1
push 2
add
push 4
multiply
add
which I have. It's actually superior to the infix notation in this case,
I don't know if it is "superior", but it is much easier to parse since
there are no recursions.
PN would be: + 1 * + 2 3 4
Sorry, I don't understand this :(
Andre Caldas.  
P: n/a

Andre Caldas wrote: 1 2 3 + 4 * + That's postfix, i.e. RPN. It is used in some pocket calculators, like HP 48,
I think that for you to have "postfix", or "watheverfix", you need: * One operator * One or more operands What are the operands for the last "+" in the expression?
Ther result of 2 3 + 4 *
and the 1
You obviously never had a HP pocket calculator :)
Consider the tree
+
/ \
1 *
/ \
+ 4
/ \
2 3
There are various ways to run through the tree:
preorder, inorder, postorder
preorder: the node first, then left subtree, right subtree
inorder: left subtree first, node, right subtree
postoder: left subtree first, right subtree, node
doing this for the above tree gives:
preorder: + 1 * + 2 3 4
inorder: 1 + 2 + 3 * 4
postorder: 1 2 3 + 4 * +
All 3 representations represent the same tree (same expression),
but only inorder requires some ( )
1 + ( ( 2 + 3 ) * 4 )
to guide you through the presedence during evaluation. The other 2 don't need that. This is just the same as: push 1 push 2 add push 4 multiply add
You forget one
push 3 which I have. It's actually superior to the infix notation in this case, I don't know if it is "superior", but it is much easier to parse since there are no recursions.
Parsing is not the problem. Evaluating is!
With inorder notation, you need to incorporate the arithmetic rules
of precedence. It is not uncommon for compilers to first build
an expression tree from an infix notation, traverse that expression
tree in postorder and emit the code from that postorder traversel.
Why? Because arithmetic precedence has already been dealt with during
parsing and the tree has organized the opertions already correctly. PN would be: + 1 * + 2 3 4
Sorry, I don't understand this :(
+ add the next 2 expressions
1 the immediatly following expression equals 1
* + 2 3 4 thats the second expressions that gets added (since it starts with *
it is not a number, but an expression)
More exactly, it is the result of that expression that participates
in the add, so lets evaluate that
* multiply
+ 2 3 the result of that
4 with 4
Now we need to evaluate + 2 3
+ add
2 this
3 with that
in a more functional approach (as eg. in Lisp) the whole expression can be written
as:
add( 1, times( add( 2, 3 ), 4 ) )

Karl Heinz Buchegger kb******@gascad.at  
P: n/a

>>> postfix: 1 2 + (sometimes called "reverse Polish notation") Whats "standard Polish notation" then? ordinary prefix ( + 1 2)?
I missunderstood your comment/question. Sorry.  
P: n/a

Hello! You obviously never had a HP pocket calculator :)
No... I think they must be pretty usefull for engineers, though.
preorder: the node first, then left subtree, right subtree inorder: left subtree first, node, right subtree postoder: left subtree first, right subtree, node
This was enlightening, thank you.
By the way, is there anything good about preorder? I tryied to think of
a machine to execute it is much more complicated then postorder: that
is, I need one stack for the operands, and one "buffer" to store the
result. (well, the words on the operand stack could have only 2 bits
each  +,,/,* , and thats good!  you cannot use this reason ;)) which I have. It's actually superior to the infix notation in this case,
I don't know if it is "superior", but it is much easier to parse since there are no recursions.
Parsing is not the problem. Evaluating is! With inorder notation, you need to incorporate the arithmetic rules of precedence. It is not uncommon for compilers to first build an expression tree from an infix notation, traverse that expression tree in postorder and emit the code from that postorder traversel. Why? Because arithmetic precedence has already been dealt with during parsing and the tree has organized the opertions already correctly.
That's what I ment, sorry. Actually I guess it would be harder to
construct a tree from "postfix" or "prefix", since you would have to
start from the leaves.
in a more functional approach (as eg. in Lisp) the whole expression can be written as:
add( 1, times( add( 2, 3 ), 4 ) )
I guess this was what it was all about. If the "functional" thing was
"infix" or "postfix".
Thank you.  
P: n/a

> I guess this was what it was all about. If the "functional" thing was "infix" or "postfix".
Yes, I know, I know... (you guys are picky!)
"postfix" or "prefix" (nobody thinks it is "infix")  
P: n/a

Andre Kaldas wrote: I don't know if [infix] is "superior", but it is much easier to parse since there are no recursions.
"Karl Heinz Buchegger" <kb******@gascad.at> wrote in message
news:42***************@gascad.at... Parsing is not the problem. Evaluating is! With inorder notation, you need to incorporate the arithmetic rules of precedence. It is not uncommon for compilers to first build an expression tree from an infix notation, traverse that expression tree in postorder and emit the code from that postorder traversel. Why? Because arithmetic precedence has already been dealt with during parsing and the tree has organized the opertions already correctly.
Even easier way (yet quite neglected by the common "grammar
driven" parser development) is to use objectorientation and put
the intelligence into the parse tree nodes themselves:
class BinaryExpression
{
Expression *my_lhs;
Expression *my_lhs;
Expression *Plus( Expression * ) = 0;
Expression *Times( Expression * ) = 0;
}
class AdditionNode : public BinaryExpression ...
class MultiplicationNode : public BinaryExpression ...
// Showing just these to illustrate how precedence is dealt with:
Expression *AdditionNode::Times( Expression *operand )
{
return new AdditionNode( my_lhs,my_rhs>Times(operand) );
}
Expression *MultiplicationNode::Plus( Expression *operand )
{
return new AdditionNode( this,operand );
}
.... etc...
Now, the expression grammar can be [basically] as simple as...
Expression : Operand  Operand Binary_op Expression
.... instead of being a set of gazillion expression rules in different
precedence levels for arithmetic operator alone. Also, all of the
intermediate expressions are evaluable and typededucible which
allows for "realtime" calculation, syntax coloring, etc. neat tricks.
 Risto 
P.S. Note how a similar distinction in the implementation of
AdditionNode::Plus() or MultiplicationNode::Times() can be
used to control the associativity of each operator respectively.  
P: n/a

Risto Lankinen wrote: Andre Kaldas wrote:
Andre Caldas :) I don't know if [infix] is "superior", but it is much easier to parse since there are no recursions.
"Karl Heinz Buchegger" <kb******@gascad.at> wrote in message news:42***************@gascad.at...
*snip*It is not uncommon for compilers to first build an expression tree from an infix notation, traverse that expression tree in postorder and emit the code from that postorder traversel.
*snip* Even easier way (yet quite neglected by the common "grammar driven" parser development) is to use objectorientation and put the intelligence into the parse tree nodes themselves:
class BinaryExpression { Expression *my_lhs; Expression *my_lhs;
Expression *Plus( Expression * ) = 0; Expression *Times( Expression * ) = 0; }
class AdditionNode : public BinaryExpression ... class MultiplicationNode : public BinaryExpression ...
// Showing just these to illustrate how precedence is dealt with:
Expression *AdditionNode::Times( Expression *operand ) { return new AdditionNode( my_lhs,my_rhs>Times(operand) ); }
Expression *MultiplicationNode::Plus( Expression *operand ) { return new AdditionNode( this,operand ); }
... etc...
So, you are going to "parse" the expression and construct a tree just
like Karl said.  
P: n/a

Andre Caldas wrote: Hello!
You obviously never had a HP pocket calculator :)
No... I think they must be pretty usefull for engineers, though.
preorder: the node first, then left subtree, right subtree inorder: left subtree first, node, right subtree postoder: left subtree first, right subtree, node
This was enlightening, thank you. By the way, is there anything good about preorder? I tryied to think of a machine to execute it is much more complicated then postorder: that is, I need one stack for the operands, and one "buffer" to store the result. (well, the words on the operand stack could have only 2 bits each  +,,/,* , and thats good!  you cannot use this reason ;))
I could be wrong or remember incorrectly.
But I think that the maximum number stack size is little bit lower with
preorder then with postorder. which I have. It's actually superior to the infix notation in this case,
I don't know if it is "superior", but it is much easier to parse since there are no recursions.
Parsing is not the problem. Evaluating is! With inorder notation, you need to incorporate the arithmetic rules of precedence. It is not uncommon for compilers to first build an expression tree from an infix notation, traverse that expression tree in postorder and emit the code from that postorder traversel. Why? Because arithmetic precedence has already been dealt with during parsing and the tree has organized the opertions already correctly.
That's what I ment, sorry. Actually I guess it would be harder to construct a tree from "postfix" or "prefix", since you would have to start from the leaves.
:)
Not really.
Consider 'evaluation' as 'building the tree'.
As has been shown evaluation of preorder or postorder expressions
is simpler (because you don't need some () and the arithmetic
precedence rules have to be dealt with already ), the construction
of such a tree is simpler too.
postorder:
All you need is a stack of trees.
algorithm:
if the next input is a number: create a 'tree' from it and
push it on the stack
if the next input is an operation (binary assumed): pop
2 trees from the stack, form a new tree combining the operation
with those 2 trees and push it on the stack.
1 2 3 + 4 * +
1 > push on stack ++
 1 
++
2 > push on stack ++
 1 
++
 2 
++
3 > push on stack ++
 1 
++
 2 
++
 3 
++
+ > pop 2 times, new tree, push ++
 1 
++
 + 
 / \ 
 2 3 
++
4 > push on stack ++
 1 
++
 + 
 / \ 
 2 3 
++
 4 
++
* > pop 2 times, new tree, push ++
 1 
++
 * 
 / \ 
 + 4 
 / \ 
 2 3 
++
+ > pop 2 times, new tree, push ++
 + 
 / \ 
 1 * 
 / \ 
 + 4 
 / \ 
 2 3 
++
Finished, the stack contains the tree.
I am sure you can figure out how the same thing works with
a preorder tree.
Hint: Where else is this usefull besides evaluation of expressions.
Well. Think of storing a tree in a file and reconstructing
it from the file. Or: sending a tree through a network. Or ....
In other words: Whenever you need to serialize a tree.

Karl Heinz Buchegger kb******@gascad.at  
P: n/a

Hello!
I hope you had a nice weekend... result. (well, the words on the operand stack could have only 2 bits each  +,,/,* , and thats good!  you cannot use this reason ;)) I could be wrong or remember incorrectly. But I think that the maximum number stack size is little bit lower with preorder then with postorder.
You cannot use this... anything else?
:) Parsing is not the problem. Evaluating is!
construct a tree from "postfix" or "prefix", since you would have to start from the leaves.
:) Not really. Consider 'evaluation' as 'building the tree'.
You where so picky about the difference between "parsing" and
"evaluating"... I am getting confused.
For me (no formal education on the subject), "parsing" is like 'building
the tree'. While evaluating is like 'running through it'.
As has been shown evaluation of preorder or postorder expressions is simpler (because you don't need some () and the arithmetic precedence rules have to be dealt with already ), the construction of such a tree is simpler too.
postorder: All you need is a stack of trees.
algorithm: if the next input is a number: create a 'tree' from it and push it on the stack if the next input is an operation (binary assumed): pop 2 trees from the stack, form a new tree combining the operation with those 2 trees and push it on the stack.
1 2 3 + 4 * +
1 > push on stack ++  1  ++
2 > push on stack ++  1  ++  2  ++
3 > push on stack ++  1  ++  2  ++  3  ++
+ > pop 2 times, new tree, push ++  1  ++  +   / \   2 3  ++
4 > push on stack ++  1  ++  +   / \   2 3  ++  4  ++
* > pop 2 times, new tree, push ++  1  ++  *   / \   + 4   / \   2 3  ++
+ > pop 2 times, new tree, push ++  +   / \   1 *   / \   + 4   / \   2 3  ++
Finished, the stack contains the tree.
Actually, I dreamed about this on the friday night, and thought: "S*it!
He got me again!" (but I guess 'I got my self' because I didn't really
think before writing;)).
I am sure you can figure out how the same thing works with a preorder tree.
Thank you for not underestimating me too much!
Hint: Where else is this usefull besides evaluation of expressions. Well. Think of storing a tree in a file and reconstructing it from the file. Or: sending a tree through a network. Or .... In other words: Whenever you need to serialize a tree.
That's a good hint!
Thank you,
Andre Caldas.   This discussion thread is closed Replies have been disabled for this discussion.   Question stats  viewed: 3120
 replies: 22
 date asked: Jul 23 '05
