From: Tom Anderson on 2 Jan 2010 08:21 On Sat, 2 Jan 2010, Tom Anderson wrote: > On Sat, 2 Jan 2010, Albretch Mueller wrote: > >> This discussion started with comp.lang.java.programmer: >> "java.lang.Rational" I will publish the algorithm/results of my code within >> a week. Some of use believe such a library should be included by Sun > > The problem of a bigger-than-int list has certainly come up before, and > a general-purpose implementation would be useful. In fact, i'd be mildly > surprised if there wasn't already one in either the Apache or Google > collections libraries - have you checked those? Hmm, it seems they don't. Nor does Javolution. If anyone's interested in writing a long-indexed list, i've had a quick cut at the groundwork (compiled, but neither tested nor documented!): http://urchin.earth.li/~twic/Code/BigCollections/ All you'd need to do to implement a big list would be to subclass AbstractBigList and fill in the blanks. tom -- History, I believe, furnishes no example of a priest-ridden people maintaining a free civil government. -- Thomas Jefferson
From: rossum on 2 Jan 2010 08:22 On Fri, 1 Jan 2010 18:42:36 -0800 (PST), Albretch Mueller <lbrtchx(a)gmail.com> wrote: >~ > java only uses int indexes which is giving me a hard time since I >need to index values over Integer.MAX_VALUE. The size of the data >array itself is not a problem at all and I am using a BitSet As has been suggested you might want to use an array of longs, treating each long as a set of 64 bits. Alternatively an array of bitsets might be easier to program. >~ > I need indexes greater than Integer.MAX_VALUE in connection to >dynamic sieves to calculate prime numbers. If you are sieving for large primes then you can compress your bitmaps substantially. If each bit only represents an odd number then you have doubled your capacity - there are no large even primes. Similarly for multiples of 3 and 5. You will need to adjust the calculations slightly but it does reduce the data storage needed for the bitmaps. rossum >You are gonna get bitten by >these exceptions if you go as far as: >~ > ( 2 * 3 * 5 * 7 * 11 * 13 * 17 * 19 * 23 * 29 ) = 6469693230 >~ > That number is risibly small but you cannot use it as an index in >Java ... >~ > How do you deal with such issues? >~ > Thanks > lbrtchx
From: Albretch Mueller on 2 Jan 2010 13:29 ~ Now, I wonder if you will go LOL (as I did) or cry about this. As a straightforward way to index over Integer.MAX_VALUE I wishfully thought of using a Memory-mapped file as some sort of (very expensive) buffer, but well sun microsystems is at least consistent in their nonsense ~ Using a Memory-mapped file and doing the bit crunching I will have my cake and it is too (at least for all 10 primes less than 30) since ~ ( 2 * 3 * 5 * 7 * 11 * 13 * 17 * 19 * 23 * 29 ) = 6469693230 < 17179869176 ~ but I will be in for some voodoo and and hax to reach out passed that number ~ Specially now that 64-bit machines are common, if any of you has a say at sun could you please raise this issue with them? Yeah sure I can switch to ANSI C/C++ and leave this whole nonsense behind but I want to code/test implementations in all three c-fam languages ~ lbrtchx ~ $ java MemMappedIO00Test /media/hdb2/tmp/test.dat // __ Setting up Random Access Mapped Byte Buffer for 25769803760 bits Exception in thread "main" java.lang.IllegalArgumentException: Size exceeds Integer.MAX_VALUE at sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:704) at MemMappedIO00Test.main(MemMappedIO00Test.java:52) ~ /* // clobbered from thinking_in_java/TIJ314_029.htm */ import java.io.*; import java.util.*; import java.text.*; import java.nio.*; import java.nio.channels.*; // __ public class MemMappedIO00Test{ private static final String aNwLn = System.getProperty ("line.separator"); private static final String aEnc = "UTF-8"; // __ private static final void setOutErr(File ODir, String aPrfx, long lTm00, boolean IsOut, boolean IsErr){ String aLogFl = aPrfx + "_" + (new SimpleDateFormat ("yyyyMMddHHmmss")).format(new Date(lTm00)); try{ if(IsOut){ PrintStream POS = new PrintStream((new FileOutputStream (new File(ODir, aLogFl + ".out.txt"))), true, aEnc); System.setOut (POS); } if(IsErr){ PrintStream PES = new PrintStream((new FileOutputStream (new File(ODir, aLogFl + ".err.txt"))), true, aEnc); System.setErr (PES); } }catch(FileNotFoundException FNFX){ FNFX.printStackTrace(); } catch(IOException IOX){ IOX.printStackTrace(); } } // __ public static void main(String[] args) throws Exception{ // __ long lTm00 = System.currentTimeMillis(); String aKNm = "MemMappedIO00Test"; File ODir = new File(new File((new File(".").getAbsolutePath ())).getParent()); setOutErr(ODir, aKNm, lTm00, true, false); // __ ODir = new File("."); String aOFl = "_.dat"; File OFl = new File(ODir, aOFl); System.err.println(OFl.getAbsolutePath()); long lL = (long)Integer.MAX_VALUE; lL += (long)Integer.MAX_VALUE/2; System.out.println("// __ Setting up Random Access Mapped Byte Buffer for " + (8*lL) + " bits"); System.err.println("// __ Setting up Random Access Mapped Byte Buffer for " + (8*lL) + " bits"); // __ MappedByteBuffer out = new RandomAccessFile(OFl, "rw").getChannel ().map(FileChannel.MapMode.READ_WRITE, 0, lL); for(int i = 0; i < lL; ++i){ out.put((byte)255); } // __ long lTm02 = System.currentTimeMillis(); System.out.println("// __ in " + (lTm02 - lTm00) + " (ms)"); System.err.println("// __ in " + (lTm02 - lTm00) + " (ms)"); // __ } }
From: Joshua Cranmer on 2 Jan 2010 14:13 On 01/01/2010 10:00 PM, Arne Vajh�j wrote: > There are no super good solution. They mad a mistake 15 years > ago in the design and did not make array indexes long. 15 years ago, I don't think computers existed that could hold enough memory to make a 63-bit index anything more than redundant. IIRC, it wasn't until the beginning of this decade or so that arrays grew large enough to uncover a bug in their binary search implementation. So, 15 years ago, it wasn't a mistake. -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
From: Arne Vajhøj on 2 Jan 2010 14:28
On 02-01-2010 14:13, Joshua Cranmer wrote: > On 01/01/2010 10:00 PM, Arne Vajh�j wrote: >> There are no super good solution. They mad a mistake 15 years >> ago in the design and did not make array indexes long. > > 15 years ago, I don't think computers existed that could hold enough > memory to make a 63-bit index anything more than redundant. IIRC, it > wasn't until the beginning of this decade or so that arrays grew large > enough to uncover a bug in their binary search implementation. So, 15 > years ago, it wasn't a mistake. I think it was. Because when designing a language one should not just consider the requirements for today but also the requirements for the future for all the years the language is expected to be used. If we say that memory sizes double every two years, then it is easy to make a prediction. BTW, even long would be too small for indexes if Java will be used after 2074, but somehow I doubt that would be the case. And besides we do not have the verylong datatype yet. Arne |