From: Geoffrey F. <fu...@ga...> - 2001-10-26 17:59:52
|
Just to let you all know, I've done what I can do for a while. I probably won't be able to respond to anything for 10 days or so. I've committed the minor mod to dyndrv.in which links all drivers against libplplot.so, needed to allow dynamic drivers to be used in the java binding. I was surprised Alan was able to work with the java binding without that patch. Alan, did you use both --enable-dynamic-drivers, and --enable-java? If so, maybe this more restrictive dlopen semantics was a JDK 1.3 innovation. Anyway, that fix is in, shouldn't disrupt anything else, except that it brings back library/driver coupling we were hoping to avoid. Fixing that will require some work with one of these structs of function pointers ideas we've discussed before. I entered a task on that in the java binding dev list. I suppose it could be a dyndriver project tasklist, but since I found it in the context of java, I just put it there. It would be good to see task lists for other thrust areas, just so we can form a clearer picture of where we really stand. Anyway, I also knocked out a little more JNI work, real quick. And I've concluded that it looks to me like x11.java doesn't actually set up the data the same way as x11c.c. I bet the same is happening in x08.java/x08c.c, which probably explains the slight discrepancy in the shade plots that I mumbled about before. After a quick peek at the codes, I'm guessing it comes down to how x[] is initialized. Alan, if you look at this, you'll see I used "2." in the java demos, where the C demos used just "2". :-). I did the "2." thing in Java, as I recall, to supress a cast. I confess to finding such matters confusing in the C case. What does the C (double) cast do? Is that an integer division the result of which is then cast to double? In which case I wouldn't expect hte abscissa to be smooth. Or does it somehow make the seemingly integer division actually be performed in double? Sheesh. I should know C better, but anyway, I bet the problem has to do with this. Think you can figure it out? Or if you want to leave it to me, that's fine, but I don't promise to fix it soon :-). I'd rather work on the JNI binding, than figure out these bizarrdoms of C/Java numerical experssion semantics. (yeah, I know this sounds lame, sorry). I guess all I'm saying is, I don't see anything wrong with the code per se, so it doesn't seem to me like something that necessarily /has/ to be fixed before a release. But someday, we should probably make sure the C/java demos actually display /exactly/ the same plots. At least x08 and x11 are probably affected by the same bug, which is probably my fault. -- Geoffrey Furnish fu...@ga... |
From: Alan W. I. <ir...@be...> - 2001-10-26 18:39:09
|
My java tests were with the static drivers so I guess I avoided the dyn driver problem that you found with java. I will look at the x08 examples in C and java and try to get them to give identical results. Same for x11. Thanks for implementing the mesh API. I will try to have at least one more java demo ready for you (except for any required java API extensions) by the time you come back. Alan email: ir...@be... phone: 250-727-2902 FAX: 250-721-7715 snail-mail: Dr. Alan W. Irwin Department of Physics and Astronomy, University of Victoria, P.O. Box 3055, Victoria, British Columbia, Canada, V8W 3P6 __________________________ Linux-powered astrophysics __________________________ On Fri, 26 Oct 2001, Geoffrey Furnish wrote: > Just to let you all know, I've done what I can do for a while. I > probably won't be able to respond to anything for 10 days or so. > > I've committed the minor mod to dyndrv.in which links all drivers > against libplplot.so, needed to allow dynamic drivers to be used in > the java binding. I was surprised Alan was able to work with the java > binding without that patch. Alan, did you use both > --enable-dynamic-drivers, and --enable-java? If so, maybe this more > restrictive dlopen semantics was a JDK 1.3 innovation. Anyway, that > fix is in, shouldn't disrupt anything else, except that it brings back > library/driver coupling we were hoping to avoid. > > Fixing that will require some work with one of these structs of > function pointers ideas we've discussed before. I entered a task on > that in the java binding dev list. I suppose it could be a dyndriver > project tasklist, but since I found it in the context of java, I just > put it there. > > It would be good to see task lists for other thrust areas, just so we > can form a clearer picture of where we really stand. > > Anyway, I also knocked out a little more JNI work, real quick. > > And I've concluded that it looks to me like x11.java doesn't actually > set up the data the same way as x11c.c. I bet the same is happening > in x08.java/x08c.c, which probably explains the slight discrepancy in > the shade plots that I mumbled about before. After a quick peek at > the codes, I'm guessing it comes down to how x[] is initialized. > Alan, if you look at this, you'll see I used "2." in the java demos, > where the C demos used just "2". :-). I did the "2." thing in Java, > as I recall, to supress a cast. I confess to finding such matters > confusing in the C case. What does the C (double) cast do? Is that > an integer division the result of which is then cast to double? In > which case I wouldn't expect hte abscissa to be smooth. Or does it > somehow make the seemingly integer division actually be performed in > double? Sheesh. I should know C better, but anyway, I bet the > problem has to do with this. Think you can figure it out? Or if you > want to leave it to me, that's fine, but I don't promise to fix it > soon :-). I'd rather work on the JNI binding, than figure out these > bizarrdoms of C/Java numerical experssion semantics. (yeah, I know > this sounds lame, sorry). > > I guess all I'm saying is, I don't see anything wrong with the code > per se, so it doesn't seem to me like something that necessarily /has/ > to be fixed before a release. But someday, we should probably make > sure the C/java demos actually display /exactly/ the same plots. At > least x08 and x11 are probably affected by the same bug, which is > probably my fault. > > -- > Geoffrey Furnish fu...@ga... > > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > |
From: Joao C. <jca...@in...> - 2001-10-26 19:33:25
|
On Friday 26 October 2001 18:59, Geoffrey Furnish wrote: | Just to let you all know, I've done what I can do for a while. I | probably won't be able to respond to anything for 10 days or so. | | I've committed the minor mod to dyndrv.in which links all drivers | against libplplot.so, needed to allow dynamic drivers to be used in | the java binding.=20 Geoffrey, it looks that you forgot to rebuild the drivers at instalation= =20 time and user INSTALL_RPATH? Joao |
From: Geoffrey F. <fu...@ga...> - 2001-10-27 04:37:40
|
Joao Cardoso writes: > On Friday 26 October 2001 18:59, Geoffrey Furnish wrote: > | Just to let you all know, I've done what I can do for a while. I > | probably won't be able to respond to anything for 10 days or so. > | > | I've committed the minor mod to dyndrv.in which links all drivers > | against libplplot.so, needed to allow dynamic drivers to be used in > | the java binding. > > Geoffrey, it looks that you forgot to rebuild the drivers at instalation > time and user INSTALL_RPATH? Mmm, probably true. Thanks for noticing. Can you enter a task manager ticket on this so we don't forget it? |
From: Alan W. I. <ir...@be...> - 2001-10-29 21:31:42
|
To address the issue of how well the java examples produce identical results to the C examples, it is important to have double precision. Thus, I have just committed the change to PLStream.java to use libplplotd rather than libplplot. This is just a temporary convenience for my tests and will presumably be superseded by Geoffrey's eventual configuration change to deal with this issue. I have just changed x08.java and x11.java following the casts from integer in the C code (see comments below in the context of Geoffrey's comments). The result is these java examples now produce identical results to x08c and x11c. This means that at least for this subset of the java plplot API, it appears with-double is working. Now I have these two java examples giving consistent results with the C examples, I intend to sytematically check all java example results against their C example counterparts. Alan email: ir...@be... phone: 250-727-2902 FAX: 250-721-7715 snail-mail: Dr. Alan W. Irwin Department of Physics and Astronomy, University of Victoria, P.O. Box 3055, Victoria, British Columbia, Canada, V8W 3P6 __________________________ Linux-powered astrophysics __________________________ On Fri, 26 Oct 2001, Geoffrey Furnish wrote: > I confess to finding such matters > confusing in the C case. What does the C (double) cast do? Is that > an integer division the result of which is then cast to double? That's my understanding. > In > which case I wouldn't expect hte abscissa to be smooth. I agree they are not completely smooth, but the degree of non-smoothness is so low it does not detract from the plot. > Think you can figure it out? Done, see above. Alan |