From: Andrew R. <and...@us...> - 2008-07-23 10:55:40
|
I've been propagating the new plrandd, plrandi and plseed functions to some of the other language bindings in plplot. In the process I've made a few observations. I was away and missed the original discussion of the random number generator or I would have brought these points up then. I should say I'm not a big fan of bloating the plplot library with non-graphical routines, but the advantage of the random number generator in terms of reproducible results across all bindings is certainly worthwhile. 1) plrandd and plrandi are the only API functions in the plplot with a return value. All the pls* functions take pointers to variables to return values. I'm sure this was all decided before my time. Others may recall the precise reason. One advantage is that you can get back multiple values. Anyway, perhaps for consistency the plrand? functions should follow this convention. Personally I like functions with return values. It makes it possible to use the functions for inline code (as in the current C implementation of example 21. On the other hand it caused me some problems with the fortran bindings as I had no templates to work from! Fortran differentiates between subroutines (no return value) and functions which do return a value. 2) The types used by these functions are a bit loose. The use of unsigned long (usually 64 bit on modern hardware) as the return value for plrandi caused me some headaches with java until I realised that the return value is actually a 32-bit unsigned integer. (Java has no concept of unsigned type and so the largest positive integer you can have is actually 63 bits with the long type - crazy, but there you are. See google for the logic behind it.) We already have a PLUNICODE type which is set up to be 32 bit unsigned on all platforms. I'm not suggesting that plrandi returns a PLUNICODE since that would be confusing but we could either rename PLUNICODE to something more generic, or make a new type with the same logic (PLUINT32 perhaps?). The function plseed takes an unsigned int as an argument, although internally it is an unsigned long. The range is actually 32 bit unsigned as far as I can see. At least it should be consistent with plrandi, preferably with our new "PLUINT32" type. Any thoughts? Anyway, these comments aside, it is nice to finally have a uniform version of example 21 to compare different bindings. Andrew |
From: Hezekiah M. C. <hc...@at...> - 2008-07-23 14:23:49
|
On Wed, Jul 23, 2008 at 6:55 AM, Andrew Ross <and...@us...> wrote: > 2) The types used by these functions are a bit loose. The use of unsigned > long (usually 64 bit on modern hardware) as the return value for plrandi > caused me some headaches with java until I realised that the return > value is actually a 32-bit unsigned integer. (Java has no concept of > unsigned type and so the largest positive integer you can have is > actually 63 bits with the long type - crazy, but there you are. See > google for the logic behind it.) There are similar issues for OCaml. There are no stand-alone unsigned integer types included in the standard library. The current interface ignores the "unsigned" aspect and simply uses OCaml native integers, which are 31bits or 63bits depending on the architecture (32bits or 64bits - 1bit used for GC purposes). Would it be reasonable to make the interfaces take signed integers and then shift/cast them appropriately to unsigned values in the PLplot interface wrapper functions? This does not address the PLUNICODE issue you brought up, but it may make the interface to other languages - at least Java and OCaml? - simpler. Hez -- Hezekiah M. Carty Graduate Research Assistant University of Maryland Department of Atmospheric and Oceanic Science |
From: Werner S. <sm...@ia...> - 2008-07-23 14:41:32
|
Hi, that was the reason why I wanted to discuss the API and the problems - the present functions weren't meant to be the perfect solution. The random number generator returns an unsigned integer and is actually using the whole 32bit, so if it's casted to a singed integer, it's still random :), but the example 21 is then still not the same for different languages. I would actually propose to drop the plrandi() function and only use the plrandd() function, since a double should be available in all languages, or? If you need an integer, you need to multiply the double with the max value of your range. What do you think? Regards WErner On 23.07.2008, at 16:23, Hezekiah M. Carty wrote: > On Wed, Jul 23, 2008 at 6:55 AM, Andrew Ross > <and...@us...> wrote: >> 2) The types used by these functions are a bit loose. The use of >> unsigned >> long (usually 64 bit on modern hardware) as the return value for >> plrandi >> caused me some headaches with java until I realised that the return >> value is actually a 32-bit unsigned integer. (Java has no concept of >> unsigned type and so the largest positive integer you can have is >> actually 63 bits with the long type - crazy, but there you are. See >> google for the logic behind it.) > > There are similar issues for OCaml. There are no stand-alone unsigned > integer types included in the standard library. The current interface > ignores the "unsigned" aspect and simply uses OCaml native integers, > which are 31bits or 63bits depending on the architecture (32bits or > 64bits - 1bit used for GC purposes). > > Would it be reasonable to make the interfaces take signed integers and > then shift/cast them appropriately to unsigned values in the PLplot > interface wrapper functions? This does not address the PLUNICODE > issue you brought up, but it may make the interface to other languages > - at least Java and OCaml? - simpler. > > Hez > > -- > Hezekiah M. Carty > Graduate Research Assistant > University of Maryland > Department of Atmospheric and Oceanic Science > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win > great prizes > Grand prize is a trip for two to an Open Source event anywhere in > the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Hezekiah M. C. <hc...@at...> - 2008-07-23 16:18:31
|
On Wed, Jul 23, 2008 at 10:41 AM, Werner Smekal <sm...@ia...> wrote: > I would actually propose to drop the plrandi() function and only use the > plrandd() function, since a double should be available in all languages, or? > If you need an integer, you need to multiply the double with the max value > of your range. I like this approach. I think a float-based random number function is much more useful than one that is integer based. It is one less non-plotting function to maintain in the library, and in this case it seems that a few of the language bindings would be simpler as a result. Hez -- Hezekiah M. Carty Graduate Research Assistant University of Maryland Department of Atmospheric and Oceanic Science |
From: Alan W. I. <ir...@be...> - 2008-07-23 17:32:55
|
On 2008-07-23 11:35-0400 Hezekiah M. Carty wrote: > On Wed, Jul 23, 2008 at 10:41 AM, Werner Smekal <sm...@ia...> wrote: >> I would actually propose to drop the plrandi() function and only use the >> plrandd() function, since a double should be available in all languages, or? >> If you need an integer, you need to multiply the double with the max value >> of your range. > > I like this approach. Same here. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Andrew R. <and...@us...> - 2008-07-23 18:24:33
|
On Wed, Jul 23, 2008 at 10:33:02AM -0700, Alan Irwin wrote: > On 2008-07-23 11:35-0400 Hezekiah M. Carty wrote: > > > On Wed, Jul 23, 2008 at 10:41 AM, Werner Smekal <sm...@ia...> wrote: > >> I would actually propose to drop the plrandi() function and only use the > >> plrandd() function, since a double should be available in all languages, or? > >> If you need an integer, you need to multiply the double with the max value > >> of your range. > > > > I like this approach. > > Same here. I'll remove plrandi then. We only need the real version for the examples, which after all is the main reason for including it in the first place. Andrew |