Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / July 2007

Tip: Looking for answers? Try searching our database.

Possible Loss of Precision - not caused by type conversion

Thread view: 
Thomas - 07 Jul 2007 15:57 GMT
Hope I will not get banned for too many posts :)
The code below does not want to compile. I get ""Possible Loss of Precision"
in the lines:
'j=last;'

'sito[j]=i;'

'increase(i,last);'

Whats wrong with it ?
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////////////

package narzedzia;
public  class LiczbyPierwsze {
protected final static long length = 21;
protected final static long sito [] = new long [(long)1<<length];

// inicjalizacja sita :

{
sito[0]=1;
sito[1]=1;

long last  = 0L;
long j;
long i =2;
while(i<length){  // in i we got the following prime
 j=last;
 while(j<length){    // we mark the numbers whose smallest divisor is i
  if(sito[j]== j);
   sito[j]=i;
  j+=i;
  }
increase(i,last);  // we count the next prime for the sive
}
}

public final static long czyPierwsza(long x ){
;
return 0;
}

public final static long naCzynnikiPierwsze(long x){
;
return 0;
}
private final static void increase(long x, long last){
while(sito[last++]!=(long)0);
   x =(long)sito[last];
}

}
Lew - 07 Jul 2007 16:34 GMT
> Hope I will not get banned for too many posts :)
> The code below does not want to compile. I get ""Possible Loss of Precision"
> in the lines:

> long last  = 0L;
> long j;
> long i =2;
...
> 'j=last;'
>
>  'sito[j]=i;'

Maybe because
> Arrays must be indexed by int values; short, byte, or char values may also be used as index values because they are subjected to unary numeric promotion (§) and become int values. An attempt to access an array component with a long index value results in a compile-time error.
<http://java.sun.com/docs/books/jls/third_edition/html/arrays.html#10.4>

>  'increase(i,last);'
The value of i will not change from this call - you knew that, yes?

> private final static void increase(long x, long last){
>  while(sito[last++]!=(long)0);
>     x =(long)sito[last];
>  }

The value of x from the assignment is thrown away.

Signature

Lew

Thomas - 07 Jul 2007 17:08 GMT
> > Hope I will not get banned for too many posts :)
> > The code below does not want to compile. I get ""Possible Loss of Precision"
[quoted text clipped - 10 lines]
> Maybe because
> > Arrays must be indexed by int values; short, byte, or char values may also be used as index values because they are subjected to unary numeric
promotion (§) and become int values. An attempt to access an array component
with a long index value results in a compile-time error.
> <http://java.sun.com/docs/books/jls/third_edition/html/arrays.html#10.4>
>
[quoted text clipped - 10 lines]
> --
> Lew

The value of i will not change from this call - you knew that, yes?

Well I know, but I forgot :).
Now after changing from long to int it works. Java sux if it doesn't allow
on more flexibilty. THX
Lew - 07 Jul 2007 17:44 GMT
"Lew" <lew@lewscanon.nospam> napisa� w wiadomo�ci
>> Maybe because
>>> Arrays must be indexed by int values; short, byte, or char values may also be used as index values because they are subjected to unary numeric promotion (�) and become int values. An attempt to access an array component with a long index value results in a compile-time error.
>> <http://java.sun.com/docs/books/jls/third_edition/html/arrays.html#10.4>

> Now after changing from long to int it works. Java sux if it doesn't allow
> on more flexibilty. THX

If you have an array of long with 2 billion entries it will occupy over 16GB
of heap - the issue of your index will be moot.

Since arrays are limited to (Integer.MAX_VALUE + 1) entries, using a long
index risks an out-of-bounds problem, hence the restriction to int indexes.
You used a long, which in conversion to int risks losing precision, and this
is the error you got.  In today's world an array with more entries than that
is not manageable anyway.

You can always downcast the long index to int for use in the indexing expression.

I do not begin to guess how you can characterize this as an issue of
"flexibility".

Signature

Lew

getsanjay.sharma@gmail.com - 07 Jul 2007 18:32 GMT
> "Lew" <l...@lewscanon.nospam> napisa? w wiadomo?ci
> I do not begin to guess how you can characterize this as an issue of
> "flexibility".

I agree. Plus no one 'forces' anyone to use arrays. You can always use
'Arraylist' if you want _flexibility_.
Lew - 07 Jul 2007 18:55 GMT
>> "Lew" <l...@lewscanon.nospam> napisa? w wiadomo?ci
>> I do not begin to guess how you can characterize this as an issue of
>> "flexibility".
>
> I agree. Plus no one 'forces' anyone to use arrays. You can always use
> 'Arraylist' if you want _flexibility_.

Although it lacks the particular feature the OP wanted, the ability to index
outside the int range.

Signature

Lew

getsanjay.sharma@gmail.com - 07 Jul 2007 20:51 GMT
> Although it lacks the particular feature the OP wanted, the ability to index
> outside the int range.

I know it sounds expensive memory wise but OP can always use the Hash
Map and with the autoboxing  capability, he can index outside the int
range.
Twisted - 07 Jul 2007 21:55 GMT
> If you have an array of long with 2 billion entries it will occupy over 16GB
> of heap - the issue of your index will be moot.

Yeah, since 640K really ought to be enough for anybody, even far into
the future ... ;)
Patricia Shanahan - 07 Jul 2007 22:18 GMT
> "Lew" <lew@lewscanon.nospam> napisa� w wiadomo�ci
>>> Maybe because
[quoted text clipped - 11 lines]
> If you have an array of long with 2 billion entries it will occupy over
> 16GB of heap - the issue of your index will be moot.

Not if you have a 64 bit JVM and a server with a large memory.

Patricia
Lew - 07 Jul 2007 23:01 GMT
Lew wrote:
>> If you have an array of long with 2 billion entries it will occupy
>> over 16GB of heap - the issue of your index will be moot.

> Not if you have a 64 bit JVM and a server with a large memory.
(and -Xmx configured accordingly)

Good catch - even though I have a 64b machine for my own development I keep
forgetting what a huge difference it makes.  I found
<http://msdn2.microsoft.com/en-us/vstudio/aa700838.aspx>
which examines the effect objectively for both .NET and Java (IBM WebSphere
with their JVMs).

I agree that an argument can be made that it was shortsighted of Sun to limit
array indexes to int, but the fact is that they did and it is documented in
the JLS.  Does Sun have a plan to change this, or to introduce a large-array
type to Java?  A sparse-array type?

I foresee when people will superciliously disparage those who once thought 64
bits provided enough address range, along the lines of those now parroting the
"and you thought 640K is enough" canard.

Signature

Lew

Karl Uppiano - 07 Jul 2007 23:59 GMT
> Lew wrote:
>>> If you have an array of long with 2 billion entries it will occupy over
[quoted text clipped - 17 lines]
> 64 bits provided enough address range, along the lines of those now
> parroting the "and you thought 640K is enough" canard.

Technology marches on, but the idea of using 'int' for array indices was
probably a compromise between performance and size for computers of the mid
1990s. The question I have to ask, how often does someone need to look up
one of 2 billion entries that quickly, and does it make sense to have it all
in memory at once? If not, then an array might not be the right data
structure anyway.
Arne Vajhøj - 08 Jul 2007 00:15 GMT
> Technology marches on, but the idea of using 'int' for array indices was
> probably a compromise between performance and size for computers of the mid
> 1990s. The question I have to ask, how often does someone need to look up
> one of 2 billion entries that quickly, and does it make sense to have it all
> in memory at once? If not, then an array might not be the right data
> structure anyway.

True.

But should the language enforce the restriction ?

Arne
Karl Uppiano - 08 Jul 2007 02:07 GMT
>> Technology marches on, but the idea of using 'int' for array indices was
>> probably a compromise between performance and size for computers of the
[quoted text clipped - 6 lines]
>
> But should the language enforce the restriction ?

Not it a perfect world, but perhaps in a practical one.
Patricia Shanahan - 08 Jul 2007 00:20 GMT
>> Lew wrote:
>>>> If you have an array of long with 2 billion entries it will occupy over
[quoted text clipped - 23 lines]
> in memory at once? If not, then an array might not be the right data
> structure anyway.

Of course one would want other data structures, such as rectangular
matrix, but array is a good starting point. Most data structure
operations can be expressed in terms of array access, and several of
Java's Collection classes are effectively built on arrays.

There are a lot of tasks that can be done out-of-core, with explicit
program transfers between slices of a file (representing the logical
array) and chunks of memory. However, such algorithms are significantly
more complicated to code than their in-core equivalents. For example, I
remember a program for solving 50,000 linear equations in double complex
that was primarily a data movement program, copying chunks of a single
logical array between files and memory.

At each memory increase so far, there have turned out to be jobs that
were best expressed using a single array occupying most of the new
memory size. One of the benefits of increased memory size is making
those jobs simpler, by allowing the natural large array representation.
Why should the Integer.MAX_VALUE boundary be different?

Patricia
Karl Uppiano - 08 Jul 2007 02:09 GMT
>>> Lew wrote:
>>>>> If you have an array of long with 2 billion entries it will occupy
[quoted text clipped - 42 lines]
> those jobs simpler, by allowing the natural large array representation.
> Why should the Integer.MAX_VALUE boundary be different?

I don't know the answer to that. But the engineers that designed Java made
many good decisions; they weren't stupid. They might have made a mistake,
but my gut tells me that it is more likely a typical case of an engineering
compromise, a trade-off.
Roedy Green - 09 Jul 2007 21:59 GMT
On Sun, 08 Jul 2007 01:09:55 GMT, "Karl Uppiano"
<karl.uppiano@verizon.net> wrote, quoted or indirectly quoted someone
who said :

> But the engineers that designed Java made
>many good decisions; they weren't stupid.

Considering they were designing for TV set top box, Java was
remarkably open ended.

I got to meet and talk with Bill Joy.  I came away greatly relieved.
He was very intelligent. He was taking into consideration all the
things about Java design I was worried about and many others besides,
and looking to the best compromise.  Often the limit is just time and
money. Change is expensive.

--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
Twisted - 08 Jul 2007 02:03 GMT
> I agree that an argument can be made that it was shortsighted of Sun to limit
> array indexes to int, but the fact is that they did and it is documented in
> the JLS.  Does Sun have a plan to change this, or to introduce a large-array
> type to Java?  A sparse-array type?

Java already HAS a sparse-array type -- it's called HashMap<Long,
Foo>. Actually, it has HashMap<BigInteger, Foo> as well if you really
need it.
Lew - 08 Jul 2007 14:25 GMT
Lew wrote:
>> Does Sun .. plan ... to introduce a ... sparse-array type?

> Java already HAS a sparse-array type -- it's called HashMap<Long,
> Foo>. Actually, it has HashMap<BigInteger, Foo> as well if you really
> need it.

Excellent point.

Signature

Lew

Roedy Green - 09 Jul 2007 21:45 GMT
>I agree that an argument can be made that it was shortsighted of Sun to limit
>array indexes to int, but the fact is that they did and it is documented in
>the JLS.  Does Sun have a plan to change this, or to introduce a large-array
>type to Java?  A sparse-array type?

The problem with giant arrays is garbage collection. You have to copy
these great monsters around and find holes big enough for them.  From
a GC point of view, it might make sense to implement an big array as a
number of smaller arrays.  

So what we might see is a BigArrayList which works just like ArrayList
with long indexes.  It would likely handle allocate ram 64K or so at a
pop as needed, so it would work for some types of sparce array.

The alternative would be to shove giant objects around by fiddling the
mapping hardware, leaving the object fixed.

You could implement big arrays as a new LongArrayList that uses some
native classes to manage indexing with 64-bits.  This would be
considerably easier than adding 64-bit indexing to the language.

--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
Patricia Shanahan - 09 Jul 2007 22:14 GMT
...
> So what we might see is a BigArrayList which works just like ArrayList
> with long indexes.  It would likely handle allocate ram 64K or so at a
> pop as needed, so it would work for some types of sparce array.
...

But what about dense large arrays? There is no particular reason to
assume that large arrays are sparse. A lot are not.

Patricia
bugbear - 10 Jul 2007 11:13 GMT
> ...
>> So what we might see is a BigArrayList which works just like ArrayList
[quoted text clipped - 4 lines]
> But what about dense large arrays? There is no particular reason to
> assume that large arrays are sparse. A lot are not.

Roedy's idea also improves the operation needed to *grow* such
an array, assuming the final size was not known at constructor time.

  BugBear
Twisted - 10 Jul 2007 12:08 GMT
> > ...
> >> So what we might see is a BigArrayList which works just like ArrayList
[quoted text clipped - 7 lines]
> Roedy's idea also improves the operation needed to *grow* such
> an array, assuming the final size was not known at constructor time.

Want huge, dense or sparse arrays indexed by e.g. BigIntegers right
now without waiting for Sun? Use a TreeMap<BigInteger, Foo>...log n
instead of constant access time is the price you pay though.
Patricia Shanahan - 07 Jul 2007 17:38 GMT
> Hope I will not get banned for too many posts :)
> The code below does not want to compile. I get ""Possible Loss of Precision"
> in the lines:
> 'j=last;'
...

I don't understand that particular error, and Eclipse did not report it.
j and last are both of type long, so the assignment should be valid.

There is an error on each attempt to use a long as an array index. That
is due to the unfortunate decision to limit Java arrays by using int for
array size and index.

Patricia


Free Magazines

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

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
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.