RE: [Plplot-devel] single<-->double

[Geoffrey F. <fu...@ga...>]

Alan W. Irwin writes:
 > On Wed, 31 Oct 2001, Geoffrey Furnish wrote:
 > 
 > > Also, I think the java binding is probably the only one that does the
 > > automatic float<-->double conversion thing.  I'm undecided about
 > > whether that is something we want in a compiled binding like C++, but
 > > I am pretty sure we /do/ want this kind of functionality for the
 > > script language bindings.  Not that "script language" is an accurate
 > > characterization of java, but you know what I mean.  OTOH, I haven't
 > > ever looked deeply at the Perl or Octave work, so perhaps there is
 > > coolness there that I don't even know about.
 > 
 > Could you summarize in one or two sentences how your treatment of
 > single-precision or double-precision java arguments relates to
 > object-oriented programming concepts such as classes, sub-classes,
 > instances, etc? 

I don't really think of it has having anything to do with OOP.  We're
just overloading each of the PLplot API calls with two versions, and
implmeenting them both.  One passes directly to the PLplot C call, the
other transforms its arguments to PLFLT and then makes the call.  This
fits easily enough in the realm of procedural thinking.

The only reall OO-ness in any of this, is the PLStream class.  Here I
do feel like a stream is the central object modelling concept for
wrapping the PLplot API.  Were PLplot itself implemented in C++, we'd
probalby also have abstract classes for things like devices, maybe
coordinate transformers, etc.

 > I am really new to these concepts (I only read the general
 > Java tutorial on OOP, yesterday, plus some of the equivalent part of my
 > python book) so I am trying to relate what you have done to my limited
 > knowledge of OOP.
 > 
 > Anyhow, the result is the java user can use the same name of plplot routine
 > regardless of type of argument and regardless of whether the back-end was
 > built --with-double or not.  

Right, this is called overloading.  

 > Java sorts it out (I assume through the magic of OOP) into a call

Overloading is accomplished through a technique known as "name
mangling", whereby the compiler synthesizes the name of the function
to be called from a combination of its given name, plus the number and
types of the presented arguments.  Once the name is generated, the
linker just has to hook up the name to the address of the function.  

 > to one of two versions of the function in javabind.c with either
 > single or double-precision arguments.  Once the appropriate version
 > is entered, the code handles the assignment (with appropriate cast
 > if needed) of the single (or double) precision quantities to PLFLT
 > quantities in a nice way.

Right.  It would actually be nice if we could support mixed types.
That is, in java the user calls PLStream.whatever() with any sort of
numeric type he's got, and then we sort it out on the other side.  You
can probably pull off something like that in Python, which is not
staticaly typed.  But for languages like C++ and Java, which are
staticaly typed, you're gonna have to write a separate overloading for
each combination you want to be allowable.  I choose two, one with all
floats, and one with all doubles.

Don't get me wrong.  I like static typing, and don't really like
dynamic typing.  Stroustrup's published arguments about the merits of
static typing hold a lot of weight with me.  But I'm just saying,
since Python is dynamically typed, it would be /possible/ to support a
totally flexible approach there.  I haven't really reviewed the Python
binding code (plmodule.c) lately, so maybe it already does this in
some cases.  I don't really remember clearly.  I seem to remember you
had to configure --with-double for the python binding, and that you
couldn't use float numpy arrays, but my memory on this point is foggy
at best.

 > Assuming this transparent (for the user) implementation of transforming
 > float or double arguments to PLFLT depends to a certain extent on OOP, then
 > it would be natural as a *long-term* goal to use the same idea for the other
 > front-ends such as c++, python, and perl that also give access to OOP.  I

It's na overloading thing.

Yeah, I think I agree.  The argument seems strong for these VHLL's
like Python, Perl, even Java (dunno if it qualifies stictly as a VHLL,
but it sure ain't C++ no matter what the hypists say).

In the case of C++, you're dealling with a language environment that
/can/ be very computationaly efficient (if you don't do idiotic things
in the C++ code).  So a silent buffering scheme might provide a
convenient binding, but be simultaneously annoying by virtue of
masking substantial performance sinks.  

What I would rather do in C++, is use templates to support floating
point type flexibility.  But to implement it right might mean
implementing large parts of the PLplot core library itself in C++.  

Left to myself, I'd convert all PLplot C files to C++ in a day.  But
previous discussions on the plplot mailing list over the years made it
clear this was an unpopular notion.  Sufficiently unpopular to
threaten PLplot's market share.  So I've never pursued it.  I think
the reality is that somehow we have to think of a C++ binding as a
"wraper" around the C PLplot API, pretty much like we do with Java
now. 

The current C++ binding falls short of this.  Maybe after we have the
Java binding in good shape, we could revisit how to spiff up the C++
binding. 

 > don't know whether octave allows OOP.  Yorick certainly doesn't so yplot
 > only works with the double-precision version of the PLplot library.

Without having looked, I would still expect that it would be possible
for the yorick wrappers to do something like the buffering scheme
currently exhibited in javabind.c, so that yorick could be hooked up
to a libplplot even if it was the float version.

-- 
Geoffrey Furnish         fu...@ga...