From: Geoffrey F. <fu...@ga...> - 2002-05-20 04:39:36
|
Alan W. Irwin writes: > Geoffrey, I hope I will be clearer this time. > > The java wrapper for plcont obtains the number of contours from the array > object passed from java. So it is important that the number of contours in > that array object are exactly correct. Yes, completely agree. > The problem for the last two example pages is an attempt is made to plot > negative and positive contours, and there is no general way in advance at > the java level to know how the 20 total contours will be split between > negative and positive values until you calculate the contours from the range > of the data. I ran the example once to find out there are 10 of each so the > next time I preallocated 10 contours for each array with > > double [] clevelneg = new double[PNLEVEL/2]; > double [] clevelpos = new double[PNLEVEL/2]; > > That works, but running the example once to see what the array size is and > preallocating that space as a constant the second time you run it is > obviously not the most general or nice way to do it. Mmm, agree. > So at the java level I want to allocate the negative contour and positive > contour arrays after the number of each kind of contour has been calculated. Right, you should be able to do that. > After nlevelpos and nlevelneg were calculated by the code I tried to > allocate the array space using > > double [] clevelneg = new double[nlevelneg]; > double [] clevelpos = new double[nlevelpos]; That should work, looks fine to me. > but that failed to work. (I have forgotten the exact error message.) Really? Are you sure you're remembering correctly? > In java, how can you allocate an array of size nlevelneg (or nlevelpos) > where those numbers are calculated values rather than constants? Here is a small example I just whipped up on my computer: [furnish@xiphi ~]$ cat x.java public class x { public static void main( String[] args ) { System.out.println( "Running x." ); int n=0; for( int i=0; i < 10; i++ ) if (i % 2 == 0) n++; double [] v = new double[ n ]; System.out.println( "v.length = " + v.length ); } } [furnish@xiphi ~]$ setenv CLASSPATH . [furnish@xiphi ~]$ javac x.java [furnish@xiphi ~]$ java x Running x. v.length = 5 [furnish@xiphi ~]$ v is a dynamic array, with dynamic size calculation, and the resulting length is just what we expect. Seems to be working in this simple example. BTW, I'm running JDK 1.3.1 on my home system. > In java our current model seems to be plplot routines can only be called > with statically allocated arrays of constant size which must be exactly > correct, and that is not going to be very convenient to use for plcont or > any other PLplot function which has array arguments. Thus, I think this > is a general problem rather than just a problem with plcont. Well, I would say our current API works for intrinsic java arrays, which I personally think is just what we want. It is my belief that java arrays can be dynamically sized, as the above simple test program demonstrates. Would you mind trying again to make x09.java read the way you think it should be, and if that doesn't compile, e-mail it to me in the broken form, and I'll take a look at the exact specific problem you're having. It seems to me that your stated goal and approach, should work fine. > BTW, this is not a problem for the C front end because, first, you can alloc > the array dynamically (say with plAlloc2dGrid) and, second, also specify the > exact number of elements as one of the arguments. Also, it is not a problem > for the python front end since the arrays are allocated dynamically with the > calculated size that you want. If we cannot dynamically allocate java array > objects, then I believe we need to move to a different array-like java > object that can be dynamically allocated for *all* our plplot functions that > require arrays. I believe there is a java object called a vector that > filled the bill for early versions of java, but we may need something else > now. I looked at the discussion of vector and ArrayList in > http://java.sun.com/docs/books/tutorial/collections/implementations/general.html, > and it looks like vector has legacy problems, and ArrayList is now > preferred, but I don't know how to convert are examples and javabind.c so > that we replace all java array objects with java ArrayList objects. I need a little more convincing that the dynamic approach isn't working. Maybe there's a subtlety that's escaping me here, but my current belief is that what you are trying to do, should work. Show me the code that doesn't work like you expect, and I'll dig in. Java has overloading, so it may be possible for us to have an API that also takes ArrayLists. However, I'm not totally clear on how to figure out what exact sort of object a JNI jobject * is. It seems to me the JNI literature gets pretty skimpy on details at exactly the point where the obvious stuff drops off and the nonobvious stuff picks up. I have some pretty significant JNI project work ahead of me over the summer at Lightspeed, so by the time I've lived through a few more months of it, I should know JNI pretty well. Maybe we can take up the ArrayList overlaoding idea then. -- Geoffrey Furnish fu...@ga... |