plplot-devel

[Plplot-devel] java example precision changes and results

[Alan W. I. <ir...@be...>]

I made the following precision changes to all implemented java examples
where appropriate:

I have used the java-defined constant Math.PI instead of defining a
low-precision local PI or using inverse trig functions to get PI.  I found
this solution in the very helpful and detailed java tutorial at
http://java.sun.com/docs/books/tutorial/java/index.html.

All float --> double

Drop f suffix on numerical constants (e.g., 1.0f --> 1.0).  According to
the tutorial, floating point numbers without a suffix are interpreted as
double just like as in C.  The f suffix forces the constant to be single
precision which is exactly what we don't want.

The reason for these changes is to extirpate low-precison (as in PI) or
single precision for the reason (noted before) of getting more consistent
comparisons between demos on different machines.  In this case, the machine
is mixed; on the front end we have the JVM which we are comparing with gcc
results generated on ix86 for the C front end.  However, the back end
(libplplot) is identical for both front-end cases.

With these changes, all java examples other than the following noted
exceptions now give identical postscript results to the equivalent C
examples when double precision is configured for the back end.

x03: If I commented out the two plptex calls in the C and java code I got
identical results.  If you don't comment out these calls, you will visually
notice the "270" label produced by plptex is slightly different (different
pixelization).  So there is likely some floating-point logic in the
calculations that go into drawing the characters (in fact such logic must be
there by necessity, I believe). Thus, for characters at just the right
coordinates, the slightest change in those floating-point coordinates can
make a pixelization change in the the way the character is rendered.

x05: diff shows a minor discrepancy between the two plots which visually,
under high magnification seems to correspond to one more column of pixels in
the "l" in "probability" (at the top of the plot).  This x05 label
discrepancy might have a similar cause (floating-point logic in the
pixelization of the drawn characters) as the x03 label problem.

I have also done the comparisons between java and C front-end results using
the single-precision back end.  (To be clear about what I did, I did a make
clean, ./configure and make for both single and double precision with the
only configure difference being --with-double.  I also had to change the
name of the library appropriately in PLStream.java.) Since double-precision
is forced in both front-ends, and you are using the same (single-precision)
back-end in both cases, you would expect discrepancies between the java and
C results to be as small when single-precision is configured as for the case
when double-precison is configured.  This expectation seems to be confirmed
by the following results:

x03: similar discrepancy as in double-precision case.

x05: No discrepancy  in this case in contrast to double-precison case.

x08: shows a minor but opposite discrepancy to x05.  The double precision
versions are identical, but the single-precision versions differ slightly.

There does seem to be one java bug for the single-precison back end which
needs further investigation. For the double-precision back end, x01 gives
gives identical good results to the double-precision C example, but for the
single-precision back end the java example badly screws up the placement of
the line symbols.

So the current status of the java front end is that x01 through x11 (except
for x09) are done.  For these implemented examples, there is one clear bug
noted above that shows up in x01 for the single-precison back end.  Also the
plplot library name has to be configured in PLStream.java. Otherwise, we are
in pretty good shape with exact agreement in results with the C examples or
else for the few minor character-drawing discrepancies that do occur we have
a reasonable explanation.

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
__________________________

[Plplot-devel] java bug which showed up for x01 example in single-precision is now fixed.

[Alan W. I. <ir...@be...>]

On Tue, 30 Oct 2001, Alan W. Irwin wrote:

> There does seem to be one java bug for the single-precison back end which
> needs further investigation. For the double-precision back end, x01 gives
> gives identical good results to the double-precision C example, but for the
> single-precision back end the java example badly screws up the placement of
> the line symbols.

I found the bug in javabind.c and fixed it in CVS.  x01 for java now gives
identical results to x01c regardless of whether single-precision or
double-precison is configured for the PLplot back end.  (I also
inadvertently changed back the CVS version of PLStream.c so it refers to the
single-precision library, but I will probably leave that as is until
Geoffrey fixes the configuration.)

So aside from that one configuration issue, I am happy with the java
frontend codebase we now have both for single and double precision.

To follow up on this nice achievement lead by Geoffrey, I will concentrate
on implementing x09, x12, x13, x15, x16, and x18 in that order.  Once
Geoffrey has done the additional API binding required by those examples, the
java front end will actually be better off than the current python front end
(which does not have the 15th example implemented yet and which currently
segfaults for the 9th example).

Alan

RE: [Plplot-devel] java bug which showed up for x01 example in single-precision is now fixed.

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

Just winking in for a moment, in an otherwise massively out of control
week.

Alan W. Irwin writes:
 > On Tue, 30 Oct 2001, Alan W. Irwin wrote:
 > 
 > > There does seem to be one java bug for the single-precison back end which
 > > needs further investigation. For the double-precision back end, x01 gives
 > > gives identical good results to the double-precision C example, but for the
 > > single-precision back end the java example badly screws up the placement of
 > > the line symbols.
 > 
 > I found the bug in javabind.c and fixed it in CVS.  

Thanks.

 > x01 for java now gives identical results to x01c regardless of
 > whether single-precision or double-precison is configured for the
 > PLplot back end.

Thanks for noticing the problem, and for all th testing you have been doing.

 > (I also inadvertently changed back the CVS version of PLStream.c so
 > it refers to the single-precision library, but I will probably
 > leave that as is until Geoffrey fixes the configuration.)

Hopefully what I have just committed will be adequate.  Let me know
how it serves you.

 > So aside from that one configuration issue, I am happy with the java
 > frontend codebase we now have both for single and double precision.
 > 
 > To follow up on this nice achievement lead by Geoffrey, I will concentrate
 > on implementing x09, x12, x13, x15, x16, and x18 in that order.  Once
 > Geoffrey has done the additional API binding required by those examples, the
 > java front end will actually be better off than the current python front end
 > (which does not have the 15th example implemented yet and which currently
 > segfaults for the 9th example).

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.

Anyway, lest anyone get consumed by anticipation, there is still a
/lot/ of work to do on the Java binding.  Many many API function
wrappers remain to be implemented.

But we're certainly getting there, and thanks again to Alan for
helping out.

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

[Plplot-devel] single<-->double

[Alan W. I. <ir...@be...>]

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 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.  Java sorts it out (I assume through the magic
of OOP) into a call 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.

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

Alan

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

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

[Alan W. I. <ir...@be...>]

On Thu, 1 Nov 2001, Geoffrey Furnish wrote:

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

Thanks for that explanation.  I had heard of name mangling in the context
that g++ was having to deal with some name mangling issues for the
transition to 3.0, but this is the first time I have understood the purpose
of name mangling. One of the real pleasures of my participation in the
plplot project is it gives me a chance to greatly expand my programming
knowledge. I have always enjoyed learning new programming concepts, but only
if there was some practical focus, such as plplot, for that learning effort.

Alan

RE: [Plplot-devel] java bug which showed up for x01 example in single-precision is now fixed.

[Alan W. I. <ir...@be...>]

On Wed, 31 Oct 2001, Geoffrey Furnish wrote:

>  > [Alan said] (I also inadvertently changed back the CVS version of PLStream.c so
>  > it refers to the single-precision library, but I will probably
>  > leave that as is until Geoffrey fixes the configuration.)
>
> Hopefully what I have just committed will be adequate.  Let me know
> how it serves you.

Works great!  Thanks, Geoffrey, for dealing with this.

Alan