What does it mean with infix

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

Jul 23 '05 #3

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.

Jul 23 '05 #4

Pelle Beckman

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

Jul 23 '05 #5

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?

Jul 23 '05 #6

E. Robert Tisdale

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

Jul 23 '05 #7

rossum

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

Jul 23 '05 #8

msalters

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 postfix-expression's.

Jul 23 '05 #9

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.

Jul 23 '05 #10

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

Jul 23 '05 #11

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

Jul 23 '05 #12

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

Jul 23 '05 #13

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

Jul 23 '05 #14

>>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 "wathever-fix", 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.

Jul 23 '05 #15

Karl Heinz Buchegger

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 "wathever-fix", 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

Jul 23 '05 #16

>>> postfix: 1 2 + (sometimes called "reverse Polish notation")

Whats "standard Polish notation" then? ordinary prefix ( + 1 2)?

I missunderstood your comment/question. Sorry.

Jul 23 '05 #17

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.

Jul 23 '05 #18

> 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")

Jul 23 '05 #19

Risto Lankinen

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 object-orientation 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 type-deducible which
allows for "real-time" 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.

Jul 23 '05 #20

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 object-orientation 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.

Jul 23 '05 #21

Karl Heinz Buchegger

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

Jul 23 '05 #22