array indexing... you cant use 'long' ???!

T

TrevorBoydSmith

As the title says... I am confused about this. I wish to index into an
array with a primitive datatype long. But the compiler will not
compile. It only accepts primitive datatype int to index into an
array!

---------------------------
Code snippet:
---------------------------
public class errorTest1{

public static void main(String args[]){
long n = 5;
int[] array = new int[1024];

n = (long)array[n];
}

}


---------------------------
end Code snippet:
---------------------------

ERROR -->
Type mismatch: cannot convert from long to
int error_test1 errorTest1.java line 7



Am i correct in assuming that you can not index an array unless it is
of datatype primitive int???

I ask about this because this pertains to code that I am porting from
C. In C you can index with primitive datatype long.
 
T

Thomas Kellerer

As the title says... I am confused about this. I wish to index into an
array with a primitive datatype long. But the compiler will not
compile. It only accepts primitive datatype int to index into an
array!
Am i correct in assuming that you can not index an array unless it is
of datatype primitive int???

The elements of an array can of course be of any valid Java data type.
But as the size of an array can not exceed Integer.MAX_VALUE, you are
not allowed to use non-int values to index the array (because
potentially you could wind up "outside" of the array.


Thomas
 
O

Oliver Wong

As the title says... I am confused about this. I wish to index into an
array with a primitive datatype long. But the compiler will not
compile. It only accepts primitive datatype int to index into an
array!

---------------------------
Code snippet:
---------------------------
public class errorTest1{

public static void main(String args[]){
long n = 5;
int[] array = new int[1024];

n = (long)array[n];
}

}


---------------------------
end Code snippet:
---------------------------

ERROR -->
Type mismatch: cannot convert from long to
int error_test1 errorTest1.java line 7



Am i correct in assuming that you can not index an array unless it is
of datatype primitive int???

I ask about this because this pertains to code that I am porting from
C. In C you can index with primitive datatype long.

You are correct. This also means that you cannot create an array whose
size is greater than MAX_INT.

- Oliver
 
C

Chris Uppal

Am i correct in assuming that you can not index an array unless it is
of datatype primitive int???

As others have already said, the index has to be something that the compiler
will accept as an int (shorts count, as do bytes, but not longs). So you'll
have to use a cast

myArray[(int)myLong]

However, the chances are that using a long in this context indicates a logic
error in your program, since the above cast will silently truncate longs >
2**31 (or so), causing them to index the wrong element of the array.

I ask about this because this pertains to code that I am porting from
C. In C you can index with primitive datatype long.

Ah, that explains it. A lot of C code is written with the assumption that a
long is 32-bits while an int /might/ be only 16 (it's been a long time since
that was often true but old habits die hard). In Java an int is /always/
32-bits, and a long is /always/ 64-bits. So unless one of your purposes in
porting this software is to expand the range of values it can handle, you will
most probably find that Java int is the nearest equivalent to a C long.

-- chris
 
D

dsjoblom

Chris said:
Ah, that explains it. A lot of C code is written with the assumption that a
long is 32-bits while an int /might/ be only 16 (it's been a long time since
that was often true but old habits die hard). In Java an int is /always/
32-bits, and a long is /always/ 64-bits. So unless one of your purposes in
porting this software is to expand the range of values it can handle, you will
most probably find that Java int is the nearest equivalent to a C long.

It might also be added that the /preferred/ type to use to index into
arrays in C is neither long nor int but size_t which will 'do the right
thing' on any platform[*]. The correct C to Java conversion would then
be size_t to int. This is not an entirely perfect solution though,
since size_t is an unsigned type in C, but it captures the intended
meaning of size_t which is a platform independent type to be used for
object sizes and indexes.

Regards,
Daniel Sjöblom

*Of course, this assumes the C code is somewhat modern. I realize there
is tons of code that doesn't follow these conventions.
 
T

TrevorBoydSmith

Once again... wow to the knowledge about random programming stuff.
Especially the bit about C programmers using long out of habit to
ensure that they get a 32 bit number on older machines. This little
tid bit of course dates back to the ACTUAL DEFINITON of what C is. C
defines the MINIMUM number of bits that you use for each datatype. int
has a definition of minimum 16 bits. LOL.

One more thing. Okay so you cant create arrays that are larger than
INT_MAX. Well then lets say I'm doing some sort of database work that
requires arrays larger than INT_MAX. What then???!

I suppose the only solution would be to wrap some class in something
that creates a new array whenever it goes past INT_MAX... and then wrap
the indexing function so that it always finds the right index or
something?
 
E

Eric Sosman

Once again... wow to the knowledge about random programming stuff.
Especially the bit about C programmers using long out of habit to
ensure that they get a 32 bit number on older machines. This little
tid bit of course dates back to the ACTUAL DEFINITON of what C is. C
defines the MINIMUM number of bits that you use for each datatype. int
has a definition of minimum 16 bits. LOL.

Why laugh? 16-bit machines were common when C was new,
32-bit machines were mostly mainframes and expensive (one
prominent company wouldn't even sell their 32-bit systems;
you had to lease them and pay by the CPU-minute). A language
that insisted on 32-bit integers would not have survived;
people didn't want to be forced to do double-precision integer
arithmetic in software emulation when they didn't need it.

Here's a proposal: Get rid of long and int and short
and byte, and just use BigNum in place of all of them.
Perhaps that would silence your laughter, but I have to
believe it would provoke laughter in other quarters.
One more thing. Okay so you cant create arrays that are larger than
INT_MAX. Well then lets say I'm doing some sort of database work that
requires arrays larger than INT_MAX. What then???!

Do you really need the entire contents of your database
to be in memory at one time, and in the form of an array?
Do you know how to find the average of a million numbers
without creating a million-place array to hold them all?
I suppose the only solution would be to wrap some class in something
that creates a new array whenever it goes past INT_MAX... and then wrap
the indexing function so that it always finds the right index or
something?

Um, er, I think you've just described the database
itself.

Trevor, I'm not trying to make fun of you, but I *am*
asking you to step back for a moment and ask yourself
whether you actually need an array of more than two billion
elements, or whether you're simply chafing at the imposition
of any limit, however great. Don't just say "databases can
be big," but sit down and think up an actual, plausible
situation where you need more than two billion "things"
*and* where dumping them all in a single flat array is a good
idea. I'm not saying such situations do not or cannot exist,
just that if they do they are rare, and corner cases don't
drive the design of any widely-applicable language.
 
P

Patricia Shanahan

Eric Sosman wrote:
....
Trevor, I'm not trying to make fun of you, but I *am*
asking you to step back for a moment and ask yourself
whether you actually need an array of more than two billion
elements, or whether you're simply chafing at the imposition
of any limit, however great.
....

I seem to have heard that story a couple of times before.

I've also met people who needed to solve sets of tens of thousands of
linear equations in complex variables.

Patricia
 
C

Chris Uppal

One more thing. Okay so you cant create arrays that are larger than
INT_MAX. Well then lets say I'm doing some sort of database work that
requires arrays larger than INT_MAX. What then???!

Then you loose...

;-)

BTW, I'm having difficulty imagining a reasonable application/library design
which would require /contiguous/ integer-indexed storage for more than 2**32
elements -- did you have anything specific in mind ?

I suppose the only solution would be to wrap some class in something
that creates a new array whenever it goes past INT_MAX... and then wrap
the indexing function so that it always finds the right index or
something?

Yes, you can create container objects (whether subclassing java.util.Collection
or not) which are indexed however you like -- by negative BigIntegers if that
makes you happy ;-)

Unfortunately you can't use array access syntax to read/write such containers
in Java, which is a definite nuisance -- making it more difficult both to read
and write the code.

-- chris
 
C

Chris Uppal

Eric said:
Here's a proposal: Get rid of long and int and short
and byte, and just use BigNum in place of all of them.
Perhaps that would silence your laughter, but I have to
believe it would provoke laughter in other quarters.

Done right, that is the only way to fly...

(Needless to say, "right" does not include autoboxing.)

-- chris
 
T

TrevorBoydSmith

I think the matter that bothers me is having any limit at all. But to
be truthful you don't need to have 2 billion length arrays. Only a
fool would do something like that right now. (in the future ... i.e.
couple of years it might be another story.)

The largest continuous arrays are images. And even then those are only
in the millions. 2048x2048x3 for example. When you go to video
processing it is not continuous flat arrays but rather it is images
stored in an array. or a multidimensional array.
 
P

Patricia Shanahan

I think the matter that bothers me is having any limit at all. But to
be truthful you don't need to have 2 billion length arrays. Only a
fool would do something like that right now. (in the future ... i.e.
couple of years it might be another story.)

The largest continuous arrays are images. And even then those are only
in the millions. 2048x2048x3 for example. When you go to video
processing it is not continuous flat arrays but rather it is images
stored in an array. or a multidimensional array.

Do you really mean "The largest continuous arrays" or just "The largest
continuous array in home data processing"?

The largest continuous arrays I've met are far bigger than that, in
scientific and engineering programs, and had nothing at all to do with
images. People were solving systems of equations with more than two
billion coefficients back when they had to do it with out-of-core
solvers, shuffling blocks of data between memory and disk, because the
whole array did not fit in memory.

And my experience with large scale linear algebra was a couple of
employers ago, when I was working for FPS and then Cray Research, back
when Java was a type of coffee. Given the general trends, array sizes
have probably increased in the last ten years.

It bothers me to have a limit that prevents application of simple array
techniques to the largest arrays that fit in physical memory on a large
server. People whose arrays are bigger than that are stuck anyway.

Patricia
 
C

Chris Uppal

Patricia said:
It bothers me to have a limit that prevents application of simple array
techniques to the largest arrays that fit in physical memory on a large
server. People whose arrays are bigger than that are stuck anyway.

I think that the problem here is not the unavailability of contiguous data
beyond a certain size -- I'm pretty sure that if you are dealing with data of
that order that you would want to handle memory layout issues with far greater
finesse than just "it's all laid end-to-end". I think the real problem is the
lack of a decent notation which would allow us to create large array-like
structures (with whatever physical layout we needed) and treat them as
transparently and (nearly) as efficiently as we can "real" arrays.

I have nothing /against/ extending indexing to 64-bit indexing[*], you
understand, it's just that I think that would be solving only a relatively
small part of the real problem.

-- chris

[*] beyond purely practical issues like backward compatibility.
 
E

Eric Sosman

Patricia Shanahan wrote On 08/31/06 18:46,:
Eric Sosman wrote:
...


...

I seem to have heard that story a couple of times before.

I've also met people who needed to solve sets of tens of thousands of
linear equations in complex variables.

The array indices for "tens of thousands" will fit
quite comfortably in `int's. If you need a 50Kx50Kx50K
array you're going to have plenty of problems, but the
range of the array indices won't be among them.

From Trevor's posts I have the impression that he
actually doesn't have enormous arrays to deal with. He's
got some C code that he's converting to Java, and the C
occasionally (or maybe systematically) uses a `long' as
an array index. When he transliterates this to Java,
the compiler slaps his wrist.

The problem isn't that he needs big arrays, but that
he needs to do a more sensitive translation. Both Java
and C use the word `long' to denote a kind of integer,
but there the similarity ends: the word means different
things in the two languages, and copying the word blindly
from one language to the other changes the meaning. C
and Java both use `char', and it means different things.
C and Java both recognize `goto', and it means different
things. Transliteration is not translation, and cognates
are not synonyms.
 
J

John W. Kennedy

Patricia said:
The largest continuous arrays I've met are far bigger than that, in
scientific and engineering programs, and had nothing at all to do with
images. People were solving systems of equations with more than two
billion coefficients back when they had to do it with out-of-core
solvers, shuffling blocks of data between memory and disk, because the
whole array did not fit in memory.

Do you literally mean systems of >2Gi equations with >2Gi coefficients
apiece? >4Ei coefficients in all, plus a >2Gi RHS? Because that's what's
in play here.

(Not to mention that even a system with 64-bit pointers could not hold
such an array in memory.)
 
P

Patricia Shanahan

Eric said:
Patricia Shanahan wrote On 08/31/06 18:46,:

The array indices for "tens of thousands" will fit
quite comfortably in `int's. If you need a 50Kx50Kx50K
array you're going to have plenty of problems, but the
range of the array indices won't be among them.

That depends in part on whether the array-of-array-of-array approach
works, or whether you want to control the memory layout a bit more by
using a flat array.
From Trevor's posts I have the impression that he
actually doesn't have enormous arrays to deal with. He's
got some C code that he's converting to Java, and the C
occasionally (or maybe systematically) uses a `long' as
an array index. When he transliterates this to Java,
the compiler slaps his wrist.

The problem isn't that he needs big arrays, but that
he needs to do a more sensitive translation. Both Java
and C use the word `long' to denote a kind of integer,
but there the similarity ends: the word means different
things in the two languages, and copying the word blindly
from one language to the other changes the meaning. C
and Java both use `char', and it means different things.
C and Java both recognize `goto', and it means different
things. Transliteration is not translation, and cognates
are not synonyms.

Indeed. I agree that when translating an ordinary C program to Java, I
would expect many uses of C "long" to translate to Java "int".

Patricia
 
P

Patricia Shanahan

John said:
Do you literally mean systems of >2Gi equations with >2Gi coefficients
apiece? >4Ei coefficients in all, plus a >2Gi RHS? Because that's what's
in play here.

(Not to mention that even a system with 64-bit pointers could not hold
such an array in memory.)

No, I meant a total of over 2 billion coefficients in the system of
equations.

Patricia
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top