 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / September 2006array indexing... you cant use 'long' ???!
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. > 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  SignatureIt's not a RootKit - it's a Sony > 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 [quoted text clipped - 28 lines] > 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 > 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 > 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. 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? TrevorBoydSmith@gmail.com wrote On 08/31/06 17:40,: > 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. SignatureEric.Sosman@sun.com ... > 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 Patricia Shanahan wrote On 08/31/06 18:46,: > ... > [quoted text clipped - 10 lines] > 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. SignatureEric.Sosman@sun.com > Patricia Shanahan wrote On 08/31/06 18:46,: >> ... [quoted text clipped - 15 lines] > 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 [quoted text clipped - 13 lines] > 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 > 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 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. ----- So ya the integer indexing is an annoyance. but point taken. > 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 [quoted text clipped - 5 lines] > 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 > 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. > 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.) SignatureJohn W. Kennedy "The blind rulers of Logres Nourished the land on a fallacy of rational virtue." -- Charles Williams. "Taliessin through Logres: Prelude" >> 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 [quoted text clipped - 9 lines] > (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 > 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 Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.