Pre-increment

[[ Xze ]]

Hi all!

My question pertains to the way that jbase treats pre-increments

Consider the following routine:

0004     PROGRAM MY.MATH
0005
0006     CNT = 3
0007     RES = ++CNT + ++CNT
0008
0009     PRINT 'RES = ':RES
0010     RETURN
0011 END

The output result is RES = 10

if i change line 007 to RES = ++CNT + ++CNT + ++CNT,
then the output result is RES = 16

Can anybody explain this behaviour? (I expected the first case to output RES = 9 and the second RES = 15)

My system configuration:

OS      :   AIX 5.3
jbase   : Major 5.0 , Minor 20 , Patch 0364 (Change 85159)

Regards

[VK]

Hi,
tried that on TAFC R10 (Change 89685)

Source:

001 PROGRAM KZM.PLUS
002
003 CNT = 3
004 PRINT ++CNT + ++CNT
005
006 CNT2 = 3
007
008 PRINT ++CNT2 + ++CNT2 + ++CNT2
009
010 STOP
011 END

Result:

10
18

It looks that preincrement has preference and it's proceeded in full
before summing ttakes place:

(3+1+1) * 2 = 10

(3+1+1+1) * 3 = 18

why you had 16, I don't understand. Typo?

VK

[[ Xze ]]

why you had 16, I don't understand. Typo?

No, checked that again, its 16

And how i'm curious about the result = 10; Is (3 + 1 + 1) * 2 a valid computation?! The second pre-increment will be applied on an already pre-incremented value
As far as i know it should look like that:

CNT = 3
RES = (3+1) + ((3+1)+1) = 9

Regards,
Xze

--

Please read the posting guidelines at: http://groups.google.com/group/jBASE/web/Posting%20Guidelines

IMPORTANT: Type T24: at the start of the subject line for questions specific to Globus/T24

To post, send email to jB...@googlegroups.com
To unsubscribe, send email to jBASE-un...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/jBASE?hl=en

[Jim Idle]

This is correct, reference this in C if you don’t believe me. Technically it is because the operator is unary right associative and is ‘pre’ increment. Hence, the instruction set generated is (roughly):

 

INC CNT in place ; CNT is now 4

INC CNT in place ; CNT is now 5

LD CNT           ; 5

ADD CNT          ; Add 5

 

And the answer is 10. I presume that you can derive the sequence for your second example from this.

 

Now contrast that with ‘post’ increment.

 

Jim

 

#include <stdio.h>

 

int

main(int cnt, char * argc[])

{

        int c, c1;

 

        c = 3;

        printf("Expr is %d\n, c is %d\n\n", ++c + ++c, c);

        c = 3;

        printf("Expr is %d\n, c is %d\n\n", c++ + c++, c);

}

 

 

 

--

[Jim Idle]

Look up the definition of the pre-increment and post-increment operators in C. They are right associative, which means that they operate to the right and as they are unary they have higher precedence than the binary “+” operator when they are the operands for the “+” operator. So the instruction sequence you get for your three piece combo with two binary “+” operations and three pre-increments is:

 

INC CNT   ; CNT = 4

INC CNT   ; CNT = 5

LD  CNT   ; 5

ADD CNT   ; 10

INC CNT   ; CNT=6

ADD CNT   ; 16

          ; Et voila.

 

 

#include <stdio.h>

 

int

main(int cnt, char * argc[])

{

        int c, c1;

 

        c = 3;

        printf("Expr is %d\n, c is %d\n\n", ++c + ++c, c);

        c = 3;

        printf("Expr is %d\n, c is %d\n\n", ++c + ++c + ++c, c);

        c = 3;

        printf("Expr is %d\n, c is %d\n\n", c++ + c++, c);

}

 

You are just confused over operator sequencing and precedence.

 

Jim

VK – if you are getting 18, then your system has a bug!! This sequence will not optimize to a multiplication because of the operator precedence requirements.

[Gregory Cooper]

Jim me eld mucker,

 

All very well and good, but ……

 

On jBASE 3.x, the answer given is 9 (and then 15 for the second test). This is what Xze (??) was expecting and differs to what he saw on jBASE 5.x , answers of 10 and 16.

 

So no matter what your argument, the fact we get different answers on different jBASE releases shows that something is wrong. As you were responsible for the jBASE 3.x compiler and not for the jBASE 5.x compiler, I would obviously expect the jBASE 3.x answer to be correct ;-)

You then talk about “reference this in C if you don’t believe me”. Now, not as though I didn’t believe you or anything, but writing a simple C program on Suse 11.2 gives this

 

main()

{

    int cnt , res ;

    cnt = 3 ;

    res = ++cnt + ++cnt ;

    printf("cnt = %d\n",cnt);

}

 

cnt = 5

 

So that doesn’t match up with either of the jBASE releases or what you had said about C.

 

So there is obviously some behaviour that is hard to pin down with these pre and post increments.

 

I am sure I am missing something here, and await your demolishment of this email to prove you right again ! ;-)

 

Greg

[Jim Idle]

Greg,

 

Thank you for your proof of Fermat’s last theorem, your mistake is at line 6.

 

I have been trying to teach you C for so long now that I cannot remember how long it is, but if this is an example of how much you have learned, then perhaps I spent about 20 minutes on your lessons? Run the program I attached and not your incorrect program. Mine confirms that cnt is 5 and that therefore the expression is 10, which your C program is merely confirming… as well as confirming that one should not try to write C at 9PM on a Sunday after a few beers and a curry… unless you are me.

 

If a prior version of jBASE did not return 10 in this instance then it was incorrect. In fact, I think I remember fixing this bug in 4.x (and specifically only at the major point release)… or maybe I don’t. Perhaps you remember me doing this… nah, it was more than 20 minutes ago ;-) (c.f. The Invisible Gorilla)

 

Anyway, your program is evaluating the expression and storing it in the variable ‘res’, but then your printf statement is outputting the value of cnt (I think you are missing a letter perhaps?  =:?o), which as cnt is has been incremented twice by then, will, as you acidulously demonstrate, have the value 5, thus proving that C thinks that 3 +1 +1 is 5.

 

So, you have fallen for the same issue only worse, in that the ++var will always happen before the binary operator + and so this will be 5 + 5 = 10. However your mistake is even worse because you are not even printing out the correct variable. If you are having trouble typing in the program that I attached to my email in the first place, then please let me know, so I can show you how to type in October when I am back in London. I was going to visit with you of course, but I am not sure if I should be associating with junior C programmers ;-)

 

Now, it could well be that the original parser at some point in 3.x did not have the correct precedence on the pre_increment operator and so it gives the wrong answer. However, the answer that the OP is getting from the latest jBASE is the correct one.

 

In future my eld padwan, you should concentrate on handing out the res due to your old master, otherwise you risk looking like a

 

As I presume that pointing out that your C program is utter crap and merely verifies my much cleverer program, I take it that this is sufficient demolition of your argument and that you will now be buying the second and third rounds as well as the first, as well of course being…

 

Yours respectfully, etc etc,

 

Ben Franklin.

[Chenai]

Hi,

Actually eh, the issue isnt quite settled. On AIX 5.3 I cut and paste
your program and the output is 9 not 10 for the pre-increment. I
compiled the program with xlc without passing any compiler options.
jbase 5 on the same server using the same compiler gives a result of
10 for the OP's code. What am I missing?


0001 #include <stdio.h>
0002
0003 int main(int cnt, char * argc[])
0004 {
0005 int c;
0006
0007 c = 3;
0008 printf("Expr is %d\n, c is %d\n\n", ++c + ++c, c);
0009 c = 3;
0010 printf("Expr is %d\n, c is %d\n\n", c++ + c++, c);
0011
0012 return 0;
0013 }

Expr is 9
, c is 5

Expr is 6
, c is 5


Chenai.

On Sep 5, 9:57 pm, "Jim Idle" <j...@temporal-wave.com> wrote:
> Greg,
>
> Thank you for your proof of Fermat's last theorem, your mistake is at line
> 6.
>
> I have been trying to teach you C for so long now that I cannot remember how
> long it is, but if this is an example of how much you have learned, then
> perhaps I spent about 20 minutes on your lessons? Run the program I attached
> and not your incorrect program. Mine confirms that cnt is 5 and that

> therefore the expression is 10, which your C program is merely confirming.

> as well as confirming that one should not try to write C at 9PM on a Sunday

> after a few beers and a curry. unless you are me.

>
> If a prior version of jBASE did not return 10 in this instance then it was
> incorrect. In fact, I think I remember fixing this bug in 4.x (and

> specifically only at the major point release). or maybe I don't. Perhaps you
> remember me doing this. nah, it was more than 20 minutes ago ;-) (c.f. The

> Invisible Gorilla)
>
> Anyway, your program is evaluating the expression and storing it in the
> variable 'res', but then your printf statement is outputting the value of
> cnt (I think you are missing a letter perhaps?  =:?o), which as cnt is has
> been incremented twice by then, will, as you acidulously demonstrate, have
> the value 5, thus proving that C thinks that 3 +1 +1 is 5.
>
> So, you have fallen for the same issue only worse, in that the ++var will
> always happen before the binary operator + and so this will be 5 + 5 = 10.
> However your mistake is even worse because you are not even printing out the
> correct variable. If you are having trouble typing in the program that I
> attached to my email in the first place, then please let me know, so I can
> show you how to type in October when I am back in London. I was going to
> visit with you of course, but I am not sure if I should be associating with
> junior C programmers ;-)
>
> Now, it could well be that the original parser at some point in 3.x did not
> have the correct precedence on the pre_increment operator and so it gives
> the wrong answer. However, the answer that the OP is getting from the latest
> jBASE is the correct one.
>
> In future my eld padwan, you should concentrate on handing out the res due
> to your old master, otherwise you risk looking like a
>
> As I presume that pointing out that your C program is utter crap and merely
> verifies my much cleverer program, I take it that this is sufficient
> demolition of your argument and that you will now be buying the second and

> third rounds as well as the first, as well of course being.

>
> Yours respectfully, etc etc,
>
> Ben Franklin.
>
> From: jb...@googlegroups.com [mailto:jb...@googlegroups.com] On Behalf Of
> Gregory Cooper
> Sent: Sunday, September 05, 2010 12:13 PM
> To: jb...@googlegroups.com
> Subject: RE: Pre-increment
>
> Jim me eld mucker,
>

> All very well and good, but ..

> For more options, visit this group athttp://groups.google.com/group/jBASE?hl=en

>
> --
> Please read the posting guidelines at:http://groups.google.com/group/jBASE/web/Posting%20Guidelines
>
> IMPORTANT: Type T24: at the start of the subject line for questions specific
> to Globus/T24
>
> To post, send email to jB...@googlegroups.com
> To unsubscribe, send email to jBASE-un...@googlegroups.com

> For more options, visit this group athttp://groups.google.com/group/jBASE?hl=en

[Charlie Noah]

Hi Folks,

If you are writing JBC code and not C, why use a construct that is so difficult to understand, and obviously returns different results depending on the environment? Is there a compelling reason? I realize this is a good discussion of the usage of pre-increment and quite educational, and that it can be used in production, but if I'm writing code for a business purpose, I'd probably use something easier to follow (maintain) and whose results are more predictable. But, that's just me.

Charlie Noah

The views and opinions expressed herein are my own (Charlie Noah) and do not necessarily reflect the views, positions or policies of any of my former, current or future employers, employees, clients, friends, enemies or anyone else who might take exception to them.

[Jim Idle]

The issue is somewhat complicated, because even in C there is an
interpretation that says that the C standard does not quite define the
behavior here. However, gcc and jBASE are generally thought to be correct.
You also have to be careful with optimizations such as O4, which can change
such things. As a general rule of thumb, you will find that when xlc differs
from other compilers, it is marginally justified but usually (but not
always) 'wrong'. The only exception to this rule is that if it is differing
from an HP compiler, you can usually (but not always) bet your last cent on
the HP compiler doing something stupid. :-)

In general, the best way to handle such issues is to avoid them, be more
explicit with parenthesis and break down the expression. In fact there is a
more important reason why you should do that and this is that 'clever'
expressions such as this are beyond the ability of most to just read the
code and know exactly what it is doing. Hence, for the sake of
maintainability, we should never be 'clever' unless it is the only way. The
optimizers will take care of almost everything these days. Besides which,
the usual problem with a program is algorithmic, which neither a clever line
of code, nor an optimizer (at least, not as yet) can fix.

Jim