How to instantaneously convert array of Integers into an array onint's?

[Joshua Cranmer]

To be succinct, I believe this dates from older compilers where a
post-increment operation was more expensive than pre-increment, but the
equivalence of the two (in any sane environment) means that modern
compilers should be able to optimize the two to the same thing in this
environment.

I code in C++ as well as Java, it is true in C++ because classes can
have their own pre- and post- increment operators.

I can make the && operator in C++ perform multidimensional matrix
inversion if I wish, but that operation will most likely confuse anyone
who uses it. Justifying a tradition on the basis of what a user *may*
do, especially if such actions require defying conventional logic.

> I like to maintain
the habit whatever one of the C-style languages I am using. I agree
it is less important in Java where you cannot add operators to
classes. Think of the work needed to pre-increment or post-increment
a BigInteger.

I've not decided how I would like to see operator overloading
implemented in Java. Personally, I think an
interface+implementation+generics model works best (although getting an
int * BigInteger operator is not going to be intuitive), but the
annotation model also has its strong points.

In any case, based on some of my experiences in the GCC world, I think
using annotations to specify compiler hints would be useful here.
Hypothetically speaking:

interface Incrementor<T> {
// ++obj -> obj.preIncrement();
T preIncrement();
// obj++ -> obj.postIncrement();
// I'm not quite happy with this model
T postIncrement();
}
public class BigInteger implements Incrementor<BigInteger> {
public BigInteger preIncrement() {
// increment self
return this;
}
@IfIgnored("preIncrement")
public BigInteger postIncrement() {
BigInteger ret = new BigInteger(this);
// increment self
return ret;
}
}

The annotation IfIgnored tells the compiler that if the return value is
ignored, the method is equivalent in function to preIncrement. Sure,
strong powers of abuse, but if operator overloading is implemented in
any case, there's already strong temptations for abuse anyways.

 

[EJP]

To be succinct, I believe this dates from older compilers where a
post-increment operation was more expensive than pre-increment

It dates from the PDP-11, which had post-increment and pre-decrement in
hardware, or possibly the other way around, but not all four, so one way
it was one hardware instruction and the other way it was 2-3.

 

[John B. Matthews]

# exact, accurate
<http://en.wiktionary.org/wiki/precise>

It is accurate that I am interested in the incremented value of the
loop counter, and not the former value. The value of a
post-increment expression is the unincremented value.

This is surely true, but the value of the expression is then discarded*.
I have trouble preferring one over the other, unless the expression's
evaluation is critical is some other way, say as part of an array
access. (Not that I would advocate cluttering the ForUpdate part of a
for statement.)

This is not exactly what I have in mind when I think of a loop index.
The already-incremented value is what I have in mind, so the
pre-increment is a more exact and accurate representation of my
mental model of the index.

This makes perfect sense as a model of the state before the value of the
expression is discarded. Afterward, the value of an expression involving
the index is the incremented value. I can see pre-increment as a
preference, of course.

*<http://java.sun.com/docs/books/jls/third_edition/html/statements.html#1
4.14.1.2>

 

[Roedy Green]

Legal syntax.

got it. I have documented the pattern at
http://mindprod.com/jgloss/jcheat.html#LOOPS
and converted all my own code to use that form.

 

[Roedy Green]

The length of an array can not vary. I think that my compiler knows taht
better than me.

however the variable pointing to an array can substitute a different
array, so it is not completely mindless.

 

[Roedy Green]

I don't know why it's good habit using the pre-increment, but this is
not the first time I have heard this thing

It is best to stick to established idioms, namely i++ unless there is
some pressing reason to do otherwise. You will make people puzzle over
your code, having to figure out from first principles just what it
does.

 

[Arne Vajhøj]

It is best to stick to established idioms, namely i++ unless there is
some pressing reason to do otherwise. You will make people puzzle over
your code, having to figure out from first principles just what it
does.

I full agree with that.

Arne

 

[Arne Vajhøj]

It dates from the PDP-11, which had post-increment and pre-decrement in
hardware, or possibly the other way around, but not all four, so one way
it was one hardware instruction and the other way it was 2-3.

What does post and pre mean at the instruction level ?

Arne

 

[Patricia Shanahan]

What does post and pre mean at the instruction level ?

The PDP-11 had addressing modes that used a general register and also
incremented or decremented it. Post and pre, in this context, mean
whether to access memory using the original value of the general
register or the modified value.

See http://en.wikipedia.org/wiki/PDP-11#General_register_addressing_modes

Patricia

 

[EJP]

What does post and pre mean at the instruction level ?

I thought about that some more. They were two of the famous 7 PDP-11
addressing modes. So you could do e.g.

MOV R1, ++(SP) ; push R1
MOV (SP)--, R1 ; pop R1

in one instruction each, which was what it was really for, i.e.
addressing the 16-bit stack; but, the PDP-11 being nicely symmetrical &
without fixations on what the registers were for, you could also use it
to traverse 16-bit int arrays addressed by any register. Dennis Ritchie
just provided that in C syntax and generalized it for pointers to any
type. Unfortunately he also provided the other two modes that weren't in
the hardware, which therefore took several instructions each. So this
lore grew up that ++i was more efficient than i++, or the other way
round, whichever it was.

Bear in mind this was the 1970s, processor speeds measured in kilohertz,
memory sizes measured in kilobytes, no pipelines. I still remember the
day we installed that extra 16k to go to 64k to support about 4
developers. Made quite a difference!

 

[EJP]

.... but I see Ritchie contradicts all that, so I am wrong. He states
that the operators were already in B, put there by Ken Thompson, and
that B preceded the PDP-11.

http://cm.bell-labs.com/cm/cs/who/dmr/chist.html

However it is certainly true that either ++i or i++ was one instruction
on the PDP-11 and that this is the origin of the conventional wisdom.

 

[Mike Schilling]

I thought about that some more. They were two of the famous 7 PDP-11
addressing modes. So you could do e.g.

MOV R1, ++(SP) ; push R1
MOV (SP)--, R1 ; pop R1

in one instruction each, which was what it was really for, i.e.
addressing the 16-bit stack; but, the PDP-11 being nicely
symmetrical
& without fixations on what the registers were for, you could also
use it to traverse 16-bit int arrays addressed by any register.
Dennis Ritchie just provided that in C syntax and generalized it for
pointers to any type. Unfortunately he also provided the other two
modes that weren't in the hardware, which therefore took several
instructions each. So this lore grew up that ++i was more efficient
than i++, or the other way round, whichever it was.

Right, pointers. IIRC, that addressing mode can't be used to
optimzize incrementing the loop counter in

for (int i = 0; i < 10; i++)

Either i++ or ++i would be a simple

INC 12(SP)

or

INC R0

if i has been optimized into a register.

 

[EJP]

Right, pointers. IIRC, that addressing mode can't be used to
optimzize incrementing the loop counter

Correct; it was all about *sp++ as against *++sp