PLplot

On Wed, Jul 23, 2008 at 6:55 AM, Andrew Ross
<andrewross@...> 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

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
> <andrewross@...> 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
> Plplot-devel@...
> 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: smekal@...
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

On Wed, Jul 23, 2008 at 10:41 AM, Werner Smekal <smekal@...> 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

On 2008-07-23 11:35-0400 Hezekiah M. Carty wrote:

> On Wed, Jul 23, 2008 at 10:41 AM, Werner Smekal <smekal@...> 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
__________________________

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 <smekal@...> 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