Subject: Numerics Working Group Report

From: [email-masked] (Ronald F Boisvert)
Date: Tue, 1 Sep 1998 16:48:50 -0400

Joe Darcy has made a number of changes to the floating-point
section of the Working Group report to expand on various
points and to clarify some issues.  The URL

    http://math.nist.gov/javanumerics/report-v3.html

now points to the updated version.  There remains a link to the
previous version, along with a Unix diff file to show the changes
applied.

Joe is the only one who has provided comments to date.  I hope
that more of you will take the time to read this document
carefully and comment on it.  Does it reflect the consensus of
the working group as best you understand it?

We have recently have had discussions with James Gosling and Tim
Lindholm on these issues. They are very interested in our input,
especially on what to do with floating-point for Java 1.2.

I would like to have all comments by a week from today so
that I can polish the document for a public release.

Thanks.

Ron Boisvert

---

From: [email-masked]
Date: Wed, 9 Sep 1998 08:04:11 -0400

Hello,

Some more remarks on my comments:

Note that this proposal deals with many other issues besides the change in
default floating-point semantics. Even though the SPARC is not affected by
these changes, it (and many other architectures) are affected by the other
component of the proposal. In that sense, the proposal targets all
architectures. We could add a sentence saying that the proposed changes in
default semantics addresses concerns in the x86 and PowerPC architectures.

Regarding the issue of precise exceptions, I should have given a more
complete example. Consider the following implementation of dot-product:

        public static double ddot(double[] x, double[] y) {

                double s = 0;
                try {
                        for (int i=0; true; i++) {
                                s += x[i]*y[i];
                        }
                } catch (ArrayIndexOutOfBoundsException bounds) {
                }

                return s;
        }

It is a perfect reasonable implementation that computes the dot product
according to the shorter of the two input vectors, x and y. Now, with a
precise exception model, the choice to use "associativefp" is striclty a
numerical issue: Are the values in my vectors tolerant to the use of
associativity? With an imprecise exception model the situation is more
complicated: Will my compiler (or any compiler out there, if this code is
going out) do any optimizations that will completely break my program? The
decision to use "associativefp" is outside the numerical domain!

Indeed, there is an extra cost with the techniques (versioning,
speculation) to support optimizations under precise exceptions. These
techniques have been discussed in the context of parallelizing compilers
for a while and are starting to be deployed. We now have an opportunity to
use them in more mainstream (i.e., Java) code.

Jose E. Moreira
IBM Thomas J. Watson Research Center
Yorktown Heights, NY 10598-0218
[email-masked]

---

From: Cliff Click <[email-masked]>
Date: Wed, 9 Sep 1998 08:21:53 -0700 (Pacific Daylight Time)

Hi!  Let me butt in and state that I'm working on Sun's Hotspot system.
I am NOT a numerics person, but I implement optimizing compilers.

>decision to use "associativefp" is outside the numerical domain!

This example is quite easy to transform into:

  for( int i=0; i<min(x.len,y.len); i++ )
    s += x[i]*y[i];
  return s;

No range-checks needed; no exceptions actually thrown.

The issue of associativity comes about because I would otherwise have
to do the math in order: s = (((x[0]*y[0]) + x[1]*y[1]) + x[2]*y[2])...
On a wide-issue machine I might like to do the adds in parallel sets.
On a truely parallel machine I'd like to do the math in any arbitrary
order.  In _this_ case, exceptions are unrelated to associativity.

Cliff

---

From: [email-masked]
Date: Wed, 9 Sep 1998 11:29:35 -0400

The transformation that Cliff suggests is an example of the techniques that
I was referring to for optimizing in the presence of exceptions. It is at
the core of our "tiling" method to eliminate run-time checks. (This is an
alternative for the "versioning" method.) For a more thorough discussion I
would recommend the article "Optimizing array reference checking in Java
programs", by Midkiff, Moreira, and Snir, IBM Systems Journal, vol. 37 no.
3, 1998, and also IBM Research Report RC21166, "From Flop to Megaflops:
Java for Technical Computing",  which was presented at LCPC98.

Jose

Cliff Click <[email-masked]> on 09/09/98 11:21:53

Please respond to Cliff Click <[email-masked]>

To:   [email-masked]
cc:   Jose Moreira/Watson/IBM
Subject:  Re: Numerics Working Group report

Cliff

---

From: Dmitri Shiriaev <[email-masked]>
Date: Wed, 09 Sep 1998 10:55:12 -0700 (PDT)

I agree with Jose Moreira on  that

>it would be both more
> accurate and more diplomatic to say that the proposal aims to allow better
> execution speed on current CPUs.

Whatever reasons are behind the proposal  as a Java Grande Forum we should adhere
to more general statements

> ISSUE 3: The notation "<-" is used for assignment operation. Note that "a
> <- b" is the legal Java expression "a less than negative b". I propose
> using ":=" for assignment.

Absolutely agree. ":=" is much better.

> Still in ISSUE 3, it says that "... expression of the form a+b is merely
> syntactic sugar for sum(a,b) ..." This is a bit unclear. Which "sum"? From
> the class of "a"? From the class of "b"? Maybe it would be better to say
> "a.plus(b)", as it is unambiguous.

Yes it is unambiguous.

We should make a table of operators  we  care about...

For example 

We could say
The use of monadic and dyadic operators 
should be syntactically replaced by a methods call according to the following table

It seems reasonable to allow this scheme to be applied to every class
If a class defines the "plus" method, the + operator can be applied to the objects of the class.

written form	replacement
a+b		a.plus(b)
a-b		a.minus(b)
a*b		a.times(b)
a/b		a.divide(b)

-a		a.negate()

We should also require the possibulity to overload the 
assignment with operation (+=, etc)

a+=b		a.plusAssign(b)
a-=b		a.minusAssign(b)
a*=b		a.timesAssign(b)
a/=b		a.divideAssign(b)

a**b		a.pow(b)     

Note: I think names  plusAssign etc. are better than  the names plusEquals  etc.
proposed in the JAMA matrix class.
The word Equals has a strong semantic associated with it.

----------

Since Sather is mentioned in connection with
the overloading of boolean operators ...

In Sather  redefining < operator  implicitly redefines
the associated >, <= and >=
Similarly  redefining = operator  implicitly redefines /=

These operators are meant to be used together in a consistent manner to 
indicate the mathematical notion of complete or partial ordering.
They are not intended to be used as a convenient short-hand for other puposes.

Thus, the >, >=, =< and /= operators are not directly translated 
into their own method call (I believe it is called a routine in Sather)
They are defined in terms of <  and =

Similar (but less strict) restriction exists in ADA .

The Ada standard disallows separate overload for 
/= operator.
If = is overloaded /= is automatically implicilty overloaded
providing  a result which is a compliment to =

I believe Sather's scheme is too restrictive.
One knows that most sets are not completely ordered 
even when there is an ordering, so it is common mathematical wisdom 
that one should not automatically assume that x < y <=> not( x >= y )
just from the syntax. 
As already pointed out in the Report of the Numeric Working Group
there is a problem with  NaNs already.

Therefore the naming scheme could look like that

written form	replacement
a < b		a.lt(b)
a > b		a.gt(b)
a === b		a.equals(b)
a /= b		a.ne(b)
a <= b		a.le(b)
a >= b		a.ge(b)

I believe that new operators for deep assignment and equality comparison need to be introduced
to reduce the confusion.

What else operator symbols do we care about ?

For example % for mod ?

Dmitri