[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference abbott::java

Title:	JAVA

Moderator:	KOALA::CIOT

Created:	Mon Nov 13 1995
Last Modified:	Wed Jun 04 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	236
Total number of notes:	1251

210.0. "Debate in numeric-interest mailing list" by CAIRN::HARRIS (Kevin Harris, dtn 381-2039) Thu Feb 20 1997 14:05

From:	US2RMC::"[email protected]" "Jerome Coonen" 28-JAN-1997 01:54:16.80
To:	[email protected]
CC:	
Subj:	Note on Java Numerics

====================================================================
A Note On Java Numerics                               Jan. 25, 1997
====================================================================

Overview

Java promises to be a vastly important programming language, even
in such arenas as hard-core numerical computation.  Its current design
is seriously flawed and detrimental to the numerical health of millions
of potential users.  It neither captures the spirit of the IEEE standard
for floating point arithmetic nor reflects the years of work of the
ANSI C standards group to undo the numerical shortcomings of C's
original, PDP-11-centric design.

Java's designers claim to aspire to bit-identical results across all
Java implementations.  But besides being mathematically intractable,
that goal is commercially infeasible.  Just as Gresham observed that
good money will drive out the bad, so will faster computations -- but
for a bit or two of rounding error -- drive out the best computations.
Java's designers, if anyone, should understand the importance of benchmark
speed in computer sales.

Instead of convening a council to proclaim the one "right" answer to any
computation, Java's design team would serve the computing community better by
providing the most robust numerical environment possible across a diversity
of architectures.  Good tools will lead to good results sooner than
arbitrary decisions about right and wrong results.  Today, the Java
specification favors processors like Sun's Sparc, at the expense of
millions of users of other hardware.

In "The Java Language: A White Paper," Sun describes Java as a, "simple,
object-oriented, distributed, interpreted, robust, secure, architecture-
neutral, portable, high-performance, multithreaded, and dynamic language."

This note explores Java from a numerical standpoint, especially with
regard to its being architecture neutral, portable, and high performance.
It suggests that by using experience gained by the C standards group,
the Java design team could make Java a more truly open design.  There
is still time for Java to be numerically robust over a wide range of
processors.

Two Examples

Consider this simple piece of a larger computation:

double h, a, b, c, d;
h = (a * b) / (c * d);

Programmers familiar with the Pentium processor might expect expression
evaluation to proceed in the form

fld.d	a	; push a onto FPU stack
fmul.d	b	; a * b on stack
fld.d	c	; push c
fmul.d	d	; a * b and c * d on stack
fdivp		; a * b / c * d on stack
fstp	h	; pop and store as double

This is an excellent application of the floating point evaluation stack
in the x86 architecture.  And because stack values are stored to 11 more
significant bits and with substantially wider exponent range than 64-bit
double values, rounding error is reduced and the possibility of intermediate
overflow or underflow is eliminated.

A careful reading of "Java: The Lanuage Specification" by Gosling, Joy, and
Steele, however, reveals language suggesting that all intermediate results
should be stored to "double precision."  According to numerical aficionados
at Sun, the spec ought to say "double precision and range." This restriction
leads to this more cumbersome evaluation on some Pentium systems:

fld.d	a
fmul.d	b	; a * b on stack
fst.d	temp1	; coerce a * b to double -- EXTRA STORE
fld.d	c	; EXTRA LOAD
fmul.d	d	; c * d on stack
fst.d	temp2	; coerce c * d to double -- EXTRA STORE
fld.d	temp1	; EXTRA LOAD
fdiv.d	temp2	; temp1 / temp2 on stack
fst.d	h

The cost of converting intermediate results to double in this simple
calculation is writing two double values to memory and then
immediately reading them back -- nearly doubling the memory traffic
and increasing the instruction count by half.  This is not what designers
of the x86 FPU (nor the IEEE floating point standard) had in mind.

Here is an example on the PowerPC processor.  Numerical approximations
are often structured to have the form (base value) + (residual), where
the base value is a fast but rough approximation, in turn refined by the
smaller residual.  Such approximations lead to expressions of the form

double y, base, x, h;
y = base + (x * h);

PowerPC enthusiasts crave such expressions because they are handled so
well by a single instruction

; Assume floating registers fr1 = base, fr2 = x, and fr3 = h.
; Compute fr0 = y = base + (x * h)
fmadd	fr0,fr1,fr2,fr3	; fr0 = f1 + (f2 * f3)

The power of the "fused multiply-add" instructions lies in the evaluation
of the product (x * h) with no rounding error before this value -- to a full
106 significant bits -- is added to the value of base in fr1.

The Java spec, however, would seem to imply that the product (x * h) must
be explicitly rounded to double before it is added to base, leading to
the alternative sequence

; fr1 = base, fr2 = x, and fr3 = h.
; Compute fr0 = f1 + (f2 * f3)
fmul	f2,f2,f3	; f2 = f2 * f3, replaces x -- EXTRA ROUND TO DOUBLE
fadd	f0,f1,f2

Java has doubled the number of instructions, added a temporary value,
and forced one gratuitous rounding on the PowerPC.

Java Is Not Architecture Neutral

Although by their nature numerical issues can become painfully murky
for some, one thing is certain: these simple examples illustrate that Java
as currently specified is NOT architecture neutral.  Users of either
Pentium or PowerPC architectures will suffer a performance penalty
compared to Mips or Sparc users, whose machines perform only ordinary
operations and only on float and double values.

The notion of "architecture-neutral" has other interpretations.  Java's
designers might say that achieving the same results (or nearly so) on all
machines makes the language architecture neutral, but this paper argues below
that this goal is ultimately flawed and that the price -- lower performance,
less accurate results -- is not nearly worth the penalty to users of some
prevalent architectures.

Java Does Not Achieve High Performance

The examples above show that Pentium and PowerPC users pay twice: less
accurate results because of imposed intermediate operations and lower
performance due to time wasted on the unwanted operations.  The ANSI
committee revising the C language standard has wrestled with these issues
for years.  They have decided on an approach that is truly architecture
neutal and high performance.  Consider this example:

/* This is C9X, but could as well be Java. */
double sum, x[100], y[100];
double_t t;		/* fastest type at least as wide as double */
int i;

t = 0.0;
for (i = 0; i < 100; i++)
	t += x[i]*y[i];
sum = t;

Such loops dominate compute-intensive numerical applications.  C9X
gives explicit, portable access to system-dependent types that will
produce the best results fastest.  Pentiums make best use of their
stack.  PowerPCs make best use of fused multiply-add.  Both produce
results at least as good as -- in the case of Pentium usually rather
better than -- a vanilla float/double architecture processor.

This programming style leads to the best code across a diversity of
machines.  By contrast, the current Java spec would force every product
and sum out of the FPU stack into memory, significantly slowing the
loop and nullifying the advantages of extra range and precision.

Java Floating Point Is Not Strictly IEEE Standard -- Unnecessarily

In its first incarnations, Java is an interpreted language.  Its code
is compiled down to compact "byte codes", which can in turn be sent
across a network and executed on diverse computers.  To have some
prospect of portability of algorithms and data, Java's designers chose
to adopt part of the IEEE standard 754 for binary floating point
arithmetic.

The standard ensures bits in a 32-bit float value and in a 64-bit
double value will have the same meaning on all Java systems (modulo
byte order, that is).  It also ensures that arithmetic will be performed
as if with unbounded range and precision, with results rounded to the
appropriate representable value.

Java deviates from the letter and the spirit of IEEE arithmetic in
critical ways.  It omits any state associated with floating point arithmetic,
preventing programmers from choosing a rounding direction from any of
the four (required) IEEE options, and preventing programmers from testing
and altering (required) IEEE sticky exception flags.

The desire of Java's designers to attain identical results on all machines
is not at all in the spirit of the IEEE standard.  The standard actually
recommends -- with its careful use of the word "should" -- the implementation
of a double-extended format on float/double machines, yet Java's designers
would preclude its use.  The IEEE recommendation was based on years of
experience that showed how a little extra hardware could go a long way
computationally.  The recommended extensions of range and precision --
supported by the x86 and 68K architectures -- are the preferred, not
prohibited, mechanisms for expression evaluation.  Aside from their
obvious use to experts, they also defend less sophisticated programmers
who often transcribe numerically dubious mathematical formulas from texts.

The examples above illustrate that Java prevents effective use of extended
precision and range on processors whose users have paid for those features.
In contrast, designers of IEEE-754 were deliberately architecture-neutral,
though it might be that "architecture-open" is a better expression.
The standard allows
* float-only systems, for the low end
* extended formats with extra range and precision, for users who care to
  pay for their benefits
* different implementations of underflow, in which the differences are
  computationally and logically negligible.

It's a pity that Java is so restrictive in light of progress in the new
C9X standard, in which great care has been taken to make the most powerful
features of the IEEE binary floating point standards portable at last.

Portability != Reproducibility

Java's designers might argue that their restrictive specification for
floating point arithmetic approaches reproducibility of results across
diverse architectures.  Identical floating point results on all machines
yield the ultimate portability.  But at what cost?

Truly identical results are possible only if every library function
available to applications yields identical results, which is only
practical if all implementations are the same.  Therein lies the
flaw.  As long as competition (or past practice) motivates a variety
of architectures, computations will be best done in different ways
on different machines.  Trying to enforce specific algorithms for
important computations across all machines will ultimately fail
because users (and salespeople) want to eke all the speed possible
out of a given architecture.

For a concrete case, consider the third example presented earlier --
computing an inner product of two vectors, that is

x[0]*y[0] + x[1]*y[1] + x[2]*y[2] + . . . + x[N-1]*y[N-1]

where x and y are double arrays.  Consider the possibilities for a
function that might be found in the widely used LINPACK or LAPACK
libraries.

1. The current Java spec suggests that all intermediate operations
   should produce double results.  Sparc and Mips processors work
   this way.

2. PowerPC users might expect fused multiply-add to speed the loop.

3. Pentium users would expect intermediate operations to enjoy
   extended range and precision.

4. Followers of the work of Kulisch and Miranker would demand that
   the sum be computed with JUST ONE rounding error -- a facility
   provided by the ACRITH package in some IBM hardware and other
   software.

Option 4 is the most accurate, but its cost is high given the range
of the IEEE double format.  Options 1-3 are fastest on their
respective architectures, with 3 almost certainly likely to be the
most accurate of them.

Who will decide what's right and how much who must pay to get this
right result?

The question is even more subtle in the realm of transcendental
functions like cos() or exp(), some of which require argument
reduction, too.  Not even Prof. W. Kahan of U. C. Berkeley,
who received the ACM Turing Award for his work on the IEEE standard
and his numerical nit-pickiness, could want to sit on such a
Numerical Governing Board.

And if the issue isn't sufficiently intractable mathematically,
consider the forces of the marketplace, in which faster code,
often at the expense of some accuracy but quite often without
sacrificing key properties like monotonicity, can create its
own market.

Identical results from any but the simplest expressions are
a hopeless cause.  An attempt at such a rigid standard could
lead to a specification conformed to only by the implementation
blessed with the choice of the "right" result of any computation.

Java Can Have Robust, Portable Floating Point Computation

As specified today, Java makes numerical sense only on processors
like Sun's Sparc that support only basic arithmetic on float and
double operands; users of other processors suffer one form of
degradation or another.

Ultimately, one hopes users will strive for a correct answer,
not the same answer.  In over a decade since its adoption, IEEE-754
has driven the industry toward common data formats and higher
quality results.  Over the past seven years, work on the new
C9X standard has exposed techniques to make the features of IEEE
arithmetic available portably.  It's time for the Java community
to take note of that progress, to open the standard to the real
diversity of existing, standard floating point architectures, and
achieve a truly high performance, portable design that is
architecture neutral in a numerically sensible way.

Jerome Coonen
C-Labs
4035 Orme St.
Palo Alto, CA  94306
[email protected]

Background

Jerome T. Coonen received his Ph.D. in mathematics from U. C. Berkeley
for work with W. Kahan on the design and early implementation of the
IEEE binary floating point standard.  He worked at Apple Computer
for a decade and nowadays consults on floating point issues with
Exponential Technology, Metrowerks, Apple, Microsoft, and SunSoft.

% ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ======
% Received: from mail13.digital.com by us2rmc.zko.dec.com (5.65/rmc-22feb94) id AA11146; Tue, 28 Jan 97 01:37:29 -0500
% Received: from netra.validgh.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id BAA07876; Tue, 28 Jan 1997 01:31:41 -0500 (EST)
% Received: from validgh.com by netra.validgh.com (SMI-8.6/SMI-SVR4) id VAA27509; Mon, 27 Jan 1997 21:54:20 -0800
% Received: by validgh.com (4.1/SMI-4.1) id AA27362; Mon, 27 Jan 97 21:40:56 PST
% Received: from netra.validgh.com (netra32) by validgh.com (4.1/SMI-4.1) id AA26824; Mon, 27 Jan 97 17:01:28 PST
% Received: from terminator.be.com by netra.validgh.com (SMI-8.6/SMI-SVR4) id QAA25241; Mon, 27 Jan 1997 16:59:18 -0800
% Received: from be.be.com ([email protected] [207.113.215.1]) by terminator.be.com (8.6.12/8.6.12) with SMTP id RAA05143 for <[email protected]>; Mon, 27 Jan 1997 17:02:52 -0800
% From: Jerome Coonen <[email protected]>
% X-Mailer: SCO System V Mail (version 3.2)
% To: [email protected]
% Subject: Note on Java Numerics
% Date: Mon, 27 Jan 97 17:02:46 PST
% Message-Id:  <[email protected]>
% Sender: [email protected]
% Precedence: bulk
% Reply-To: Jerome Coonen <[email protected]>

T.R	Title	User	Personal Name	Date	Lines
210.1	Bill Walster brings up Intervals	CAIRN::HARRIS	Kevin Harris, dtn 381-2039	`Thu Feb 20 1997 14:06`	51
	From: US2RMC::"[email protected]" "MAIL-11 Daemon" 28-JAN-1997 12:32:22.85 To: [email protected], [email protected] CC: Subj: Re: Note on Java Numerics Jerome, I enjoyed your note on Java Numerics, and agree with the arguments and the conclusions you make in it. Why isn't interval arithmetic the ideal framework within which to deal with all the issues you raise concerning numeric accuracy on alternate platforms? In the proposed Fortran 2000 standard, there is one and only one requirement regarding interval accuracy: "containment". Interval results MUST contain the correct answer. How a processor achieves this or how "sharp" (or narrow) the containing interval, is processor dependent, as you aptly point out, it must be. In case you have not seen it, I refer you to the interval home page and the draft standard contained therein. Also, note the existing proposal for support of intervals in Java. http://cs.utep.edu/interval-comp/main.html http://interval.usl.edu/F90/f96-pro.asc http://cs.utep.edu/interval-comp/java.html Regards, Bill Walster, Manager, Fortran Compiler Technology and Russian Projects SunSoft % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail13.digital.com by us2rmc.zko.dec.com (5.65/rmc-22feb94) id AA16305; Tue, 28 Jan 97 12:20:13 -0500 % Received: from netra.validgh.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id MAA02209; Tue, 28 Jan 1997 12:10:11 -0500 (EST) % Received: from validgh.com by netra.validgh.com (SMI-8.6/SMI-SVR4) id IAA02142; Tue, 28 Jan 1997 08:39:21 -0800 % Received: by validgh.com (4.1/SMI-4.1) id AA29881; Tue, 28 Jan 97 08:39:32 PST % Received: from netra.validgh.com (netra32) by validgh.com (4.1/SMI-4.1) id AA29875; Tue, 28 Jan 97 08:39:27 PST % Received: from venus.Sun.COM by netra.validgh.com (SMI-8.6/SMI-SVR4) id IAA02117; Tue, 28 Jan 1997 08:37:37 -0800 % From: [email protected] % Received: from Eng.Sun.COM ([129.146.1.25]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA23492; Tue, 28 Jan 1997 08:39:34 -0800 % Received: from gww.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA28045; Tue, 28 Jan 1997 08:39:33 -0800 % Received: by gww.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA14056; Tue, 28 Jan 1997 08:41:09 -0800 % Date: Tue, 28 Jan 1997 08:41:09 -0800 % Message-Id: <[email protected]> % To: [email protected], [email protected] % Subject: Re: Note on Java Numerics % X-Sun-Charset: US-ASCII % Sender: [email protected] % Precedence: bulk % Reply-To: [email protected]
210.2	Jim Demmel's note	CAIRN::HARRIS	Kevin Harris, dtn 381-2039	`Thu Feb 20 1997 14:07`	37
	From: US2RMC::"[email protected]" "James W. Demmel" 28-JAN-1997 14:13:22.72 To: [email protected], [email protected] CC: Subj: Comment on "Java Numerics" I read Jerome Coonen's recent contribution on "Java Numerics" with great interest, because of related issues arising in the ScaLAPACK numerical library project, which aspires to produce portable parallel library code, and so must (conceivably) contend with a user who connects a Cray C90, DEC Alpha, PowerPC and Pentium across a network to cooperate in a computation. There are some such "heterogeneous computations" that we understand how to do correctly, and others that we do not. Some problems seem beyond our control to fix in any cost effective way (such as an Ultrasparc sending a denormalized number to a DEC Alpha, which then faults, and may deadlock the computation). For a technical report discussing these and other issues, see LAPACK Working Note 112, http://www.netlib.org/lapack/lawns. Jim Demmel UC Berkeley % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail13.digital.com by us2rmc.zko.dec.com (5.65/rmc-22feb94) id AA24642; Tue, 28 Jan 97 14:02:50 -0500 % Received: from netra.validgh.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id NAA12179; Tue, 28 Jan 1997 13:54:27 -0500 (EST) % Received: from validgh.com by netra.validgh.com (SMI-8.6/SMI-SVR4) id KAA03040; Tue, 28 Jan 1997 10:18:48 -0800 % Received: by validgh.com (4.1/SMI-4.1) id AA00301; Tue, 28 Jan 97 10:13:05 PST % Received: from netra.validgh.com (netra32) by validgh.com (4.1/SMI-4.1) id AA00295; Tue, 28 Jan 97 10:13:01 PST % Received: from bmw.CS.Berkeley.EDU by netra.validgh.com (SMI-8.6/SMI-SVR4) id KAA02950; Tue, 28 Jan 1997 10:10:46 -0800 % Received: from bmw.CS.Berkeley.EDU (localhost.Berkeley.EDU [127.0.0.1]) by bmw.CS.Berkeley.EDU (8.8.3/8.8.2) with ESMTP id KAA15952; Tue, 28 Jan 1997 10:12:24 -0800 (PST) % From: "James W. Demmel" <[email protected]> % Message-Id: <[email protected]> % To: [email protected], [email protected] % Subject: Comment on "Java Numerics" % Date: Tue, 28 Jan 1997 10:12:11 -0800 % Sender: [email protected] % Precedence: bulk % Reply-To: "James W. Demmel" <[email protected]>
210.3	Conference on Java for Science and Engineering	CAIRN::HARRIS	Kevin Harris, dtn 381-2039	`Thu Feb 20 1997 14:08`	130
	From: US2RMC::"[email protected]" "Bob Knighten" 28-JAN-1997 20:26:59.78 To: [email protected] CC: Subj: Java for Science and Engineering Computation Shortly after Jerome Coonen's interesting note on Java numerics arrived the following also arrived, noteworthy confirmation that Java is likely to be important in hard-core numerical computation. Robert L. Knighten \| [email protected] Server Architecture Lab \| Intel Corporation \| 5200 N.E. Elam Young Parkway, CO3-202 \| (503) 677-4315 Hillsboro, OR 97124-6497 \| (503) 677-6700 [FAX] ------- start of forwarded message (RFC 934 encapsulation) ------- From: Rob Schreiber <[email protected]> Sender: [email protected] To: [email protected] Subject: hpff-core: Scientific Java Wkshop Date: Tue, 28 Jan 1997 14:27:10 -0800 (PST) - --------------------------------------------------------------------------- [email protected] is a mailing list for announcements related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. - --------------------------------------------------------------------------- CALL FOR PAPERS ACM 1997 Workshop on Java for Science and Engineering Computation Las Vegas, Nevada, June 21, 1997 (In Conjunction with ACM SIGPLAN PPoPP) http://www.cs.rochester.edu/u/wei/javaworkshop.html The workshop on Java for Science and Engineering Computation is aimed at discussing all issues of using Java in simulations where today we use Fortran and C++. We include both classic Grand Challenge applications and libraries as well as distributed simulation as in Forces Modeling seen in SIMNET/DSI. We include both parallel and sequential applications but will only consider Java for simulation as opposed to major commercial use of Java in Web Servers. We include both optimized Java native compilers for numerical kernels and interpreted Java "wrappers" for visualization. We also include research issues on Java language, compilers, interpreters and runtime systems. The workshop is aimed at getting a broad perspective of community interests and views, as well as more technical discussions. A similar Java workshop was held very successfully in Syracuse in 1996 (http://www.npac.syr.edu/projects/javaforcse). A mailing list has been created for people interested in Java for Science and Engineering Computation. To join, send a message with "subscribe java-for-cse" to [email protected]. Original submissions are invited in all areas including (but not restricted to): * Java in Simulation * Web based Computation Environments in Java * Optimized Compilation of Java * Just-In-Time vs. Offline Compilation * JVM as Compiler Intermediate Representation * Java Runtime Systems * Java I/O * Data Parallel Java * Mapping C, Fortran, and C++ to Java * Java as User Interface to Simulations * Java as Wrapper Technology for Existing Scientific Codes * Use of Java Applets to Illustrate Science for Education Papers should report new research and should not exceed 5000 words (approximately 10 typeset on 16-point spacing, or 15 typewritten double-spaced pages). Short papers (less than 3000 words) that describe existing implementations or work-in-progress, or outline new problems or important issues are also welcome. All accepted papers will be presented at the workshop and published in a special issue of the journal "Concurrency: Practice and Experience". SUBMISSION Electronic submission is preferred. Please e-mail a postscript copy of your submission or send three hard copies to one of the co-chairs. Submissions must be received by 5pm (Eastern Time) on April 10, 1997. Authors will be notified by April 30. Final camera-ready versions are due by May 15. PROGRAM CO-CHAIRS Geoffrey C Fox Wei Li NPAC Department of Computer Science 111 College Place 711 Computer Studies Building Syracuse University University of Rochester Syracuse, NY 13244-4100 Rochester, NY 14627-0226 Phone: (315) 443-2163 Phone: (716) 275-2957 FAX: (315) 443-1973 FAX: (716) 461-2018 [email protected] [email protected] - --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to [email protected]. Leave the subject line blank, and in the body put the line (un)subscribe <email-address> - --------------------------------------------------------------------------- ------- end ------- % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail13.digital.com by us2rmc.zko.dec.com (5.65/rmc-22feb94) id AA19375; Tue, 28 Jan 97 20:13:51 -0500 % Received: from netra.validgh.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id UAA10154; Tue, 28 Jan 1997 20:05:39 -0500 (EST) % Received: from validgh.com by netra.validgh.com (SMI-8.6/SMI-SVR4) id QAA06023; Tue, 28 Jan 1997 16:34:39 -0800 % Received: by validgh.com (4.1/SMI-4.1) id AA01205; Tue, 28 Jan 97 16:34:53 PST % Received: from netra.validgh.com (netra32) by validgh.com (4.1/SMI-4.1) id AA01199; Tue, 28 Jan 97 16:34:45 PST % Received: from comail.co.intel.com by netra.validgh.com (SMI-8.6/SMI-SVR4) id QAA05986; Tue, 28 Jan 1997 16:32:54 -0800 % Received: from ssdintel.co.intel.com (ssdintel.co.intel.com [137.46.3.5]) by comail.co.intel.com (8.8.3/8.7.3) with SMTP id QAA10978 for <[email protected]>; Tue, 28 Jan 1997 16:43:17 -0800 (PST) % Received: from knight.co.intel.com by ssdintel.co.intel.com (4.1/SMI-4.1) id AA06633; Tue, 28 Jan 97 16:34:49 PST % Received: (from knighten@localhost) by knight.co.intel.com (8.8.5/8.8.4) id QAA02663; Tue, 28 Jan 1997 16:34:44 -0800 (PST) % Date: Tue, 28 Jan 1997 16:34:44 -0800 (PST) % Message-Id: <[email protected]> % From: Bob Knighten <[email protected]> % To: [email protected] % Subject: Java for Science and Engineering Computation % Sender: [email protected] % Precedence: bulk % Reply-To: Bob Knighten <[email protected]>
210.4	Some comments from the Author	CAIRN::HARRIS	Kevin Harris, dtn 381-2039	`Thu Feb 20 1997 14:09`	77
	From: US2RMC::"[email protected]" "Arthur van Hoff" 30-JAN-1997 19:23:34.48 To: [email protected] CC: [email protected] Subj: Re: Java numerics issue Hi Jerome, I am not a math expert but I was present when some of the decisions about Java's math support were made. We spend a fair amount of time=20 discussing these issues before we decided on the current specification. Guy Steele acted as our resident Math expert at the time. Anyway, it was decided that for the sake of portability all platforms would have to implement the exact same semantics for all language features including math operations. We considered portability to be more important than performance in some cases. Unfortunately this means that on some platforms this will make it impossible to generate=20 optimal native code for math operations.=20 With this strict requirement for portability it should be easy to write math algorithms that produce the same results on all=20 platforms. This would be very hard to do in C or C++ which were designed for performance not portability. Anyway, as a resuls it is=20 unlikely that Java will be the best choice for implementing very performance critical math routines such as sqrt(). It is likely that=20 these will remain hand-coded native routines for a while. Another issue to consider is the support for interpreted and compiled code in the same environment. It would be wrong if JIT compiled code woul= d produce different or more accurate results than interpreted code which rounds intermediate results differently. This could cause very unpredictable behaviour within one virtual machine. Forcing the interpret= er to mimick the hardware's capabilities would be very expensive and very sl= ow. A related problem that was never resolved, is the standarization of the Math library which is part of the Java standard. I think we decided that Sun would eventually provide a reference implementation for these in Java. I don't think there is a satisfactory answer for that one.=20 Was it the right decision to force the JIT compiled Java code to conform to a strict standard? I think so, but then again, I am not a math expert.= .. =09 Have fun, Arthur van Hoff Mar=EDmba Inc., 445 Sherman Avenue, Palo Alto CA 94306 415-328 JAVA (main), 415-328 5283 (direct), 415-328 5295 (fax) http://www.marimba.com/, mailto:[email protected] % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail13.digital.com by us2rmc.zko.dec.com (5.65/rmc-22feb94) id AA03594; Thu, 30 Jan 97 19:07:40 -0500 % Received: from netra.validgh.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id TAA14874; Thu, 30 Jan 1997 19:02:03 -0500 (EST) % Received: from validgh.com by netra.validgh.com (SMI-8.6/SMI-SVR4) id PAA26273; Thu, 30 Jan 1997 15:28:39 -0800 % Received: by validgh.com (4.1/SMI-4.1) id AA08203; Thu, 30 Jan 97 15:27:31 PST % Received: from netra.validgh.com (netra32) by validgh.com (4.1/SMI-4.1) id AA08196; Thu, 30 Jan 97 15:27:26 PST % Received: from marimba.com by netra.validgh.com (SMI-8.6/SMI-SVR4) id PAA26235; Thu, 30 Jan 1997 15:25:24 -0800 % Received: from trix.marimba.com by marimba.com (SMI-8.6/SMI-SVR4) id PAA22297; Thu, 30 Jan 1997 15:27:26 -0800 % Message-Id: <[email protected]> % X-Sender: [email protected] % X-Mailer: Windows Eudora Pro Version 3.0 (32) % Date: Thu, 30 Jan 1997 15:28:25 -0800 % To: [email protected] % From: Arthur van Hoff <[email protected]> % Subject: Re: Java numerics issue % Cc: [email protected] % Mime-Version: 1.0 % Content-Type: text/plain; charset="iso-8859-1" % Sender: [email protected] % Precedence: bulk % Reply-To: Arthur van Hoff <[email protected]> % Content-Transfer-Encoding: quoted-printable
210.5	rationale for no COMPLEX?	CAIRN::HARRIS	Kevin Harris, dtn 381-2039	`Thu Feb 20 1997 14:09`	52
	From: US2RMC::"[email protected]" "Dean Schulze" 30-JAN-1997 19:53:53.97 To: Arthur van Hoff <[email protected]> CC: [email protected], [email protected] Subj: Re: Java numerics issue Arthur, I've been curious to know why complex numbers were left out of Java. Since there is no operator overloading the syntax for working with, for example, objects of type ZDouble will be pretty ugly. Is there any chance that complex numbers could be added to the language in the future or have they been frozen out? Dean Schulze ====================================================================== "You plot the growth of the NEA [National Education Association] and the dropping of SAT scores, and they're inversely proportional. The problems are unions in the schools. The problem is bureaucracy. I'm one of these people who believes the best thing we could ever do is go to the full voucher system." Steve Jobs Wired Magazine, Feb. 96 http://www.hotwired.com/wired/4.02/features/jobs.html ===================================================================== % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail13.digital.com by us2rmc.zko.dec.com (5.65/rmc-22feb94) id AA04953; Thu, 30 Jan 97 19:37:04 -0500 % Received: from netra.validgh.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id TAA21032; Thu, 30 Jan 1997 19:33:51 -0500 (EST) % Received: from validgh.com by netra.validgh.com (SMI-8.6/SMI-SVR4) id QAA26493; Thu, 30 Jan 1997 16:01:56 -0800 % Received: by validgh.com (4.1/SMI-4.1) id AA08240; Thu, 30 Jan 97 16:02:27 PST % Received: from netra.validgh.com (netra32) by validgh.com (4.1/SMI-4.1) id AA08234; Thu, 30 Jan 97 16:02:23 PST % Received: from cassini.LPL.Arizona.EDU by netra.validgh.com (SMI-8.6/SMI-SVR4) id QAA26483; Thu, 30 Jan 1997 16:00:29 -0800 % Received: from LOCALHOST by cassini.LPL.Arizona.EDU with SMTP (1.38.193.4/16.2) id AA02800; Thu, 30 Jan 1997 17:01:08 -0700 % Message-Id: <[email protected]> % Date: Thu, 30 Jan 1997 17:01:07 -0700 % From: Dean Schulze <[email protected]> % Organization: Lunar and Planetary Laboratory % X-Mailer: Mozilla 3.0Gold (X11; I; HP-UX A.09.05 9000/735) % Mime-Version: 1.0 % To: Arthur van Hoff <[email protected]> % Cc: [email protected], [email protected] % Subject: Re: Java numerics issue % References: <[email protected]> % Content-Type: text/plain; charset=us-ascii % Content-Transfer-Encoding: 7bit % Sender: [email protected] % Precedence: bulk % Reply-To: Dean Schulze <[email protected]>
210.6	COMPLEX answer from van Hoff	CAIRN::HARRIS	Kevin Harris, dtn 381-2039	`Thu Feb 20 1997 14:10`	51
	From: US2RMC::"[email protected]" "Arthur van Hoff" 30-JAN-1997 20:17:50.69 To: Dean Schulze <[email protected]> CC: [email protected] Subj: Re: Java numerics issue Hi Dean, > I've been curious to know why complex numbers were left out >of Java. Since there is no operator overloading the syntax for >working with, for example, objects of type ZDouble will be pretty >ugly. We spend most of our time figuring out ways to keep Java simple. One of the goals was to avoid unnecessary duplicate functionality. It is unfortunately not possible to design a language that is all things to all people. We had to made some sacrifices for simplicicty, and operator overloading was one of them. Personally I think it would do more harm than good, so we left it out. Unfortunately that leaves you with an ugly notation for complex numbers. Sorry about that... =09 Have fun, Arthur van Hoff Mar=EDmba Inc., 445 Sherman Avenue, Palo Alto CA 94306 415-328 JAVA (main), 415-328 5283 (direct), 415-328 5295 (fax) http://www.marimba.com/, mailto:[email protected] % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail13.digital.com by us2rmc.zko.dec.com (5.65/rmc-22feb94) id AA05919; Thu, 30 Jan 97 20:01:45 -0500 % Received: from netra.validgh.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id TAA21740; Thu, 30 Jan 1997 19:55:07 -0500 (EST) % Received: from validgh.com by netra.validgh.com (SMI-8.6/SMI-SVR4) id QAA26642; Thu, 30 Jan 1997 16:23:02 -0800 % Received: by validgh.com (4.1/SMI-4.1) id AA08264; Thu, 30 Jan 97 16:24:29 PST % Received: from netra.validgh.com (netra32) by validgh.com (4.1/SMI-4.1) id AA08258; Thu, 30 Jan 97 16:24:24 PST % Received: from marimba.com by netra.validgh.com (SMI-8.6/SMI-SVR4) id QAA26632; Thu, 30 Jan 1997 16:22:35 -0800 % Received: from trix.marimba.com by marimba.com (SMI-8.6/SMI-SVR4) id QAA23550; Thu, 30 Jan 1997 16:26:46 -0800 % Message-Id: <[email protected]> % X-Sender: [email protected] % X-Mailer: Windows Eudora Pro Version 3.0 (32) % Date: Thu, 30 Jan 1997 16:27:45 -0800 % To: Dean Schulze <[email protected]> % From: Arthur van Hoff <[email protected]> % Subject: Re: Java numerics issue % Cc: [email protected] % Mime-Version: 1.0 % Content-Type: text/plain; charset="iso-8859-1" % Sender: [email protected] % Precedence: bulk % Reply-To: Arthur van Hoff <[email protected]> % Content-Transfer-Encoding: quoted-printable
210.7	Other standards, FYI	CAIRN::HARRIS	Kevin Harris, dtn 381-2039	`Thu Feb 20 1997 14:11`	47
	From: US2RMC::"[email protected]" "Fred J. Tydeman" 31-JAN-1997 06:10:02.88 To: "numeric interest" <[email protected]> CC: Subj: Re: Java numerics issue >A related problem that was never resolved, is the standarization of the >Math library which is part of the Java standard. I think we decided that >Sun would eventually provide a reference implementation for these in Java. >I don't think there is a satisfactory answer for that one. FPCE (Floating-Point C Extensions) of C9X (the revision of C currently in progress) has defined behaviour of the math library functions for IEEE-754 values and exception flags. LIA-2 (Language Independent Arithmetic Part 2: Elementary numerical functions) has accuracy requirements on the math library functions as well as behaviour for exception cases. --- Fred J. Tydeman +49 (7031) 288-964 Tydeman Consulting Meisenweg 20 [email protected] Programming, testing, C/C++ training D-71032 Boeblingen Voting member of X3J11 (ANSI "C") Germany Sample FPCE tests: ftp://ftp.netcom.com/pub/ty/tydeman % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail13.digital.com by us2rmc.zko.dec.com (5.65/rmc-22feb94) id AA00197; Fri, 31 Jan 97 05:58:21 -0500 % Received: from netra.validgh.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id FAA11640; Fri, 31 Jan 1997 05:52:03 -0500 (EST) % Received: from validgh.com by netra.validgh.com (SMI-8.6/SMI-SVR4) id CAA00672; Fri, 31 Jan 1997 02:22:04 -0800 % Received: by validgh.com (4.1/SMI-4.1) id AA09336; Fri, 31 Jan 97 02:22:42 PST % Received: from netra.validgh.com (netra32) by validgh.com (4.1/SMI-4.1) id AA09330; Fri, 31 Jan 97 02:22:38 PST % Received: from hq.seicom.de by netra.validgh.com (SMI-8.6/SMI-SVR4) id CAA00662; Fri, 31 Jan 1997 02:20:41 -0800 % Received: from tybor.bb.schwaben.de by hq.seicom.de with smtp (Smail3.1.28.1) id m0vqFQg-000KZWC; Fri, 31 Jan 97 10:38 MET % Message-Id: <[email protected]> % From: "Fred J. Tydeman" <[email protected]> % To: "numeric interest" <[email protected]> % Date: Fri, 31 Jan 97 09:52:05 +0100 % Priority: Normal % X-Mailer: Fred J. Tydeman's Registered PMMail 1.53 For OS/2 % Mime-Version: 1.0 % Content-Type: text/plain; charset="iso-8859-1" % Content-Transfer-Encoding: 7bit % Subject: Re: Java numerics issue % Sender: [email protected] % Precedence: bulk % Reply-To: "Fred J. Tydeman" <[email protected]>
210.8	confused person	CAIRN::HARRIS	Kevin Harris, dtn 381-2039	`Thu Feb 20 1997 14:11`	137
	From: US2RMC::"[email protected]" "R. Baker Kearfott" 31-JAN-1997 10:59:35.53 To: Jerome Coonen <[email protected]>, [email protected] CC: Subj: Re: Note on Java Numerics At 05:02 PM 1/27/97 PST, Jerome Coonen wrote: > >==================================================================== >A Note On Java Numerics Jan. 25, 1997 >==================================================================== > >Overview > . . . >arbitrary decisions about right and wrong results. Today, the Java >specification favors processors like Sun's Sparc, at the expense of >millions of users of other hardware. I am confused. I thought that Sun implemented IEEE 754, that includes the extended register for argument reduction, etc. Furthermore, other aspects of Sun products, such as promotion of single precision constants to double in f77, seem to be counter the rigid stand on coercion into a floating point storage unit as you describe in the proposed Java standard. Can someone enlighten me? Is it something I don't understand about Sparc architecture? >Two Examples > >Consider this simple piece of a larger computation: > >double h, a, b, c, d; >h = (a * b) / (c * d); > >Programmers familiar with the Pentium processor might expect expression >evaluation to proceed in the form > >fld.d a ; push a onto FPU stack >fmul.d b ; a * b on stack >fld.d c ; push c >fmul.d d ; a * b and c * d on stack >fdivp ; a * b / c * d on stack >fstp h ; pop and store as double > >This is an excellent application of the floating point evaluation stack >in the x86 architecture. And because stack values are stored to 11 more >significant bits and with substantially wider exponent range than 64-bit >double values, rounding error is reduced and the possibility of intermediate >overflow or underflow is eliminated. > >A careful reading of "Java: The Lanuage Specification" by Gosling, Joy, and >Steele, however, reveals language suggesting that all intermediate results >should be stored to "double precision." According to numerical aficionados >at Sun, the spec ought to say "double precision and range." This restriction >leads to this more cumbersome evaluation on some Pentium systems: > >fld.d a >fmul.d b ; a * b on stack >fst.d temp1 ; coerce a * b to double -- EXTRA STORE >fld.d c ; EXTRA LOAD >fmul.d d ; c * d on stack >fst.d temp2 ; coerce c * d to double -- EXTRA STORE >fld.d temp1 ; EXTRA LOAD >fdiv.d temp2 ; temp1 / temp2 on stack >fst.d h > >The cost of converting intermediate results to double in this simple >calculation is writing two double values to memory and then >immediately reading them back -- nearly doubling the memory traffic >and increasing the instruction count by half. This is not what designers >of the x86 FPU (nor the IEEE floating point standard) had in mind. > >Here is an example on the PowerPC processor. Numerical approximations >are often structured to have the form (base value) + (residual), where >the base value is a fast but rough approximation, in turn refined by the >smaller residual. Such approximations lead to expressions of the form > >double y, base, x, h; >y = base + (x * h); > >PowerPC enthusiasts crave such expressions because they are handled so >well by a single instruction > >; Assume floating registers fr1 = base, fr2 = x, and fr3 = h. >; Compute fr0 = y = base + (x * h) >fmadd fr0,fr1,fr2,fr3 ; fr0 = f1 + (f2 * f3) > >The power of the "fused multiply-add" instructions lies in the evaluation >of the product (x * h) with no rounding error before this value -- to a full >106 significant bits -- is added to the value of base in fr1. > >The Java spec, however, would seem to imply that the product (x * h) must >be explicitly rounded to double before it is added to base, leading to >the alternative sequence > >; fr1 = base, fr2 = x, and fr3 = h. >; Compute fr0 = f1 + (f2 * f3) >fmul f2,f2,f3 ; f2 = f2 * f3, replaces x -- EXTRA ROUND TO DOUBLE >fadd f0,f1,f2 > >Java has doubled the number of instructions, added a temporary value, >and forced one gratuitous rounding on the PowerPC. > --------------------------------------------------------------- R. Baker Kearfott, [email protected] (318) 482-5346 (fax) (318) 482-5270 (work) (318) 981-9744 (home) URL: http://interval.usl.edu/kearfott.html Department of Mathematics, University of Southwestern Louisiana USL Box 4-1010, Lafayette, LA 70504-1010, USA --------------------------------------------------------------- % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail13.digital.com by us2rmc.zko.dec.com (5.65/rmc-22feb94) id AA18494; Fri, 31 Jan 97 10:45:56 -0500 % Received: from netra.validgh.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id KAA01183; Fri, 31 Jan 1997 10:33:25 -0500 (EST) % Received: from validgh.com by netra.validgh.com (SMI-8.6/SMI-SVR4) id HAA02624; Fri, 31 Jan 1997 07:02:27 -0800 % Received: by validgh.com (4.1/SMI-4.1) id AA09938; Fri, 31 Jan 97 07:02:42 PST % Received: from netra.validgh.com (netra32) by validgh.com (4.1/SMI-4.1) id AA09932; Fri, 31 Jan 97 07:02:37 PST % Received: from bp.ucs.usl.edu by netra.validgh.com (SMI-8.6/SMI-SVR4) id HAA02614; Fri, 31 Jan 1997 07:00:46 -0800 % Received: from rbk5287.usl.edu (rbk5287.usl.edu [130.70.64.43]) by bp.ucs.usl.edu with SMTP id AA22740 (5.65c/IDA-1.4.4 for <[email protected]>); Fri, 31 Jan 1997 09:02:27 -0600 % Message-Id: <[email protected]> % X-Sender: [email protected] % X-Mailer: Windows Eudora Pro Version 2.2 (32) % Mime-Version: 1.0 % Content-Type: text/plain; charset="us-ascii" % Date: Fri, 31 Jan 1997 08:58:28 -0600 % To: Jerome Coonen <[email protected]>, [email protected] % From: "R. Baker Kearfott" <[email protected]> % Subject: Re: Note on Java Numerics % Sender: [email protected] % Precedence: bulk % Reply-To: "R. Baker Kearfott" <[email protected]>
210.9	Gosling gives some background	CAIRN::HARRIS	Kevin Harris, dtn 381-2039	`Thu Feb 20 1997 14:12`	385
	From: US2RMC::"[email protected]" "James Gosling" 1-FEB-1997 00:08:35.73 To: Dean Schulze <[email protected]>, [email protected], Arthur van Hoff <[email protected]> CC: Subj: Re: Java numerics issue ---LA_F1918945549R-1A-854732983=:16982NCE.Roam Content-Type: TEXT/PLAIN; CHARSET=US-ASCII As the guy who wrote the original Java compiler and runtime, I made all the early decisions, so I suppose I ought to jump into this debate. For the issue that Coonen raised, about exact behaviour and extended precision, it's really an issue of point-of-view and priority. The point of view in his paper was essentially: Make this program as fast and accurate as possible on the box in front of me. The point of view that drove the design of Java was: Maximize correct program behaviour on a broad spectrum of machines where the application writer doesn't know what those machines are. Fast and accurate were important too, but not as important as knowing that if my program works on the machine in front of me, it works on all others. We aren't as perfect in this as I would like to be, but allowing non-deterministic use of things like fused-multiply-add would make it worse. Exploiting FMA via an explicit method call (which could be optimized away) would be perfectly OK, however. The suggestion was made that the Java FP semantics were driven by some need to promote SPARC chips. This is nuts. Java started out being designed for embedded systems and consumer electronics. The chips I was concerned with at the time were ARM, M32, SH-n, 68K and several others. SPARC was not on the list because it's way too expensive. Outside of the computer mainstream there are a lot of CPU architectures in use -- it's this mind boggling list that made portability concerns so important. > > I've been curious to know why complex numbers were left out > >of Java. Since there is no operator overloading the syntax for > >working with, for example, objects of type ZDouble will be pretty > >ugly. As Arthur said, simplicity was a big driver in leaving complex numbers out. Another, about as important, was that we just didn't need them. Java's design target wasn't people doing serious numerical work. These reasons aside, there are other problems with doing complex numbers. There are other data types that, in other fields, are at least as important as complex numbers. One of my favorites is 3D graphics where points and transformation matricies are what matter. Doing something special in the language for just complex numbers would be wrong: it needs to be generally extensible. This is what classes are for, and how complex numbers are done in languages like C++. Performance, however, often suffers. Guy Steele has a proposal for something he calls "tuples" that are a simpler and faster alternative to classes that work for small objects. Operator overloading got left out, as Arthur said, for simplicity. It's also a feature that is often abused. About the only reasonable use I've seen for it is things like complex numbers. There are a couple of other reasons that matter to me personally: there's only a small number of operators available for overloading (what do you do about dot and cross product? Which gets to use '*'?); and even when you use them, math is still ugly and incomprehensible. I think the real answer to this is in tools. I've attached a screen shot from an editor I've been working on occasionally that allows you to define the visual representation of program fragments in a really general way: sqrt(pow(x,2)+pow(y,2)) looks right! ---LA_F1918945549R-1A-854732983=:16982NCE.Roam Content-Type: IMAGE/X-sun-tiff-file; name="jed.tif" Content-Transfer-Encoding: BASE64 Content-Description: tiff-file SUkqAAgyAAAIAAgACADIqzkAoIYBAMirOQCghgEAgC/gQAgkFg0HhEJhULhk Nh0PiERiUTikVi0XjEZjUbjkdj0fkEhkUjkklk0nlEaIJBIUCX5AmEpmUzmk 1m03nE5nU7nk9n0/oERQFDQNFl0wIDApVBplNp1PqFRqVTqlVq0gpTAoqBo8 wrNXsFhsVjslls1ntEzrNbrtJpcEYErtNzul1u13vF5vURIEDuFKtkCpFfuF yveHxGJxWLxmNjt9X8FtdGwVet4AuJBkCBhp/x2f0Gh0VVQD/f80AOp02nme pAOeg2l1ky12wguQyWAykvyzAyWGjGcjG20fF43H5Eh2WEkmTQOr5kj53EAH Ly/S3SB6m4v9a3eDy+ZgvC6kL4UI1gB9EE9UI8vJ+Hx+Xz62+kvO6GXleajM u3LvO0g76pM6aDu4zDsra5jxII8kGoI2DzoU2b2PWgz2wgiDZIQQDUqhDaFQ 7DD5xJEr4QG+7svy+wAP2jT/O6rbqRQg0XIJGCExsAEcQKg0DudBTwuAhEJI fCgARGgkjxG96GNlESrSfDyCSlJMTSvLDFxo7EARWgr9xwiMwL9BEARm0zoo PHUcTXMj/xlA0ySAyq3RZBjqyoiEivSh0+ILJsONNKDSUFKbY0LK0s0VRa7S 2kT8TQ/SVzCiExsjGKizOf80xzIaD0og0etvOUEzpBbgEBPM8VXVMLo/QEBU RQMjuq1MQVqAMq1nDlDIdW9eVy0yCxFXUqWFAVbWPXEq2K6tlUHQ7Z2JZ9kn /aFGWw5NHJDSFN0kINQIdS030zWNvRZcTgXCg9RIJH7soCCAL+BECCMCDACE MAgkGEQ2HICHRGEAGJQ5/xOGv+LgGKRI/xWKoCNICOQ2RP+SR0ASeUyaRxyW SWETGVTSQSGXzWcy6LzOZSudzOg0CUTCczahUWVTyU0iiSafzepVOqVWrVes VmtVuuV2vV+wWGxWOTwZgWOb2ZA2uNP+zQ2FkGBL+tXG5w21WuPw+NW+p3Gb 3eQXlA3uGkCBXiDWtA3OCEC/ACFQyEIEAP+P0uQZaJT2GyqNQ6o4aQU6nUyf zTVUPUZqpaah7ClRLZU2j6yk7bPVDXae0b/gcHhcPicXjcet2WD8XCW3I3bE 1noXSE4u9RHlWeQYCEYIAdwAd7FMDGaQAYjqZLrY2BwXl5KFw3LZgAAH55n5 xHNbv6xndtG7Dbtm3LUtwp6fJ1AaiJaqzfQWo0FNbCUAv4h8CqU1cFQzBjkQ 7D0PxBEMRRGrLsok8CqPEiLmr697prqhbvMI80TIi8EVIdG7ovU8jroc9Dxs Yxz3O0+DKIq/KpP2jCQNDAC+M9DieKpDkHJPKiowpLEEykpLaSzKDdS7A6Vw vL8uTBEk1TXNk2zdN6ksiuD4qtHEgrZFsixQrkZPXGk8uNGaIyA6sevYX7Hs iyb5IQ8ybs4sdHThSdKUrS1L0xTNNRLQDmPW5z3uHQUoTk4VRsPHbCSGyD30 WytG1eAC90gqdJIdWiHVtTdd15XtfV/YFgzCQCIOQxi22JYrjvLClkw7Zkf1 S9dV0VOkkKtXSrM5bNhW7b1v3BcNxKvXFxqq81yw+81CR5IT21ZItXXNed6X re173xfN9Wi9NVXfasj33gWB4JguDYPhCs3Zf1ESJhOH4hiOJYnilhYZRNQ4 rjWN45juPY+rOL4dkGSZLk2T5RfWRXhlOW5dl+YZjNzCICCAL+BECCMCDACE QmFQuGQ2HQ+IRGJROKRWLReMRmNRuOR2PR+QSGRSOSSWTSeUSmVSuWRWDMBA zGBL+CECXy2cTmdTueT2fT+gUGhUOiUWjRKXzFAzOazeNEGoRKZ1Ag1OoTOj VSpQKJVSrVWBV6uTmtQ6sSyxL+j2u2W23W+4XGT0mZQOCwen1exxa01m9WqO 32F4KV4SGYaTYi5YvGY3HY/ISi6Uu7Ta8RnFYe/4Sywqz4W/xXO1+vw/PyfM w7FWnOwzSwvP62EbHQ4Pa5HcbndbveR/J0y7sCN7LPXvWZvbwnUyLia6w7fR 8+wL/l6io7O95rp9rSdmEcft9/k+LwgDwafe+n1ev2bjf5WnZjxw3z9Kt4CU dXyejzcjpv00AgoS/j6vw1b/QI66GwS8r2wdB8IQioT3po4Lhvm7jpO6/Cew BA7/wQ7ygs5EMDPnArlRPFUGwlFsXRfGCPQoprLoxD0Sw+/iSRu8roupEqWu XHMRSHH8euhBTaRBFkYybJ0nxhGcLLzJkMyNJTnQ4lLmtg40kw1MEjQHETrQ Es0yP3IkVteAEsOxK8wytKE5zpOreykyzhTtPb5SrPk/0BQNBIfPD40HQ8AU PRVF0ZF1CxrRtI0lSdKUq9yDKUgIgC/gRAgjAgwAhEJhULhkNh0PiERiUTik Vi0XjEZjUbjkdj0fkEhkUjkklk0nlEplUrlkVgzAQMxgS/ghAl8tnE5nU7nk 9n0/oFBoVDolFo0Sl8xQMzms3o9PqFRqVTqlVq1XrFZkdJmUDgsHhFOrVjsl ls1ntFptVrkM1hNcpdem1gABBu1svF5vV7vl9v1/iszt8GpVMr7AhNuwGLxm Nx2PyGRkNiuGGueIhF2IL/f6AAIBQGcz2g0Wf0Od02l0mo1ej0+u1Wv1Os2W t2ew2mx3W53m43234G24W14m73/D43B4u95XJ5HM5/H5fS53T5vQ63R6/U7H V73d8Hc8Xb8na83Z9Hf8fn9Xl9Ph93t9nw+fr4mCsOErs0w8JuzMMlAMBQHA kCwMqyBsGmD9qauj/wPCEIwlCcKQqi0EvzBa4v4y7/CDACNtEiTTJC2KExNC UUKJFUTs6h8SIXFiTRklERIXGCRRVHTaKG6qKxonUbIbHEWtcjEgJBJCISEh kiSTF0btAiUMAAyq5LFB6OyVJUfx4hEuQDMCdx3IyHTJJySzEj0aTUikzykp 83kArMty8AE2oVPEjzsiU6zKjk2T4hcqStDixMUAE0PlOczUFO8oIVHEmIQ7 aEzRPtIUvL9IUtOE8t7TtGIbSdE09Uj40dQNRUlTlKOGh7jSa88i1lUUi0VO 1T09W9d0bP9VNvWs5V419Q1hVtS1tGNc0dY9f1BV1lU/aVcT+hlYodarlWvZ FNVHZtfW9PVl2tcNTM6yj9Q3BsASzR9n1Xc9y2nVl52HTd41FMV73fbV5WNf F639fVmXzYluXhgV5YVaVMXhgF+17iOCYTheJX5Z2GYRjWA4timIYxjuKYHL uH2jg+RY3j09ullTiZRemJZdktvRLcCJtFdMNICAgC/gRAgjAgwAhBBILAhA Af7/QABAKAhsPiMThsViEZjkNiUUjshjMWj8ai8gh0QksckkYkUmlcvlMnjs tlE2msql0zmMyhE4n86lEwndEm9Cn08otBoccntMmNAkdIllUpSAqVGnM0qF LkNSrNdo9cq9asVbqNWs1lqtkpNgtVnuVTt1Ml9PtlXuFksN5l99t8bkV4pN or0WjtpQEGhkIxiByECX8EIGMhuUxM7vuAwszu+aq2buNf0eGpt50V1z1Ow+ h0epxWEtuymV72Ot1V7zOnxE+2+n01rte20F81+u4Gssd4zmk4255FJ2l/5G /4lj6Ve4Od7nNwOq7czy2Og2QQOSynjAEKxu14/gn2w4u/8PU+F05nV3HT2f z/zePe+j4v05LUQI+q5uu4UBvu4cAv/BznvzCTtJE+UCvDC8Fvc+8FLFDy/O 4/sMRG+z+Q5E69vUx7IoGgqDoShcIwnE8MsEAEBRDHUbQpAEex5GkILnDcQS K0sEwPEslQNH8lyJB8fRzIzoSa/EhStEksSfKsZwrJkgyjK8NwRFEvO8zsNL bFbyxaycXvazCETBMjuxuj7dTkic0sK3scTNG6PP3QUfN2rdAqxI7VpDCdD0 NPLsMG3FDubPtGydJDTxTQFHu+z9IT9REqz2k1Cws6LOzvJMtLbUrnU9R1QS 3RjlTrLNLUVVsxwZXM1RgAEWPPFzK189kRWNY9kWTZVl2ZZtnWfaFo2ladqW ra1r1NBtsW3acz25b9V3AACBobYD0Tehti3Fdd2Xbd133heN5XncVvXpdt7X vaV82jcjyGA81z2G9qFCCm2DqFhCT4VVOF4Th+HYjhuJz1iGKVDi+GYriWN4 zi2O5BjGQ41kWS5Jk+P5NlOUY5lWW5Zj2X5XmeZZrmOb5HmmcZdneYZzm2f5 7nWg6Jnmi59o2k6Rpeh6VprJXLNlgzdgbLoJfWsazrWt65ruva/sGw7FrM14 BNr019se1bXtm27dt+4bjuW23NYT1Tjue871ve+b7v2/8BcWy4Du208Dw/Ec TxXF8Zxuv7rqj1ai9vHcry3L8xzPNbmQHO8lf7zICIAv4EQIIwIMAIRCYMwE DDYTD4hEYlE4pFYtF4xGY1G45HY9H5BIZFI5JJZNJ5RKZVK5ZLZdL5hKIEv4 IQIXEYXDUDM5rN4hOYa/6FMaJRaNR6RSaVS6ZTadT6hUYVB6MQatPILVIfQJ 3A6ywJxBp1Qn/UrNZ5eAbVZLRbbdb7hcblcYXNZegLxOqxNq1U4ZDb3Pq3Yq DQ7nh8RELUAbZicdj8hkclcrrX5ZXMDfYRmK9fLBP8Igcbk9JUMXo9LqdVq9 ZrYvlc9l9Dmc/g7/XZpltBt9RrqJi4jvZVp8NHuJZd9MePyYzy+Zz9ZsMFKc 5udju71nenm9DZOBCOFCe+APD0ABzqR6I76vNJvZ7Yr7/h87h0s1J+rPfv+d 1trGoTxvK861ITAT3LXAECPA4q0wUh7vQQ5EBsZBMKQk8cCuLDEFwkjT0Pkh EQJO48AwYib3xE8UIxRCLfxXB0DRDFrFRfCz6RuyiDP02qKKsIKZo0/jrv8w DtP27sNQci8YxHGEkxtGgAo1JkPxnCcMwvK0VShCcmIpFkuTBKcTIlEssy5L 8aypK0wOFDaKzXKUOS3AU2yfL0cTyo77R4iEfIjICLSE7YAUHI7eSfLEt0U5 UtRlNCXSrMNHS7Mk00gjc7H/FKV00i8SUoiNNU44dKVJUFMVJPVVqJPiIz+i 1AolQ0+0K2cjVqrk3SUiE8JJEVVJLSTR2BXjyTJYMy1DR9fJTTzm2XZVUzVS 1I1NaM6QrXdMVZbqjVchFYI3WS/Oy61CVosNEQ7R6KWakVi2nOSMTjYk2WxE 9725aF5QhfcrozetkXxStN4JUdozfd1qofZ742pdmC29iakXAlV0uxItz0O/ +I0XOajTNbOPWtSeTW3lE74ZT99Xtf6WZFZmV5lg2X5pS93ybeeXV9eOc4po CQYs6lb43XLQoCCAL+BECCMCDACEQmDMBAw1/w+ExGEAGKQmHv+JRmNRuORq KAGLx+LRCOyWTSWPxeEymSACWRiNyKJSqJTIATSTyuKSGdy2My+c0GOy+bTi dSCH0Caz1/0qI06j0ahVOY0yiz6J0yf1ql0iYVSwWGxWOyWWzWe0UKFwQgQu 0xKFw1AwJf2y3XCDXK6XaD3iGQ6sW+yVDBYXDYeu1LEWLCYjG4+uYuq160ZD KZLMZnNZvOSW1wW+4W4w296BgRnR3OB6bUXnAV/OybG7HaZ3Z7XJ4rD7eXVb I7XeUHLbrccXjcfjwu75i9au26GFa7VXXWX65cTkdntZjg9vvd/weHxePybK K7TS8/T9bSc7l9G/oHseX6fWo4H7fn9fv+f3/IQz71L4YEBwK00DPUhMBta+ L0vfADpPm/8JuA38KQvDEMw1DapwDDyDQRD8CQPEkBOqiLUwc6EIPjCUORet LuxhGcaRrGzsxFEMQRLHMTwW9jpx/FEIvxG7yKdGSqKI86boeUEnjDKKEj/K hASsjiFiDLUXMZC0KJsoMuNzIqny8o6MsVGUlgDMKkyZNrYKzNiZsCj70yMw UexNPc9T7HcEyBFT1yHFsyTw8EkTMwdFN7OcmzioaKE/SYwUq3dGQ3JKpqvS FOK2y8y1BNTfVBLtSzHTrIyeUEojDMVDw7P8/RHPlZVtQchPg5rqUBQjr0M8 c1pHSCOOHN1HTTL1E1FTCw2EnLsVXVs7zknlkWBRqOWSr1n0fYs3oRV9R1Os 1PK7Yb72IxKW2Mr9NUjcl0vMr0sy1SZP0qMFYLLWcdVpfseRWAEUvdgTU1e7 1zUbFzLXRat2WUyNl4QnNu2thyOysQFdrZM9w4heN1qbiNuSYnGJzrZuF2xd 7hVJa2YZBhmJZJk+VXm7FxoveogyoP+NX2s+AVrf9byFXMWY5E9dNe/t2zAk ubXJlFU2Zq2KJPi1j4xb9r6rbeZ6vY+pbBmWU5LRyTZzm9N5fse33dlWqU/q U4a7teQ1DuuP3VoKc6HwGjYDQemSDpek6a/l27vMnF4fr+zbjvNTYvvmFa7r nH7plmabRsmz72ju8XFtihTXmOR7Fvt5ZFxyxt5nWQczvywcDovb39BXD4G6 SAiAL+BECCMCDACEQmDMBAw1/w+ExGJROKRWLReMRMAxuHv+NRyHxsAxmEx2 EyKTRKURCESuPSqQS8AS6TzGSTeagGOyKSyGNz2ZRaeQiUxGaTCdSyL0eZzG mUyc0WoRWhySix+k0GcRiXV2nTaW2Cl2Koz6s1ir1ujWSkWmKU+f0SlWq6XW 7XetwuCEC9QWDXu+3y/35gYDB4LC4TDMCJwuGoGBL/F42DY+3XjMXSq1K2U2 z1zO3DP2vR6LL5ivSO5P/N3OKoDYY/I3uc0Cy1q36HdaoAZzS7u3VOScLM6a lcLkZ20a7Saet8S28ymQsg9U/9fYIDM9vud2cYHwYfw4nEYvJwjzxHHQ3Z4T KQyHczvfPl6y473pcqqcD87yJt9AD5NQr7eJ2+7nISUEFDDBj2iA27Wtw0Tb LC0cIQPATPP+/sENBCzuOMmToQ0iUOubDKqoy50RqxDbcOo6pPxkMEaPpG0b ru8bzMVHjyx7HT3Ik9bIIHIL1Mq+LcRw+kWSXJ0nv3D7vJFGRPxoMDbye5Mp ShLsvS/MEwwUUEGDDE0wzQzEgR9Nk1vGhL0oVJEiMlI05PgQMzzSjMmz3Py7 z7HKFoM7MsxvEdAz+nEUpvPVFUfHDsr22lIUq77xUw8k3UzHc2oPIU5wchb3 stDNLVPVEmP1VNWVbV1X1hWNZABTdNU5H9MzhOyESHUVPyPPFHVnYdWUTYlj 2RZNlWXVNa07Z1cVsxlQTxX1p2BUslWZbdFWNblv3BcNxXGi1oU9aVn1/ONe VDIrEVJJNyXlL1vXne173xfM0XNflb3PeE6XXWk52FfWDRDg2Ew9guFYbfVR zA6og2tgGKWpbOHYy+tDY1h1647kFwsDJ7stld2IWw9mT1/O+MTA1MKTRmDV 0XAmYxbErjt2i0DS5kMnS3hk+QI4NV5/o9YTfG9e5Xa+W5VOt34veOXwxEVV 0Yi8TQjjihatjmg50rOEQroWkQHsejbRAL7Z9s+31dpUbaZqOUaeQKAggC/g RAgjAgwAhEJgzAQMNf8PhMRiUTikViwBjEPf8TjABjUWkEhkUdj8SkkQkMnj cmjMoAEqjktlcvmUwhE2mkel0ink9n0/oFBoU9lU4ocgnFFmVHplNp1PqFRq VTqkihcEIELqsIhcNQMCX9YrUSrsNsFig9kg1ektbitGm9Lt1vuURuEUu9Jj EitsJvN1u9zwWDt2Bqd/nUzwmLxmNx2PqlXgtpqtlr8DybAieWs+Zzdrh07x eIvssAM+0t4ut+1d0xMx19x2M8pWzvWzyG53WwjWGnMT1O8l214O743H5HJo eSrOUyOgy9hz1qhlmzHNzXUtmiwkdhNt32FvcI8Gt1W42Xl9E59W9wHv9fK+ Vb4ncqO393x+f7/n9x7mLGyroM67DPuq6K0OyiLLOKubau++zRpq8YANS/Du MQ4DhvNB7yIe8L/RC2kOPMpz6sU9MIxFFcWRansAOcqbOOvAKFQHGkYgBBkV PE/TdxBFyfyBILTQbIkjyRJMlMhGEFOfA8CRqrkbulArtNDFDuxK40hyW88j S9LsvTHMkyzMismrdGcqylHUqQTAztyzM86MZMT9u9Dx/xOi8tzrP9AUDJiD Tgrc10LBc3unRMDzBQVHqZO7ktvCCZwvLM8p5R1IU5Ts6zTQ1FStRivSjHMd znT1VSFP08T9S9JUjCkXU3VdbTHUEBShHEnSnXc2VO6Fa1vYj2R4+bfNJY9i 2ZZtOVzJ9S15OLrWBXs3UbZdnVtWLdWS+D8wbTK+W1bdzXOxdoRlUU20PRcb WzVN0W5VtkPhSrWNtet535fsQoXNq3Wla1qECgKAL+BECCMCDACEQmDMBAw1 /w+ExGJROKRWLReMRmNRuOR2PR+QRgAyOHv+QyeUQmRgGEyWVy6SRCKy+ZSm bTecTmdTueT2fT+gTqV0GLwJfwQgQuJwuGoGjUilRKmQ6a0SrVesVmJTSTVq vV+wTauWGyWWzWetQuoQa1sC22+C2y4265wm20uDU2n3WpXmqV20YHBV+x4P DYed0OESXEY3HY+v2q53Ck3LK3TL5TJZm+RGp06B52FX5A4zIafURvC6nWRb VyqY4Cf4oAabW7fcbmK5veZbe5jf3eEcLPaS95e8Qy/7rmY/X83U88AdKc1z qdDsdmy8HJ93Od/ueCD33laCj6KEZ/bdr2WDr+3EdbY0T5AH1/D8fmg+H+b7 /OA8YAOI0byuOqLivK+79QWnj3wYs76wU6r5oRB0HwvDDdv+zUNu8/sAGA5K 9NC5DyKbCUMxSjsLRUrUIqqraRonFCItoi0aRbHMGQ/DkQR6uz0AAz8DQDAk TxhHUkpnCklLNFjZyZJspPxHkPQ68UfSDIcSQPIzlynMEKyjMMXTGrMnzJNL USrLEeuJAb0uNLkizjBMkTVFs0TxPc+T6r02UBK7fxEhsiRDE0vz9FU9UVRt HUem1AyzNrOzhIU5PPEsESO2VIQXRlPVDUVR0lN0rUnLs6qagICAL+BECCMC DACEQmDMBAw1/w+ExGJROKRWLReMRmNRuOR2PR+QRgAyOHv+QyeUSmVSuWS2 XS+YTGZTOaTWbACFwQgTmCwadTydz6esCf0KgsCE0WkRKFw1AwJf0qJ02HRC b1esVmtQiRgGS1uwWGxWOyWWzWe0RagWujWyiUOlXG4UOpwanVCpUy7VWTWm /X+r12v4DCYXDYfEYnFRW3XKj47G3SEXmI1SnwPJZW9oHB4vPZ+I4KraDSYj RX3S6nVZ7I4+567Ya23XWGQ28ZmFZvO6veWnT73gWXf8HicWybK28m37HlUn cQjLbej7Snbvjdeb8PsZ/tQnuyzT98AeLt+Xzbnl8j08rIeznzjN9KF9S+ef 7S/yfe/+L8yjwpI0bvQA1D9QK7D1Pa9cFMoyj0LuzDpr02rOQDA0LI4/sLrO /6vQqlztQ460NRG0sENfEzmQU+jLqi97LRFEkYwFDsCRlDcBwylMQRxAcbR8 0EUSC5rJxc+MIPnCTqw9H8RxzJisRDJauJGicYIlHcaSdJ8trBIUFxO90UxW +SDyS+suRJLU0JtNT/R7K83zXOS0S9BMEudCLNQnMilz1JUazm+820CmFBpC /k40JRSsTrMEvxTBroSNFs8wdM9FvtQzPU04VErDTlMVCkNG0hR08SRPyGoC gC/gRAgjAgwAhEJgzAQMNf8PhMRiUTikVi0XjEZjUbjkdj0fkEYAMjh7/kMn lEfkYBkspl0dlctl8omMQmc3nE5nU7nk9m8LghAoEFg1BodCotEYFGpNIpdK pjAicLhqBgS/qNTg1VmU+r1fsFhmEkm1inErhMlmr/tcWttmuFxuVzul1u0p o95pt6p9OqNZhGAiNUhtXwUKrcOst3xmNu9vx0ayFohFqskmiWQhOUjVdyOf 0Gh0Wjjl8v9Q1F+1OmpVahmFgetiWEQOe0m33EezW33cRte93s6zm5kO24nH 5Gh1mq5nLvkJw8I2mG2WDxO1xfJ7XH4Oi7oA3+Xzfi7fl83n9E55179l99fu 9uuqvUp3yxWY9P5x3f0Hf8KWIe/iEOGjDjP1A8EQSsz3tO5r2sE6IAOm2L6t m68DQVDKfQEyLJpGtLsvBD7KxDDUTRPFC6wY1cHxY+EXvsq0KIXGMMRTG6Tw 4/sRgAy0APw8cfxxIciSKn0VwdF8GxowLqsQ18ZKxJzpQvEsjSui8dP1LUsN 08kuzA48kTHFskxi+kmOtKEbTDMEuO0zk2TbLwAxBIE5zw0UySVF0ISnCTrz Qg8LTXK08yvN9DppL8guNRKzx5OVFUmsM9yXMr3zPGdBzUrlDUpHFH1AschM zRkB1Oik40+kTL1FUdYJfS0+xc6E/wnKUK06+9Y0RVNepu/8fWHVjfUjYq3V dX9gWYmdZyTS8+V1J6qoCIAv4EQIIwIMAIRCYMwEDDX/D4TEYlE4pFYtF4xG Y1G45HY9H5BGADI4e/5DJ5RKZVK4nIwDJZdMJJD5jEIrLo5JYzNZNCJ5LKBQ aFQ6JRaNIIXBCBSYLBqVTKXTqawKfUqiwITVaxEoXDUDAl/WonXYdNqPZ7Ra bVHZ/a7db5DPLlM3/bY1OIROo9eIverhf8BgcFQKhhathqpU61i8VU7HBq9Y LFXMhZZ7g8xmc1Prpm89b7tCdDG75fpVo8/qdVq6LiMZV9frsdCMnEbJX4Hs 9tlUDptZv+Bcc7weJKNRqMxyOLy+Zq9lsMb0Olz8Rj4ZDcluoVvN9ze9xeV3 /F4/J5fNnuph/Vien66z2oRt+zV+tXu75/xgfD+f5/f8/8APS9kBNi9bau26 7cLC+AANu+8AQgob9wjCkKwtC7BwI6MNPo2kGPk3MOt3BMHwxEyOQnE8VRXF kWorDkYQNDaDspBL5oW+rLRdHaLRTHkfyBIL8xjAcZParYAQO+LeRvGkRvss 0hR3H0pSrK0rs3IkCyLLktxzBUlQa7koyxE8qTK8czrtNbhzRNyWS1Gcut1M MQQXEUESgy83wvM8+QtNiXrNP0/0LMU5yPLdFTlL8myRPMdUNCtCUkoLjza0 S6UuAKEplQS6pGidPU9TsyUrSU40TRkPTxJcEoCAgC/gRAgjAgwAhEJgzAQM Nf8PhMRiUTikVi0XjEZjUbjkdj0fkEYAMjh7/kMnlEplUrlUjAMlicumESmU PmsmhE3hMuhMzAE6nMjnsQoMvokspFJpVLplNlMLghAqEFg1RqdSqtUYFWrN YrdarjAicLhqBgS/sNjg1ln1Ot1vuFxkNAuV1u13oslm97klHul0nd9nE/wW Bo2Dw1tvGLxmNx0Uq+RruSr9esNphGYiNkhtnzUKtcOo+P0ml02Ew+n1WrmO CvmHv+FvOj2eD2Opmmy1m73m9zeT4GVymXsHFy1atUMzsD5ESziBxW+6XTju A6nXt+vvWu3W36Pev26xO07Hl81u4fG9PH9kLhOfhHPz3N3/K6Hk8/56XW/X 9lL+QA7rxNq8bbQG1Dov9BUFos9cHOC4j2uC5Kyvmr0KNExEGQ2x7+Q5D6Kw C3CIxEiyfJ4hDtxHAsQRbD8HuFCD1QmzL6NA+0LPc5zQvvDUXR+t0POvIUgS LI0jupGEIyVGcYrFHccOZC8oLY/EkSuucDuxIksS7L0vrrJkJSdJaDxrKb6w rKUdTTDMwTejkuN416hx9OE7zxPMGxlMcyzJJr4AA+U1zNNsez1REWPNFAAR PA9GIzBNE0nSjpTFS8aABQNBrRGz4x5SVKy7OTdxFUKkUhUTfVPVT+0xP8+0 BT1BR5HNCxvKs7VbK9SNZU0rV3YNhPLV8/T899Z05TdQWBYcf161dfx9VKL1 YkFqWcpNrWy6di1lWMxwwQKAgIAv4EQIIwIMAIRCYMwEDDX/D4TEYlE4pFYt F4xGY1G45HY9H5BGADI4e/5DJ5RIwDJYnKpZKJhG5dEJjNZtN5xOZ1O55PZ9 F4XBCBQYLBqFRKHRqKwKPSqSwITTahEoXDUDAl/UonVYdNJ/X7BYbFIpJXrH IZnJolabPILZbbhcblc7pdYxSLxTrzTKXUr9faXW4NVqxWqpg67arti8Zc7f jchO8fkcplctl8Xe7/T83msDCMNEa5V4Hn9FiEDL8xq9ZHcnrdhFtfkpHE9V sZltYlt9xvcjns5gODw+Be8FDIbhdNCtRvN9z8vs+hsOlNtn1d917Liun3bl xb14b5xPFUeXCNHyqfx6tzu977p2PhlPlP/r8wB9/x+5P4PG/zOvE0LmOQ0i svOADRvc/kGJ8/UGrbB7aJWs0IIRCULQyjMAOFDj1tBBD0tLD7TwLBcNRQk8 MRSnsVprFzoRhFkUw9GsBQ6g7DwK9SFvYxMZyBFTtyCuUZLdIcUyNIkaRu8j /ya40QRJAjCRHHsdPbCsly2islS5I8KO4skwo4lSMxPIskI1MyMTRL8IRtJ8 5QDOcQtRHkcxLLMxTfPsvT7Ms1IzP7qUFQFDv7KFFTrJzzSm9E7ytPMqR/RE /UNSzrUwhM2AAkq0u1MjMU7T7t1DN1MxnOM6VZHCpz05NJVfSjUy1VMgUJW9 OUwx9SK9UFN00AKE1Qls1V8f9T1tXUl1XV06UdK9YECgIIAv4EQIIwIMAIRC YMwEDDX/D4TEYlE4pFYtF4xGY1G45HY9H5BGADI4e/5DJ5RKZVKJGAZLE5bL 4lMYhCJo/5vK4rLYTMo7OZnJJqAJvQJ1R6RSaVS6XC4IQKdBYNT6jUKnUmBV KvVqzWK0wInC4agYEv6/YYNY59TLZbbdb5XRrhc7pHLlNqFJqDLqHCbvcZHH LXO7zMMLeL5OMPdcZjcddKrka3kq7XK/Z4RmIjYobZc1CrTDr7j9JpdNGb/p 9VOtTiMHRMXRcXSp5CNfqNnrqHssTq99v99lMvXuJluLwqxaIZnYHyYlnEDt +B0+pSdb1exhN72tfRt50sAAZ7o41f/Nuez6fVSORxvd7cpCc/COhnudm9D0 fJ6/5/cM7b/P666/MCiqSvPADsNqijuvRAMHwg0DKvgycKwnCzhq45SxvtDT nvy8EIxE38BxGurvQdEzTxLFUWunCkLxjDL4sy+8JQ45sPPw5b9L1F0ftNFk gLdBcQyGukhSPJS6xhGcMOPJ8dRu5izRs+kQP3JctNpFMtrZIssy9MUxzHJs oRlM75SsAD6xyhcNtFH0yTmlkuzo607TvPU9v5Mz3yjP03w/HkO0FHa1TDPl FIjJNF0dR9IS1QNAUosEaylK9CTcg9B0ROVI0fRtQVHUlSuxSc0T/VMaUPKj 5zZLFP1NPVRMfMB/lBXIw12hI/18QFgIshYg2JIzwwPPLYQSxEO1nZ0y0rJ1 VwtNVMVhTUq2s6FjWfJdaxJAoAW4xBP3KMFzy+2NkwJAFclBXYw3Hbt5z7aM z2lfE1uggICAL+BECCMCDACEQmDMBAw1/w+ExGJROKRWLReMRmNRuOR2PR+Q RgAyOHv+QyeQSMAxySxZQS8wzGBL+CECUSKSRCESqSyqEy2JTydACFkGjJ+k GClTemU2nU+oVGpVOqR2FzWrwWDVit1pgVyv16wQmxxKFw1AzOyxGzw6h1W4 XG5XOQ0KTXSTz6ET2Rz+3xVAYG0WqCQm9ACgADD3674qc43DX290O7RO7UWj H/NYFAXjPZ/QaHRXiskDS6eu6bU6iw6rW6yJ220wOvbGDWjE6PdbveRbK72L 4e+SvJ5CK8LKY/I8TEX/HAHh7md8qg9SI7/n4zgdvud3vVPWWDxWLya612uF beG4TXbaGW7jd/5fOm9j58h//iM/rp9DnPs/rov+6zluk57Ev4+kFQXBjePC 8sHvNCDVwoYD3MG2j2rM9RAwNBsPxBArnO8/EEt8yTmsa7ETQCh8AQPAb/Pj FcUQ9EMbxxHKPwjHkKvHDQAPQhDZPYhcLvhHUkwVF8SRrF0nPiibOQwmjCv6 ibhyw5MZMtAkWxmx7MCCzQ/s5JUzzRM8etfH0JzZN8hKJDkioPDb3w7Ec0z0 0EmO7EsoIyl5QJiML2KrGkuOrRMYMbMSkE+pQwT3SdKQXNcf0u2qETjIkMyN OzcTzStRqnPtSOukdH0jQ8vJS61BUJG1T1nWi4UzCVcVu2FQPXT06rZDlZVr YaP1NWiFoXMy42M49Ws4mqa2JaVpqlXU21zCqyU1YE7zpC1eTxKNqXG4NW3J c90XTdFrThN1MWzcFvSPcN1XrRVhXtfN9X3HV2XfdsgU5OdfW/blQ3FflpWZ hOGYbhzR39d2JWxgr027gl53xh9R4XjePY/kCmU+zyjCDeVwICCAL+BECCMC DACEQmDMBAw1/w+ExGJROKRWLReMRmNRuOR2PR+QRgAyOHv+QyeUSmVSuWSi FwtATGEyMAwmSy2cTmdTueT2fSyFwQgT8ATFAQ1AwJf0KFxOF0ilUyDxKnw6 IUSsVmtVuKTSb1ywWGxRmaTar2O0Wm1Wux0GC1Od1WkwO3sCnQaoXQgU2qXi rSa2YHBWKvWfB4eNKDFGHGQk/4+hUKE4pQYwwwlP5kwZuZyPMZlwaGkZlP5a LSWywjUZ6EaTQuDR5rN6kAV8AbTbZTTa3ZGDEb/gWC3Xu4Tq5VG63eGQ3kcS 7X3loHbcHqdWP4XAdbgbrGaQQd8g+HHn+jdww6SE5bSZswbTveDw2Z/7iz/T 56wAe8QeEg/L7M6mrVIe8z0IQ9Teu1BMFI+4a+Livy5qW5LoLzCTnOUpDpwX DcEuxDjBv+kT8Ns+0QtvEaHxNEsUOzFcAtq+sWRVFkPxrG0GuKnLjr1ByFQg 5seoQuUNRtIrBQ9Iy0xMi0Zxe1cnRjKD7ylAD/RohEXPlKsBSmjkiSTMDDxw 54AP4j6lQw5keRyAEdwtIM2whL8wzorckTqrklorJsrSpLEZSvE8pT5LlCRh LsuTxRTtTGiczIxNCKzcqUyR86MgTZIbDUXTiezvTqfwIzLvv28THvKxbusy 9NVE+9lDSfLU/0HQMsoQpTXt3Q9RE/Uj+PGo1QWErdGorR6I0ii9JwmiNlwv Ci/2HaSW0/aaePMxzIMioaEWw3lXM5WdZUE+TzWAmNbUPLdd1Sy9boFY7c3b bLyJla17p5YqLv5ZKM2dOF/0zOVN3xgqyJJgmDYVheGYXfTjR/NdKyFiM34E 6M54bhdq41juPY/MOHx1itKTTCOS2g6WE5BfGOZZl+YZjMSDZRB9L4lk1MYn OOMZXmVhZdn+haHoie5EnGA52uSAgIAv4EQIIwIMAIRCYMwEDDX/D4TEYlE4 pFYtF4xGY1G45HY9H5BGADI4e/5DJ5RKZVK5ZLZdL5hMZlM5pNZpC4XNoTDU DAl/BCBOYlC55PqBQojRIdEJ1TadT6hCJGAZLUatV6xWa1W65Xa9FqnWKNBY PQ4NRYHZGBE6VPYFUSDcZ9X7pJ7iQbHQYNR73ar4wL/gb9g71gMJC8FhcTiM PfcVjcNj8ljMnjspl8tmcjmM3msXnshn87o9FpdDp8rpNRnNNqdbrNXoNdsb XV7vc61f7ZZ4beaRCt5bp/BJsgONaOGQLry4xxkBPJLsNn0+l1dl1tV1Ov2+ z2Nf3O/3fBtPD5fJ5+14vV5vT7O96OLx97b9zat3DPnyd/CLbvrKmL+rSwrm QIpLgv89b0Pe9sFPHBkHwXCMHQlBMIQnC8Kwo90MQ3DMONohLdJlAJfq3EUD Pw4UTuBFMEJnEkVwK5a2ujD8LQ9HEOx1Bscx5Hcbx/DUfSHIEiSFIsbxfA76 KzGIARg+yzRbAT9ou28mItKEBxlAktSPL8bTBHskTFIMwzPMcyyNNEzTTNkQ IRJyEyvEqPRIqLRPu5EnS8/6LLuhLcIvPray5GbgxrN1FTbRk10XR1GzJN9J UfSlIzVS0oopQCEUEjM7qaoDnKBPklv1Pz+VNOSEU4iNPIrQlDOZQlL0nTFb 1tXNK1xXddVrXtgV/E9VgBVtAyxWFTJtUTjRDUktxRPdNRZaVoTmuKLVeilY 1kusaIfXlhUhcdM3LcNyXPc1fXRdd1UKidjIlbVqPymdmEBZzlTjadUynU93 37asq2uIKJ3nKWBVRbquVpdlg4dcV3YjdOKXbiuH4lOAAWJeIAYPaN6pfe98 zzhD81Lf1iYJY860HVV+YWrdvn/i+J4tm+MZriGd4znudZ8zU/2xTtkZdfyW 5HfdSVHZ8q25kEVZhoS8aLPWT6lmKsYboGc5xm2u7Br+xZ5n+y6DpWB1YuWq oxUCUaTjdnudkmYLagKAL+BECCMCDACEQmDMBAw2BL+CECFwmKRWLReMQuGo GHxGJxiQSGRSOSSWTSeMwaNv+WQuPQaXsCYzOCzCazKbzSJTadziezqXTmhT +h0GiUejUmeUqfUygUuoU2o0+pVWqVei1Os1at1ikVqv1yw16nV2zWOz2W0T 2USeNQ6BW2ExFAXW5xGCXVAXcgXyPxS3xyBzeLYGO4S5STDYO2YnHY/IZHCy q4RC02C1ZnMZuxZrO5yyaDL5/SaHS6PTanUau157Va3RbDT7KY36D5KL4tf2 26XaEXi874AcCw5OGZXaxXdcnccrKYLLY3m9PqdUAYGWP/Xazt7TubHu+Hwe PZ+Ly+TX+b0+jv+f3ev36PrQjdSbe3vf8C9Xz78S/oU57DulADjug/75oSja HwPBEGwck8FMY9T2vhCsKQu70MwnDT2Q4+MPQtEEMQ3EjOQJB8Esqkb7v44L 8OG/ThP827AQDCUaQIjcUR3Hketw7MSw/IMQyHEcOyLEUkyRJcjybIUnSIng AynHyKIekEWPyvD9y1LMYL7LUGOWxEap9KszzRNM1TXNk2zdN84TjOU5zi5k cuRMi+TpPc+T7P0/0BQNBUHQlCzFGzowZQtF0ZRtHUfSFI0lScHTHAdKUxTN NU3TlO09T7IUtRVQVJUtTVPVFU1VBDdVHVdX1hWNZVnWlJR1WtcVzXVd15Xs qoCATgIAAKMCAADhAQAArAIAACsDAAC8AgAATgMAAPgCAABpAgAA+AEAAPYB AAAsAgAA/QEAAD4CAAArAgAAXAIAAJQCAADAAgAA9QIAABECAAAeAAAAbAIA AA8FAADwBgAAnAkAAMcMAACDDwAA0RIAAMkVAAAyGAAAKhoAACAcAABMHgAA SSAAAIciAACyJAAADicAAKIpAABiLAAAVy8AAA8A/gAEAAEAAAAAAAAAAAEE AAEAAAABAQAAAQEEAAEAAAADAQAAAgEDAAMAAAAIAAAAAwEDAAEAAAAFAAAA BgEDAAEAAAACAAAAEQEEABQAAAC4MQAAEgEDAAEAAAABAAAAFQEDAAEAAAAD AAAAFgEEAAEAAAANAAAAFwEEABQAAABoMQAAGgEFAAEAAAAOAAAAGwEFAAEA AAAWAAAAKAEDAAEAAAADAAAAPQEDAAEAAAACAAAAAAAAAA== ---LA_F1918945549R-1A-854732983=:16982NCE.Roam-- % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail13.digital.com by us2rmc.zko.dec.com (5.65/rmc-22feb94) id AA07573; Fri, 31 Jan 97 23:54:28 -0500 % Received: from netra.validgh.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id XAA13449; Fri, 31 Jan 1997 23:49:13 -0500 (EST) % Received: from validgh.com by netra.validgh.com (SMI-8.6/SMI-SVR4) id UAA07710; Fri, 31 Jan 1997 20:24:00 -0800 % Received: by validgh.com (4.1/SMI-4.1) id AA11054; Fri, 31 Jan 97 20:23:43 PST % Received: from netra.validgh.com (netra32) by validgh.com (4.1/SMI-4.1) id AA10461; Fri, 31 Jan 97 09:48:30 PST % Received: from venus.Sun.COM by netra.validgh.com (SMI-8.6/SMI-SVR4) id JAA03725; Fri, 31 Jan 1997 09:46:36 -0800 % Received: from Eng.Sun.COM ([129.146.1.25]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA27428; Fri, 31 Jan 1997 09:47:14 -0800 % Received: from doppio.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA13263; Fri, 31 Jan 1997 09:47:10 -0800 % Received: from norquay by doppio.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA28102; Fri, 31 Jan 1997 09:46:47 -0800 % Date: Fri, 31 Jan 1997 09:49:42 -0800 (PST) % From: James Gosling <[email protected]> % Subject: Re: Java numerics issue % To: Dean Schulze <[email protected]>, [email protected], Arthur van Hoff <[email protected]> % In-Reply-To: "Your message with ID" <[email protected]> % Message-Id: <Roam - SIMC 2.0 Beta.854732982.6929.jag@doppio> % Mime-Version: 1.0 % Content-Type: MULTIPART/MIXED; BOUNDARY="-LA_F1918945549R-1A-854732983=:16982NCE.Roam" % Sender: [email protected] % Precedence: bulk % Reply-To: James Gosling <[email protected]>
210.10	extra precision not always good	CAIRN::HARRIS	Kevin Harris, dtn 381-2039	`Thu Feb 20 1997 14:12`	74
	From: US2RMC::"[email protected]" "Douglas Priest" 1-FEB-1997 15:22:22.67 To: [email protected] CC: Subj: Re: Java numerics issue Coonen laments the fact that Java as it is defined seems not to be a good environment for serious scientific computing. While I imagine some people might find it reassuring to be able to buy an airline ticket over the Web and then click on a link that downloads and runs a structural simulation of the aircraft they'll be flying on, there is another application that is important in the context of Java and the Web that would provide reassurance to more of us, namely encryp- tion. Many encryption techniques rely on multi-word integer arithmetic, and on many modern computers, the easiest and most efficient way to do multi-word integer arithmetic is to use double precision floating point. The key ingredient that makes such techniques work (and makes related techniques for multiple precision floating point work, too) is the ability to round a known number of bits off of the end of a floating point number; for example, if x is a double precision number no larger than 2^51 in absolute value, then computing (x + 6755399441055744.0) - 6755399441055744.0 gives x rounded to the nearest integer in the direction of the pre- vailing rounding mode provided each operation is rounded to double precision. The magic number 6755399441055744 is related to the precision used, here 53 bits. Experts like Coonen know that the same thing can be done in any precision and that there are ways to compute the appro- priate magic number at run time to match the expression evaluation format used, but many programmers who think they know what the IEEE standard has to say about precision might not know of them. They might not realize that in some languages, on some machines, "double" sometimes means double precision and sometimes means double extended and which is which when can hinge on what most of us would regard as accidents of notation. The choice that the designers of Java made sacrifices efficiency but may well save a lot of programmers from the embarrassment (or worse) of not knowing that y = (x + 6755399441055744.0) - 6755399441055744.0 and y = x + 6755399441055744.0 y = y - 6755399441055744.0 don't mean the same thing. Douglas M. Priest SunSoft Floating Point Group Sun Microsystems, Inc. (but only speaking for myself) % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail13.digital.com by us2rmc.zko.dec.com (5.65/rmc-22feb94) id AA16882; Sat, 1 Feb 97 14:59:32 -0500 % Received: from netra.validgh.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id OAA15447; Sat, 1 Feb 1997 14:49:00 -0500 (EST) % Received: from validgh.com by netra.validgh.com (SMI-8.6/SMI-SVR4) id LAA13487; Sat, 1 Feb 1997 11:22:04 -0800 % Received: by validgh.com (4.1/SMI-4.1) id AA12534; Sat, 1 Feb 97 11:22:32 PST % Received: from netra.validgh.com (netra32) by validgh.com (4.1/SMI-4.1) id AA12528; Sat, 1 Feb 97 11:22:27 PST % Received: from venus.Sun.COM by netra.validgh.com (SMI-8.6/SMI-SVR4) id LAA13475; Sat, 1 Feb 1997 11:20:37 -0800 % Received: from Eng.Sun.COM ([129.146.1.25]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA19965 for <[email protected]>; Sat, 1 Feb 1997 11:22:35 -0800 % Received: from roundoff.Eng.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA22516; Sat, 1 Feb 1997 11:22:34 -0800 % Received: by roundoff.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id LAA15192; Sat, 1 Feb 1997 11:19:50 -0800 % Date: Sat, 1 Feb 1997 11:19:50 -0800 % From: [email protected] (Douglas Priest) % Message-Id: <[email protected]> % To: [email protected] % Subject: Re: Java numerics issue % Sender: [email protected] % Precedence: bulk % Reply-To: [email protected] (Douglas Priest)
210.11	Coonen's response	CAIRN::HARRIS	Kevin Harris, dtn 381-2039	`Thu Feb 20 1997 14:13`	157
	From: US2RMC::"[email protected]" "Jerome Coonen" 3-FEB-1997 02:47:22.97 To: [email protected] CC: Subj: Re: Java Numerics Dear Colleagues, In his recent posting, Doug Priest wrote that >> Coonen laments the fact that Java as it is defined seems not to be a >> good environment for serious scientific computing. I would prefer to think that I argued in my Note on Java Numerics that Java is not yet the BEST environment for numerical computation, especially for the tens of millions of users of fpus which use extended values for intermediate calculations. I attempted to show that the flaw in the design was motivated by the strict demand for bit-for-bit reproducible results for all computations across all platforms -- a demand that is neither numerically necessary nor commercially feasible. This letter focuses on changes to the Java spec that would serve a broad numerical community without compromising robustness nor portability. Doug Priest continued to present a compelling example of the occasional need for strict coercion to a given data format. This is a technique used to "split" a number into lower-precision pieces. It's widely acknowledged to be a Good Thing; I merely request that it not be the Only Thing. >> The choice that the designers of Java made sacrifices efficiency but >> may well save a lot of programmers from the embarrassment (or worse) >> of not knowing that >> >> y = (x + 6755399441055744.0) - 6755399441055744.0 >> >> and >> >> y = x + 6755399441055744.0 >> y = y - 6755399441055744.0 >> >> don't mean the same thing. I will try to show that there's no need to sacrifice efficiency and that the only reason for a programmer not to know the fate of the right-hand side is for want of asking. Other programmers might be disappointed or dismayed (depending on their platform) that the simple expression z = (a * x) / (b * y); leaves z a NaN or infinity, when the mathematical ratio is exactly 2. EXPRESSION EVALUATION Here lies the crux of the disagreement. Arguments like Doug Priest's show that strict coercion of intermediates -- whether by casting, assignment, or control of expression evaluation -- is vital to certain numerical techniques. My arguments from the Note show that forcing strict evaluation to float or double compromises performance on virtually every calculation performed by extended-based processors. The C9X proposed revision of Standard C offers an alternative to one-size- fits-all evaluation. As Jim Thomas pointed out in his recent note, cries by some of "unpredictability" and "nondeterministic behavior" are overstated. He points out that C9X permits three evaluation styles: >> 1. evaluate float expressions to float, double to double, and long >> double to long double >> 2. evaluate float and double expressions to double and long double to >> long double >> 3. evaluate them all to long double A program can ask what style is in effect at translation time. Method 3 applies to extended-based archtictures like x86. Method 2 applies to PowerPC. Method 1 applies to a variety of other processors supporting IEEE arithmetic. This flexibility captures the spirit of IEEE 754, which explicitly recommended hardware support of an extended type. During deliberations on 754, it was argued that the use of extendeds FOR INTERMEDIATE CALCULATIONS would defend some naive calculations against precision and range problems, would offer extra capability to experts, and, most importantly, not unduly compromise portability of programs designed for float or double calculation. But poor support by high-level languages has given the extended formats a bad reputation. Some compilers set "precision control" bits to force intermediates to be rounded to double. Others ignore explicit casts to a narrower type. Many offer no "long double" type to explicitly declare extended variables. It's my experience that, too often, compiler implementors appeal to a questionable purity of language to excuse "simplifications" that compromise numerical applications. With Java, however, there is an opportunity to support robust and portable calculation across the diversity of IEEE platforms. It's my hope that Java's designers will look closely at this issue. With the announcement of one company's intention to deliver IMSL libraries in Java, and the announcement of an ACM workshop on Java for Science and Engineering Computation, Java promises to be an important language for numerical computation. Designing its expression evaluation for the best balance of performance, robustness, predictability, and portability would be a boon not only for Java programmers, but for C, C++, and FORTRAN programmers, whose compiler vendors might be induced to meet the high standard set by Java. REPRODUCIBLE RESULTS Discussion to date suggests that the urge of Java's designers to limit expression evaluation to just one style is driven by the demand for reproducible results for EVERY calculation across all platforms. This means, for example, that the method java.lang.Math.sin would compute the same approximation to the mathematical sine function on all platforms. As Guy Steele pointed out in an off-line note, >> [Java] requires that java.lang.Math.sin, java.lang.Math.log, etc., >> be rounded as fdlibm [Sun's publicly available math function library] >> rounds them. There is no objection to provision of alternate >> implementations as long as they have different names. Fdlibm is an excellent piece of technology, but I claim that the numerical community wants accurate results fast, not an arbitrary definition of correctness that is blind to performance. How will the IMSL codes be ported to the Java environment, where they will be subjected to performance benchmarks? Anyone hoping to sell products based on performance will be forced to resort to some "java.lang.FAST.Math.sin" in order to exploit Pentium's highly accurate fsin instruction or PowerPC's all-but-correctly rounded library that exploits fused mul-add. And what if fdlibm must change slightly; what is correct then? Results will be reproducible until the first benchmark is run, when a balance of the realities of the marketplace and the real needs of numerical programmers will drive Java practice to a less pure but more useful plane. Because exact reproducibility of results drives the overly strict expression evaluation style of the current Java spec, I encourage the Java community to explore this issue fully with numerical and business folks. I consider the current definition of java.lang.Math.sin far less desirable to the numerical community than the chance to exploit fast, accurate evaluation across all Java platforms. -Jerome Coonen % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail13.digital.com by us2rmc.zko.dec.com (5.65/rmc-22feb94) id AA24969; Mon, 3 Feb 97 02:37:39 -0500 % Received: from netra.validgh.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id CAA16240; Mon, 3 Feb 1997 02:27:15 -0500 (EST) % Received: from validgh.com by netra.validgh.com (SMI-8.6/SMI-SVR4) id WAA25946; Sun, 2 Feb 1997 22:55:19 -0800 % Received: by validgh.com (4.1/SMI-4.1) id AA15601; Sun, 2 Feb 97 22:54:48 PST % Received: from netra.validgh.com (netra32) by validgh.com (4.1/SMI-4.1) id AA15595; Sun, 2 Feb 97 22:54:43 PST % Received: from terminator.be.com by netra.validgh.com (SMI-8.6/SMI-SVR4) id WAA25936; Sun, 2 Feb 1997 22:52:54 -0800 % Received: from be.be.com ([email protected] [207.113.215.1]) by terminator.be.com (8.6.12/8.6.12) with SMTP id WAA11236 for <[email protected]>; Sun, 2 Feb 1997 22:56:04 -0800 % From: Jerome Coonen <[email protected]> % X-Mailer: SCO System V Mail (version 3.2) % To: [email protected] % Subject: Re: Java Numerics % Date: Sun, 2 Feb 97 22:55:54 PST % Message-Id: <[email protected]> % Sender: [email protected] % Precedence: bulk % Reply-To: Jerome Coonen <[email protected]>
210.12	David Hough's summary	CAIRN::HARRIS	Kevin Harris, dtn 381-2039	`Thu Feb 20 1997 14:14`	244
	From: US2RMC::"[email protected]" "David G. Hough at validgh" 5-FEB-1997 01:48:58.73 To: [email protected] CC: [email protected], [email protected] Subj: Comments on Java Numerics PRELIMINARY - SUBJECT TO REVISION - NOT FOR PUBLICATION A B S T R A C T Java is not a machine-oriented language; it is intended to be as machine-independent as possible. Identical numerical results on every machine is an important part of that goal. Java can be improved in its suitability for numerical computation, by allowing operator notation to be extended to user-defined types, and by recog- nizing IEEE 754 exceptions. troff, postscript, and ascii versions of this draft will be available at http://www.validgh.com/.java. Jerome Coonen awoke the [email protected] mailing list from a long dormancy by arguing that the Java language definition should not mandate a uniform style of expression evaluation that is suboptimal on certain architectures, in the sense of being sometimes slower and sometimes less accurate, than methods native to that particular architecture. The following are my personal views on these and some other aspects of Java for numerical computing. While I expect to be involved in testing Java implementations for correctness and performance, I was not involved in the definition or implementation of Java, and so my descriptions of the current state of Java may be incomplete or out of date, but I hope they're not grossly wrong. * What Java is The next paragraphs discuss some features about the current definition of Java and attempt to explain their rationale. Java is NOT a machine-oriented language Among its other goals, C aims to promote machine-independent programming AND machine-dependent programming. Different language features cater to the different needs of these goals. Few rules on the size on integral and floating-point types, no rules on expression evaluation, conditional compilation, and ready access to internal representations of types, all act together to make it possible to write programs that are very specific to particular computers. Yet by avoiding these features and a few others it is possible to write relatively machine-independent programs, as long as every machine on which those programs are run conforms to the programmer's mental model of what's important. If the programmer thought to allow for 16, 32, and 64-bit ints, then the program may only be machine independent until compiled and run on a system with 36 or 48-bit ints. If the programmer thought to allow any of IEEE 754's varieties of floating-point arithmetic, then the program may only be machine independent until compiled and run on a DEC VAX, IBM 370, or Cray supercomputer. Creating and testing programs that really are independent enough to be run on all these machines is an arduous task. In contrast, promoting machine-dependent programming would have to be considered an anti-goal of Java; that's what the "100% Pure Java" campaign is all about: assisting software producers in avoiding dependencies on particular machines. Instead Java programs are intended to produce identical results on all supported machines. One important reason for that goal is to facilitate validation of claimed Java implementations: all floating-point results should agree to the last bit. The alternative is most conventional languages like Fortran and C, in which hardware faults and compiler bugs sometimes masquerade as "roundoff differences" and conversely, roundoff differences are sometimes misclassified as hardware faults and compiler bugs, particularly with aggressively optimizing compilers. Persons involved in intensive numerical work put up with these differences, and the costs associated with analyzing and correcting them, when their programs and problems demonstrate a high enough performance benefit. In contrast, most Java programming is likely to be somewhat less numerically intensive, and the tradeoff is the other way: the cost of dealing with ultimately insignificant numerical differences doesn't justify the performance improvement available by tolerating them. If there is to be but one Java expression evaluation model, how should it be chosen? The Java expression evaluation model is a simple one supported by most old and new computers used for floating-point computation: only single and double precision variables and registers exist, and floating-point instructions apply to only one or two input operands at a time. No extra- precise accumulators or fused three-operand instructions may be employed. That model is supported in hardware or may be efficiently emulated on all current popular RISC workstations and CISC PC's. It is true that x86-architecture PC's could sometimes provide faster and more accurate results by exploiting extended-precision accumulators, and PowerPC's could sometimes provide faster and more accurate results by exploiting fused multiply-add instructions, but the performance penalties for adhering to Java's model are not overwhelming and could be reduced further with a few modifications in the next revisions of those architectures. In contrast, based on past experiences of compilers' routine misapplication of extended-precision registers and fused operations, there is plenty of reason to doubt that the benefits of those architectures would be readily achieved if they were mandated by Java, even if there were no performance degradation on machines which had not provided hardware support for those features. Java doesn't allow VAX, IBM 370, or Cray floating-point formats; Java implementations on those systems must emulate IEEE 754 single and double precision. Java's insistence on a single expression evaluation model means that systems that are intended only to execute Java will not support other kinds of expression evaluation, but there are numerous other languages - namely almost every other language - available for that purpose. Functions are fully defined in Java Defining a function by writing a reference implementation in Java defines its floating-point behavior completely; implementations of that function that produce different results are defective to a greater or lesser extent. Java numerical functions intended to be part of a portable Java implementation are best defined by such reference implementations. That includes the class math functions, although they may not yet be so defined, and so are not a good example; consider instead a BLAS dot product. If the definition of Java ddot were written in Java then all implementations of Java ddot would produce identical results. The implementation may differ, but the results must be identical. In contrast, another dot product function nddot might be defined to produce a native dot product "sort of like ddot" but perhaps faster or more accurate or both. Because it's not defined as a Java program, nor defined as a mathematical abstraction like a correctly-rounded dot product, its exact definition is left to the good taste of the implementer - who may follow standard industry practice by denying the suitability of his implementation for any particular purpose while advertising its speed or accuracy derived by exploiting characteristics of particular hardware through a native implementation. Your nddot and mine may have the same name, and work sort of alike on bland data, but may exhibit strikingly different characteristics when challenged. This should not happen with programs defined by a Java implementation - that with a looser language definition, they COULD run faster or more accurately on SOME machines, is of no help on ALL machines. Similarly there will be implementations of languages that can't be called Java because they are tuned to run faster on a particular machine - and maybe more or less accurately, though history is not encouraging for the former. So call them Fava, Kava, or Lava as languages "sort of like Java" with the exact definition left to the good taste of the implementer. Probably there will be Java implementations that can be converted to Fava, Kava, or Lava by a compile-time option. For most programs these options will produce minor performance enhancements at best. * What Java needs The next few paragraphs describe some extensions to Java that would make it a better language for scientific computing. For all I know, some of these may be planned for future releases. Operator extension to user-defined types Java's definers wisely defined only a few numerical types as primitive in the language, and excluded operator overloading, a technique available in some languages that can be used to redefine the meaning of integer addition, for instance. I sympathize with that exclusion. Not so wisely, though, there is no operator notation extension to cover necessary user-defined types, such as complex, interval, or extended precision, not to mention complex extended intervals. Thus adding numerical types to Java by class definitions is either unduly burdensome to users, because every operator becomes a function invocation, or programs require a source code preprocessor of the style popular in Fortran circles twenty years ago - with the result that the code executed by the interpreter or examined by a debugger does not resemble the source code used by the programmer. IEEE 754 Exceptions Java recognizes certain exceptions such as integer overflow, but doesn't recognize the five IEEE 754 exceptions. These are essential to building robust fast programs. The minimum useful support is to detect specified exceptions when they arise in basic blocks of code and take alternate action if they do. By not specifying how much of the protected block is executed when an exception is detected, the definition would permit implementations to use flags or traps and to optimize within blocks fairly freely. There would be discernible differences in implementations that examined side effects produced by basic blocks whose partial execution was interrupted by an exception, but such programs could be deemed illegal Java. Unmentioned exceptions would produce IEEE 754 nonstop defaults as at present. Handling exceptions arising in external functions would require more infrastructure since the external functions might be separately compiled and thus would have to be careful about preserving flags or traps. Exception handling that protects only basic blocks is quite a bit less than IEEE 754 requires and recommends, but it should suffice for many applications. Undefined areas If the elementary transcendental functions in class math do not have a published reference implementation yet, then their implementation currently depends on good taste. It would be better to have a reference implementation such as a translation of fdlibm. In some ways a correctly-rounded reference implementation would be even better, but such an implementation based only on high-precision software arithmetic would be very slow, and one based on large tables would be unsuitable for the embedded applications for which Java was first designed; these points might be overlooked if good public implementations of correctly-rounded transcendental functions were available, but that has not happened yet. Java conversions from binary floating-point to decimal string representations are intended to be correctly rounded but are somewhat limited in releases so far. Correctly-rounded base conversion is an important aspect of portable identical results. *** Interval arithmetic Interval arithmetic is a method to replace uncertain floating-point results with intervals guaranteed to contain the correct results. When it can be successfully applied, it thus produces better results than most floating- point computations usually have, because they are guaranteed. Although there have been many successes, interval arithmetic is still difficult to apply successfully, for a variety of reasons. So interval arithmetic should be available as a java class (with operator extensions as mentioned above) but it is far from being a substitute for "point methods," as interval enthusiasts refer to ordinary floating-point arithmetic. Most Java applications at present are supposed, rightly or wrongly, to be either obviously right enough or obviously wrong. As they get more complicated numerically, people will realize that while getting identical results on all machines is an important benefit of Java programming, if it can't be determined whether they are identical CORRECT results, the benefit is of little value. % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail13.digital.com by us2rmc.zko.dec.com (5.65/rmc-22feb94) id AA15907; Wed, 5 Feb 97 01:35:17 -0500 % Received: from netra.validgh.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id BAA03845; Wed, 5 Feb 1997 01:24:28 -0500 (EST) % Received: from validgh.com by netra.validgh.com (SMI-8.6/SMI-SVR4) id VAA02035; Tue, 4 Feb 1997 21:48:54 -0800 % Received: by validgh.com (4.1/SMI-4.1) id AA01267; Tue, 4 Feb 97 21:46:39 PST % Received: by validgh.com (4.1/SMI-4.1) id AA01156; Tue, 4 Feb 97 21:36:10 PST % Date: Tue, 4 Feb 97 21:36:10 PST % From: [email protected] (David G. Hough at validgh) % Message-Id: <[email protected]> % To: [email protected] % Subject: Comments on Java Numerics % Cc: [email protected], [email protected] % Sender: [email protected] % Precedence: bulk % Reply-To: [email protected] (David G. Hough at validgh)
210.13	Bill Joy's comments on Hough's note	CAIRN::HARRIS	Kevin Harris, dtn 381-2039	`Thu Feb 20 1997 14:14`	162
	From: US2RMC::"[email protected]" "Bill Joy" 5-FEB-1997 01:53:24.64 To: "David G. Hough at validgh" <[email protected]> CC: [email protected], [email protected], [email protected] Subj: Re: Comments on Java Numerics David G. Hough at validgh wrote: > > Java doesn't allow VAX, IBM 370, or Cray floating-point formats; Java > implementations on those systems must emulate IEEE 754 single and double > precision. Java's insistence on a single expression evaluation model means > that systems that are intended only to execute Java will not support other > kinds of expression evaluation, but there are numerous other languages - > namely almost every other language - available for that purpose. > > > *** What Java needs > > The next few paragraphs describe some extensions to Java that would make > it a better language for scientific computing. For all I know, some of these > may be planned for future releases. > > Operator extension to user-defined types > > Java's definers wisely defined only a few numerical types as primitive in > the language, and excluded operator overloading, a technique available in some > languages that can be used to redefine the meaning of integer addition, for > instance. I sympathize with that exclusion. Not so wisely, though, there is > no operator notation extension to cover necessary user-defined types, such as > complex, interval, or extended precision, not to mention complex extended > intervals. Thus adding numerical types to Java by class definitions is > either unduly burdensome to users, because every operator becomes a function > invocation, or programs require a source code preprocessor of the style > popular in Fortran circles twenty years ago - with the result that the code > executed by the interpreter or examined by a debugger does not resemble the > source code used by the programmer. We have considered whether to allow these extended numeric types to be defined and hooked to infix operators, without fully going to operator overloading. For example, a class could declare that it implemented a certain magic interface that hooked it to the operators. It would make sense to consider a facility like this while considering parameterized types, which seem to be required to support naive versions of this that I have looked at. > IEEE 754 Exceptions > > Java recognizes certain exceptions such as integer overflow, but doesn't > recognize the five IEEE 754 exceptions. These are essential to building > robust fast programs. The minimum useful support is to detect specified > exceptions when they arise in basic blocks of code and take alternate action > if they do. By not specifying how much of the protected block is executed > when an exception is detected, the definition would permit implementations to > use flags or traps and to optimize within blocks fairly freely. There would > be discernible differences in implementations that examined side effects > produced by basic blocks whose partial execution was interrupted by an > exception, but such programs could be deemed illegal Java. > > Unmentioned exceptions would produce IEEE 754 nonstop defaults as at > present. Handling exceptions arising in external functions would require > more infrastructure since the external functions might be separately compiled > and thus would have to be careful about preserving flags or traps. > > Exception handling that protects only basic blocks is quite a bit less > than IEEE 754 requires and recommends, but it should suffice for many > applications. I would support exception handling, provided it was "well bracketed", in a statement like "try", i.e. try enabling FloatingPointOverflow { // code where overflow enabled } catch { ... } where you would be required to catch the exceptions you enable, and they would be enabled only in the code that is marked as enabled, e.g. not in methods called by this try statement. > Undefined areas > > If the elementary transcendental functions in class math do not have a > published reference implementation yet, then their implementation currently > depends on good taste. It would be better to have a reference implementation > such as a translation of fdlibm. In some ways a correctly-rounded reference > implementation would be even better, but such an implementation based only on > high-precision software arithmetic would be very slow, and one based on large > tables would be unsuitable for the embedded applications for which Java was > first designed; these points might be overlooked if good public > implementations of correctly-rounded transcendental functions were available, > but that has not happened yet. Guy looked closely at this; we decided not to do the definition that required huge tables, not only because the tables were very large but also because the performance is unpredictable... They are defined with reference to a standard C implementation (the spec gives the exact reference) whose source is widely available. We expect that fully accurate versions would be provided in another java package rather than being required in every implementation by being part of java.lang. > > Java conversions from binary floating-point to decimal string > representations are intended to be correctly rounded but are somewhat limited > in releases so far. Correctly-rounded base conversion is an important > aspect of portable identical results. I asked Richard Tuck (in 95) to adapt the exact input and output routines which had previously been implemented, e.g. in Lisp. I believe the current state is that the specification is of these routines, but whether they are released yet or not I do not know. Guy is the lead on these issues among the three of us. I hope he weighs in more, just thought I'd pass this early stuff along. Thanks for the careful explanation of the issues as you see them. What we wanted with Java is that you could write a numeric program and send it to someone else after testing it and know it would behave, for them, the same way it behaved for you. Otherwise there is no way to ever finish "testing" a program. The ability to write once and test once and have confidence everywhere is the KEY idea of Java... Regards, Bill Joy % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail13.digital.com by us2rmc.zko.dec.com (5.65/rmc-22feb94) id AA16168; Wed, 5 Feb 97 01:43:39 -0500 % Received: from netra.validgh.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id BAA03542; Wed, 5 Feb 1997 01:38:34 -0500 (EST) % Received: from validgh.com by netra.validgh.com (SMI-8.6/SMI-SVR4) id VAA02165; Tue, 4 Feb 1997 21:58:39 -0800 % Received: by validgh.com (4.1/SMI-4.1) id AA01414; Tue, 4 Feb 97 21:58:06 PST % Received: from netra.validgh.com (netra32) by validgh.com (4.1/SMI-4.1) id AA01408; Tue, 4 Feb 97 21:58:01 PST % Received: from data.zgsw.COM by netra.validgh.com (SMI-8.6/SMI-SVR4) id VAA02153; Tue, 4 Feb 1997 21:57:50 -0800 % Received: from iw-asw.zgsw.com by data.zgsw.COM (SMI-8.6/SMI-SVR4) id WAA12649; Tue, 4 Feb 1997 22:55:49 -0700 % Received: from pc-red by iw-asw.zgsw.com (SMI-8.6/SMI-SVR4) id WAA27011; Tue, 4 Feb 1997 22:55:05 -0700 % Message-Id: <[email protected]> % Date: Tue, 04 Feb 1997 22:52:41 -0700 % From: Bill Joy <[email protected]> % Organization: sun microsystems % X-Mailer: Mozilla 3.01 (WinNT; I) % Mime-Version: 1.0 % To: "David G. Hough at validgh" <[email protected]> % Cc: [email protected], [email protected], [email protected] % Subject: Re: Comments on Java Numerics % References: <[email protected]> % Content-Type: text/plain; charset=us-ascii % Content-Transfer-Encoding: 7bit % Sender: [email protected] % Precedence: bulk % Reply-To: Bill Joy <[email protected]>
210.14	Emphasis on portability	CAIRN::HARRIS	Kevin Harris, dtn 381-2039	`Thu Feb 20 1997 14:15`	41
	From: US2RMC::"[email protected]" "David G. Hough at validgh" 5-FEB-1997 02:00:31.35 To: [email protected] CC: [email protected], [email protected], [email protected] Subj: Re: Comments on Java Numerics > What we wanted with Java is that you could write a numeric program > and send it to someone else after testing it and know it would behave, > for them, the same way it behaved for you. Otherwise there is no way > to ever finish "testing" a program. The ability to write once and test > once > and have confidence everywhere is the KEY idea of Java... And the slogan should not be just "write once run anywhere" but "Write once, TEST ONCE, run anywhere" This corresponds to the notion (advanced about operating systems and other complex systems) that if the interfaces are sufficiently well defined, then you can freely change the implementations underneath the interfaces without necessarily having to retest the whole system to determine if your changes affect some should-be unrelated component elsewhere. It's a noble vision, even if somewhat distant from most current practice, and extremely difficult to achieve when the interfaces themselves are changing rapidly in an immature industry. % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail13.digital.com by us2rmc.zko.dec.com (5.65/rmc-22feb94) id AA16484; Wed, 5 Feb 97 01:53:02 -0500 % Received: from netra.validgh.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id BAA00316; Wed, 5 Feb 1997 01:46:58 -0500 (EST) % Received: from validgh.com by netra.validgh.com (SMI-8.6/SMI-SVR4) id WAA02320; Tue, 4 Feb 1997 22:10:25 -0800 % Received: by validgh.com (4.1/SMI-4.1) id AA01512; Tue, 4 Feb 97 22:09:42 PST % Received: by validgh.com (4.1/SMI-4.1) id AA01497; Tue, 4 Feb 97 22:09:23 PST % Date: Tue, 4 Feb 97 22:09:23 PST % From: [email protected] (David G. Hough at validgh) % Message-Id: <[email protected]> % To: [email protected] % Subject: Re: Comments on Java Numerics % Cc: [email protected], [email protected], [email protected] % Sender: [email protected] % Precedence: bulk % Reply-To: [email protected] (David G. Hough at validgh)
210.15	Coonen on Hough's comments	CAIRN::HARRIS	Kevin Harris, dtn 381-2039	`Thu Feb 20 1997 14:16`	192
	From: US2RMC::"[email protected]" "Jerome Coonen" 13-FEB-1997 13:55:58.42 To: [email protected], [email protected], [email protected], [email protected] CC: [email protected], [email protected], [email protected], [email protected], [email protected] Subj: Java Numerics Dear Colleagues, This note continues the discussion of the past few weeks regarding numerics in Java. Because David Hough's "Comments on Java Numerics" of 2/4/97 offered useful suggestions and cast the context of the discussion in yet another light, this note is organized loosely around Hough's comments. Readers may wish to know that David and I had a chance to discuss these and other issues in person on the fourth. IEEE 754 Exceptions We agree that some testing mechanism should be provided. Bill Joy responded to Hough's comments with support for "well bracketed" exception handling in the form of try blocks: >> try enabling FloatingPointOverflow { >> // code where overflow enabled >> } catch { >> ... >> } The suggestion is that, in the event the exception arose, an unspecified amount of the try block would be excuted, but the catch block's execution would be guaranteed. Hough points out >> There would be discernible differences in implementations that >> examined side effects produced by basic blocks whose partial execution >> was interrupted by an exception, but such programs could be deemed >> illegal Java. While good programming practice would dictate against dependence on the results of a partially executed block, results may differ, whether legally or not. Might this not lead to exactly the kind of bit-checking between platforms Java's designers wish to avoid? On a smaller scale, Bill Joy proposes that the exceptions be >> enabled only in the code that is marked as enabled, e.g. not in the >> methods called by this try statement. This would seem to incur a high implementation cost because of the need to isolate the flags (static sticky bits, or possibly static trap enable bits, on most current processors) across calls. It also leads one to wonder whether the programmer who wrote a statement like z = x * exp(y); would care whether an overflow arose in the exponential (masked by Bill Joy's scheme) or in the product? Operator Extension to User-defined Types As I understand Hough's proposal, he would have operators like "+" and "" apply to like pairs of user-defined types, such as complex or interval, but the operators would not support indiscriminate mixing of different types. Programmers would use explicit casts to mix types. Although this is the first mechanism from within the Java community that would permit the use of extended evaluation, it would force the casting of every float or double argument in a statement: extended86 t = 0.0; for (i = 0; i < N; i++) t += (extended86) x[i] (extended86) y[i]; Presumably, there would be "reference" definitions of all popular types: extended86, float_complex, double_complex, float_interval, double_interval, etc. In this way results could be identical across all implementations that support the extensions. Java is NOT a Machine-oriented Language Hough compares Java and its reproducible results everywhere with C, whose code can be compiled to run on virtually anything. In the context of numerical programs he points out that >> Creating and testing [C] programs that really are independent enough to >> run on [DEC VAX, IBM 370, Cray supercomputer, and anything conforming >> to IEEE 754] is an arduous task. Hough leaps from the chaos of C's supporting every conceivable floating point arithmetic to the conclusion that reproducibility is NECESSARY in order to guarantee portability. This unsupported reasoning is a basis for my dispute about Java's numerical design. Java's designers made a wise choice by requiring IEEE 754 conformance on all Java platforms. Among other things, the standard nailed down float and double formats and specified strict rounding rules for every floating point operation. But the standard allowed some flexibility in implementation, especially in its recommendation that implementations support a modest amount of extended range and precision for intermediate calculations. Now, extended evaluation has been scorned as incompatible with lesser systems, and its one purveyor, Intel, has been asked to add as a feature the ability to disable any extended precision and range on future implementations of the x86 architecture. Nowhere in the larger discussion has there been any evidence that simple adherence to IEEE 754 is insufficient to achieve a useful level of portability. Instead there is the truism that if everyone can be made to agree, no one can disagree. And then extended accumulation is disparaged as * dangerous in those calculations requiring exactly double precision, * poorly implemented on some systems, and consequently unreliable, and * of little value to purveyors of portable programs, because it's not available everywhere. I have advocated adoption of the expression evaluation techniques recommended for C9X. They address the first two bullet items directly (where so much harm has been done at the whims of compiler implementors). Then there is the matter of portability across extended-based and double-based architectures. One company, at least, has made the transition from extended to double evaluation. Apple Computer has migrated the Macintosh from the Motorola 68K to the PowerPC. Extended evaluation was a part of the Standard Apple Numeric Environment (SANE) dating back to the humble Apple II. So faithful were Apple's implementations that financial, scientific, and spreadsheet developers could port their numerical code -- in assembly language! -- effortlessly from the Apple II to the Macintosh. Although developers winced when Apple dropped extended from SANE for the PowerPC, there has been no alarm regarding the dangers of extended. This debate needs to be joined by members of the broader numerical community. Just how onerous is the prospect of porting LAPACK or the IMSL libraries to a broad family of architectures supporting IEEE 754? The performance implications of the current Java specification drive the argument to have Java's designers accommodate more than one IEEE 754 architecture. According to David Hough, an expert in numerical performance, >> the performance penalties for adhering to Java's model are not >> overwhelming and could be reduced further with a few modifications >> in the next revisions of those architectures. The inner product example of my original note showed that memory traffic nearly doubled for compiled x86 code forced to adhere to Java's model. Given that this penalty is suffered by users whose processors dominate the market by orders of magnitude, one might expect this to be of more than "not overwhelming" concern. Other examples involve elementary functions, several of which are provided at high accuracy and speed on x86 machines. Sometimes performance arguments are expressed relative to the "high-end market," where RISC cpus rather than CISC x86s currently dominate. On the one hand it's natural to expect high-end users not to be overly concerned with problems on other users' processors; on further inspection, however, it turns out that the most performance-hungry users in the elite workstation market are interested in FORTRAN, not C or Java. This does not lead to compelling arguments about Java across a breadth of networked platforms. System designs have always involved a balance of speed and accuracy. Although historically some painful decisions have been made in the name of speed, Java's designers have reached the other extreme -- and not even in the name of accuracy, only sameness at all costs. As Java finds wider numerical use, the pressure for higher performance -- without sacrificing a bit of IEEE 754 conformance -- will rise. Implementors wishing to make a sale, or users who want to get their work done, will be forced to decide whether one arbitrary "reference" version of an elementary function or a LINPACK BLAS serves their needs best. The decision about what is truly "100% pure" Java may become clouded by the legitimate demands of numerical users and by mathematical arguments that fast, accurate libraries on top of 100% pure IEEE 754 arithmetic lead to a more desirable mix of performance, accuracy, and portability. -Jerome Coonen % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail13.digital.com by us2rmc.zko.dec.com (5.65/rmc-22feb94) id AA29691; Thu, 13 Feb 97 13:41:05 -0500 % Received: from netra.validgh.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id NAA13781; Thu, 13 Feb 1997 13:34:46 -0500 (EST) % Received: from validgh.com by netra.validgh.com (SMI-8.6/SMI-SVR4) id KAA23549; Thu, 13 Feb 1997 10:03:53 -0800 % Received: by validgh.com (4.1/SMI-4.1) id AA06006; Thu, 13 Feb 97 09:58:51 PST % Received: from netra.validgh.com (netra32) by validgh.com (4.1/SMI-4.1) id AA06000; Thu, 13 Feb 97 09:58:47 PST % Received: from terminator.be.com by netra.validgh.com (SMI-8.6/SMI-SVR4) id JAA23501; Thu, 13 Feb 1997 09:58:43 -0800 % Received: from be.be.com ([email protected] [207.113.215.1]) by terminator.be.com (8.6.12/8.6.12) with SMTP id JAA06060; Thu, 13 Feb 1997 09:57:13 -0800 % From: Jerome Coonen <[email protected]> % X-Mailer: SCO System V Mail (version 3.2) % To: [email protected], [email protected], [email protected], [email protected] % Subject: Java Numerics % Cc: [email protected], [email protected], [email protected], [email protected], [email protected] % Date: Thu, 13 Feb 97 9:57:06 PST % Message-Id: <[email protected]> % Sender: [email protected] % Precedence: bulk % Reply-To: Jerome Coonen <[email protected]>
210.16	Guy Steele's comments	CAIRN::HARRIS	Kevin Harris, dtn 381-2039	`Thu Feb 20 1997 14:17`	146
	From: US2RMC::"[email protected]" "Guy Steele - Sun Microsystems Labs" 13-FEB-1997 15:20:59.10 To: [email protected], [email protected], [email protected], [email protected], [email protected] CC: [email protected], [email protected], [email protected], [email protected], [email protected] Subj: Re: Java Numerics From [email protected] Thu Feb 13 13:02:35 1997 From: Jerome Coonen <[email protected]> ... Thanks for the commentary on Hough's remarks. IEEE 754 Exceptions We agree that some testing mechanism should be provided. Bill Joy responded to Hough's comments with support for "well bracketed" exception handling in the form of try blocks: >> try enabling FloatingPointOverflow { >> // code where overflow enabled >> } catch { >> ... >> } There are, of course, other linguistic possibilities that could be explored. For example, a facility could be provided in expression form rather than, or in addition to, statement form, which might be less unwieldy for handling small regions of text. An example off the top of my head: x = (y/z ifzerodivide 1.0); We should also not overlook the possibility of providing a way to deliver overflowed and underflowed results to a trap handler. The suggestion is that, in the event the exception arose, an unspecified amount of the try block would be excuted, but the catch block's execution would be guaranteed. Hough points out >> There would be discernible differences in implementations that >> examined side effects produced by basic blocks whose partial execution >> was interrupted by an exception, but such programs could be deemed >> illegal Java. While good programming practice would dictate against dependence on the results of a partially executed block, results may differ, whether legally or not. Might this not lead to exactly the kind of bit-checking between platforms Java's designers wish to avoid? Indeed, and I would argue strongly against such uncertainty within Java. Such uncertainty is sometimes desirable at the hardware level, principally to allow the possibility of exploiting parallelism (such as pipelining)! But it is possible to exploit such techniques at the low level without having to reflect them at the high level. The DEC Alpha architecture provides one example of how this can be done. On a smaller scale, Bill Joy proposes that the exceptions be >> enabled only in the code that is marked as enabled, e.g. not in the >> methods called by this try statement. This would seem to incur a high implementation cost because of the need to isolate the flags (static sticky bits, or possibly static trap enable bits, on most current processors) across calls. It also leads one to wonder whether the programmer who wrote a statement like z = x * exp(y); would care whether an overflow arose in the exponential (masked by Bill Joy's scheme) or in the product? We should further distinguish between "arose in the source of the code that implements the exponential" and "ought to be indicated to the caller as part of the result of the exponential". Ordinarily, for reasons of abstraction, I would argue that a programming language ought to be able to support delivering flag results to the caller in a manner that is under programmer control, while making it easy to hide details of implementation from the caller. (If other behaviors that violate such abstraction are nevertheless useful to the programmer, then I am all for providing those behaviors also---but under programmer control, not at the implementation-dependent whim of the compiler.) By abstraction I mean the facility to encapsulate a compound behavior so as to make it appear to be primitive. Procedures are one such facility. So I would be inclined to define the semantics of a procedure call in such a way that any IEEE flags it returns are merged (OR'd) with the flag state as of before the procedure call, and this merged state is what is returned to the caller for use in its further execution. In this way a user-defined exp procedure would behave in the same manner with respect to the flags as a hardware-defined sqrt instruction. I note that many numerical library routines I have seen use such roundabout idioms as return 1/0; /* overflow / usually with a comment such as the one shown, to return +Infinity and also set the overflow flag. This may or may not be the fastest way to accomplish this dual action at the machine instruction level, but the fact that such a comment is usually included indicates that the idiom is, by itself, linguistically deficient. It might well be clearer to be able to write something like return Infinity with overflow; and leave it to the compiler to decide the most effective sequence of machine instructions to produce this effect. Similarly, return 0.0 with underflow; may be more pleasant in a number of ways than double tiny = 1e-300; ... return tinytiny; /* underflow */ I hope that part of tomorrow's discussion can be devoted to the questions of (a) what coders of numerical software need to be able to say in expressing computations, and (b) what are clear and effective ways of saying those things. A question of special interest for me is whether traps, especially traps that "stop on a dime", are important for the expression of algorithms as such or whether their principal use is in suspending a computation for inspection (debugging). --Guy % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail13.digital.com by us2rmc.zko.dec.com (5.65/rmc-22feb94) id AA07213; Thu, 13 Feb 97 15:05:08 -0500 % Received: from netra.validgh.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id OAA00811; Thu, 13 Feb 1997 14:56:00 -0500 (EST) % Received: from validgh.com by netra.validgh.com (SMI-8.6/SMI-SVR4) id LAA24206; Thu, 13 Feb 1997 11:18:27 -0800 % Received: by validgh.com (4.1/SMI-4.1) id AA06244; Thu, 13 Feb 97 11:11:44 PST % Received: from netra.validgh.com (netra32) by validgh.com (4.1/SMI-4.1) id AA06238; Thu, 13 Feb 97 11:11:35 PST % Received: from mercury.Sun.COM by netra.validgh.com (SMI-8.6/SMI-SVR4) id LAA24142; Thu, 13 Feb 1997 11:11:17 -0800 % Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA27724; Thu, 13 Feb 1997 11:06:10 -0800 % Received: from suneast.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3) id OAA23810; Thu, 13 Feb 1997 14:05:32 -0500 % Received: from livia.East.Sun.COM by suneast.East.Sun.COM (SMI-8.6/SMI-SVR4) id OAA17050; Thu, 13 Feb 1997 14:05:29 -0500 % Received: by livia.East.Sun.COM (SMI-8.6/SMI-SVR4) id NAA05912; Thu, 13 Feb 1997 13:59:33 -0500 % Date: Thu, 13 Feb 1997 13:59:33 -0500 % From: [email protected] (Guy Steele - Sun Microsystems Labs) % Message-Id: <[email protected]> % To: [email protected], [email protected], [email protected], [email protected], [email protected] % Subject: Re: Java Numerics % Cc: [email protected], [email protected], [email protected], [email protected], [email protected] % X-Sun-Charset: US-ASCII % Sender: [email protected] % Precedence: bulk % Reply-To: [email protected] (Guy Steele - Sun Microsystems Labs)
210.17	and a correction	CAIRN::HARRIS	Kevin Harris, dtn 381-2039	`Thu Feb 20 1997 14:17`	48
	From: US2RMC::"[email protected]" "Guy Steele - Sun Microsystems Labs" 13-FEB-1997 15:41:15.20 To: [email protected], [email protected], [email protected], [email protected], [email protected] CC: [email protected], [email protected], [email protected], [email protected], [email protected] Subj: Re: Java Numerics I just realized that, in my previous message, I should have distinguished between return 1/0; the results of which are return Infinity with zerodivide; and double huge = 1e300; ... return huge*huge; the results of which are return Infinity with overflow; --Guy % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Date: Thu, 13 Feb 1997 14:35:43 -0500 % From: [email protected] (Guy Steele - Sun Microsystems Labs) % Message-Id: <[email protected]> % To: [email protected], [email protected], [email protected], [email protected], [email protected] % Subject: Re: Java Numerics % Cc: [email protected], [email protected], [email protected], [email protected], [email protected] % Sender: [email protected] % Precedence: bulk % Reply-To: [email protected] (Guy Steele - Sun Microsystems Labs)
210.18	More discussion of exceptions	CAIRN::HARRIS	Kevin Harris, dtn 381-2039	`Thu Feb 20 1997 14:18`	266
	From: US2RMC::"[email protected]" "bill joy" 13-FEB-1997 15:53:09.84 To: Jerome Coonen <[email protected]> CC: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected] Subj: Re: Java Numerics > IEEE 754 Exceptions > > We agree that some testing mechanism should be provided. Bill Joy responded > to Hough's comments with support for "well bracketed" exception handling in > the form of try blocks: > > >> try enabling FloatingPointOverflow { > >> // code where overflow enabled > >> } catch { > >> ... > >> } > ALTERNATIVE PROPOSAL: I have an alternative proposal, which doesn't involve language changes: provide operations mul, add, etc. defined as double mul(double a, double b) throws FloatingPointOverflow, FloatingPointUnderflow; double add(double a, double b) throws FloatingPointOverflow, FloatingPointUnderflow; Add such methods to a library in a standard place, and let code which wishes to have an exception on these operations use these routines. JIT compilers can optimize these routines to be inline. This is trivial to implement, and can be optimized by JIT's. COMMENTS ON THE PREVIOUS PROPOSAL: The syntax here needs some work... I would prefer to name the exceptions only once i.e. as in try { ... } catch enabled (FloatingPointOverflow f) { ... } but this has the problem that you have to read the stuff at the bottom to see what is being enabled. The alternative try enabling FloatingPointOverflow { ... } catch (FloatingPointOverflow f) { ... } seems verbose. > The suggestion is that, in the event the exception arose, an unspecified amount > of the try block would be executed, but the catch block's execution would be > guaranteed. No, the proposal is that a SPECIFIED amount of the try block would be executed, namely the code up to the first exception. Java guarantees APPARENT evaluation order, so there is no indeterminism here, and no observable differences. >... Hough points out > > >> There would be discernible differences in implementations that > >> examined side effects produced by basic blocks whose partial execution > >> was interrupted by an exception, but such programs could be deemed > >> illegal Java. No, this is not what is proposed since Java guarantees APPARENT evaluation order. > While good programming practice would dictate against dependence on the > results of a partially executed block, results may differ, whether legally > or not. Might this not lead to exactly the kind of bit-checking between > platforms Java's designers wish to avoid? It would, and that is why it is not what I am proposing. > On a smaller scale, Bill Joy proposes that the exceptions be > > >> enabled only in the code that is marked as enabled, e.g. not in the > >> methods called by this try statement. > > This would seem to incur a high implementation cost because of the need > to isolate the flags (static sticky bits, or possibly static trap enable > bits, on most current processors) across calls. It also leads one to > wonder whether the programmer who wrote a statement like > z = x * exp(y); > > would care whether an overflow arose in the exponential (masked by Bill > Joy's scheme) or in the product? The person who wrote the exp routine wrote it relative to a certain way of processing overflow. It is completely inappropriate in a language like Java to have the IEEE flags be modified by the caller in a way that would invalidate this callee's expectations, and thus making the results of a method such as exp unpredictable. > > Operator Extension to User-defined Types > > As I understand Hough's proposal, he would have operators like > "+" and "" apply to like pairs of user-defined types, such as complex or > interval, but the operators would not support indiscriminate mixing > of different types. Programmers would use explicit casts to mix types. > Although this is the first mechanism from within the Java community that > would permit the use of extended evaluation, it would force the casting > of every float or double argument in a statement: > > extended86 t = 0.0; > for (i = 0; i < N; i++) > t += (extended86) x[i] (extended86) y[i]; > > Presumably, there would be "reference" definitions of all popular types: > extended86, float_complex, double_complex, float_interval, double_interval, > etc. In this way results could be identical across all implementations > that support the extensions. This is not what I would propose. If we are to put these datatypes in infix notation, then their use must be convenient. I think we can tie coercions to the type hierarchy that these types obey, provided we can work these types into the (future parameterized) type hierarchy. > Java is NOT a Machine-oriented Language > > ... > > Nowhere in the larger discussion has there been any evidence that simple > adherence to IEEE 754 is insufficient to achieve a useful level of portability. If you want to do a language that varies the results it gets per platform, then you should do that language, but that is not Java. Java's point is that if you test once you get the same answer on other plaforms, up to determinism. This is a choice; we shouldn't (and won't) mix in the other style of answer. You can get the other style of answer (namely, "whatever") from many other languages. > > ... > This debate needs to be joined by members of the broader numerical > community. Just how onerous is the prospect of porting LAPACK or the > IMSL libraries to a broad family of architectures supporting IEEE 754? > There is too much numeric code being written to have each code checked by an expert who can make sure it will run on all IEEE 754 platforms and get the same answer. This just isn't practical. Java's alternative of writing the code once, under a more limited model, and getting it correct there seems the only way to get reproducible results from thousands or millions of different pieces of code. People who want to tie more closely to the hardware at hand, and take advantage of nooks and crannies to squeeze out performance have lots of other alternatives. > The performance implications of the current Java specification drive > the argument to have Java's designers accommodate more than one IEEE 754 > architecture. According to David Hough, an expert in numerical performance, > > >> the performance penalties for adhering to Java's model are not > >> overwhelming and could be reduced further with a few modifications > >> in the next revisions of those architectures. > > The inner product example of my original note showed that memory traffic > nearly doubled for compiled x86 code forced to adhere to Java's model. > Given that this penalty is suffered by users whose processors dominate > the market by orders of magnitude, one might expect this to be of more > than "not overwhelming" concern. Other examples involve elementary > functions, several of which are provided at high accuracy and speed on > x86 machines. As Guy's note pointed out, we welcome the addition, in the numeric library of "bit-accurate" versons of sin, cos, etc. These would, conceivably, run very fast on machines with extended (like the x86). They are not suitable for the standard (required) Java routines becauase they take egregious amounts of space and time on machines with only double precision hardware (a decision that has ALREADY been taken). Intel can add a rounding operation in the registers of the x86 in the future to help the performance of "Pure Java" floating point. As I mentioned before, I mentioned this issue to Intel engineers in 1995. We are not sacrificing "write once, run anywhere" for performance on Intel or indeed any other hardware. > Sometimes performance arguments are expressed relative to the "high-end > market," where RISC cpus rather than CISC x86s currently dominate. > On the one hand it's natural to expect high-end users not to be overly > concerned with problems on other users' processors; on further inspection, > however, it turns out that the most performance-hungry users in the elite > workstation market are interested in FORTRAN, not C or Java. This does > not lead to compelling arguments about Java across a breadth of networked > platforms. > > System designs have always involved a balance of speed and accuracy. > Although historically some painful decisions have been made in the > name of speed, Java's designers have reached the other extreme -- and > not even in the name of accuracy, only sameness at all costs. > > As Java finds wider numerical use, the pressure for higher performance -- > without sacrificing a bit of IEEE 754 conformance -- will rise. > Implementors wishing to make a sale, or users who want to get their > work done, will be forced to decide whether one arbitrary "reference" > version of an elementary function or a LINPACK BLAS serves their > needs best. The decision about what is truly "100% pure" Java may > become clouded by the legitimate demands of numerical users and by > mathematical arguments that fast, accurate libraries on top of > 100% pure IEEE 754 arithmetic lead to a more desirable mix of > performance, accuracy, and portability. I think a more constructive approach than the above would be to put together a group of people interested in "high-performance numerics in Java" and to come up with some proposals which can be adopted by all the chip manufacturers: Intel, MIPS, SPARC, PowerPc, ARM, etc. to deal with reproducible results across the set of processors. So, for example, the Intel folks could make rounding to 64-bit faster (it may be already on Merced, depending on the details of its floating-point design), the MIPS, SPARC and PowerPc folks could consider making bit-accurate elementary functions go faster, etc. The goal of this effort would be to move the performance of "write once, run everywhere" numerics upward. The raw performance is already heated by the SPECmark and similar benchmarks in languages like C and FORTRAN and doesn't need our help. > -Jerome Coonen % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail13.digital.com by us2rmc.zko.dec.com (5.65/rmc-22feb94) id AA10151; Thu, 13 Feb 97 15:36:49 -0500 % Received: from netra.validgh.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id PAA28016; Thu, 13 Feb 1997 15:28:43 -0500 (EST) % Received: from validgh.com by netra.validgh.com (SMI-8.6/SMI-SVR4) id LAA24620; Thu, 13 Feb 1997 11:59:25 -0800 % Received: by validgh.com (4.1/SMI-4.1) id AA06466; Thu, 13 Feb 97 11:58:58 PST % Received: from netra.validgh.com (netra32) by validgh.com (4.1/SMI-4.1) id AA06460; Thu, 13 Feb 97 11:58:54 PST % Received: from data.zgsw.COM by netra.validgh.com (SMI-8.6/SMI-SVR4) id LAA24607; Thu, 13 Feb 1997 11:58:48 -0800 % Received: from iw-asw.zgsw.com by data.zgsw.COM (SMI-8.6/SMI-SVR4) id MAA09661; Thu, 13 Feb 1997 12:56:38 -0700 % Received: from nt-300 by iw-asw.zgsw.com (SMI-8.6/SMI-SVR4) id MAA01395; Thu, 13 Feb 1997 12:55:35 -0700 % Message-Id: <[email protected]> % Date: Thu, 13 Feb 1997 12:51:15 -0700 % From: bill joy <[email protected]> % Organization: sun microsystems % X-Mailer: Mozilla 3.01Gold (WinNT; I) % Mime-Version: 1.0 % To: Jerome Coonen <[email protected]> % Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected] % Subject: Re: Java Numerics % References: <[email protected]> % Content-Type: text/plain; charset=us-ascii % Content-Transfer-Encoding: 7bit % Sender: [email protected] % Precedence: bulk % Reply-To: bill joy <[email protected]>
210.19	Mr. Interval again	CAIRN::HARRIS	Kevin Harris, dtn 381-2039	`Thu Feb 20 1997 14:19`	51
	From: US2RMC::"[email protected]" "MAIL-11 Daemon" 13-FEB-1997 16:56:09.08 To: [email protected], [email protected] CC: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected] Subj: Re: Java Numerics Here is my personal opinion on this topic. It would help in framing the discussion tomorrow to keep the intended Java consumers in mind. A reasonable case can be made for "sameness" at all cost, if Java users are dominated by people using embedded systems or other low-level (from a numerical perspective) devices. However, "sameness" is not as important as accuracy if (as appears to be happening) Java becomes adopted by users and developers of numerically intense software, or even if Java stations are used as "terminals" for large clusters on a network. At present, interval arithmetic is the only practical way to deal with accuracy information from all sources. The beauty of intervals is that "containment" is the one and only sense in which all interval implementations must be the "same". In an interval environment, developers of hardware and software are free to compete for speed and interval sharpness however they feel will best serve their customers. Rather than attempting to impose a meaningless "sameness" on all vendors (a Herculean task that seems doomed to fail), better to open the door to competition on both speed and accuracy, but in a way that will benefit users. Bill Walster % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail13.digital.com by us2rmc.zko.dec.com (5.65/rmc-22feb94) id AA15165; Thu, 13 Feb 97 16:43:02 -0500 % Received: from netra.validgh.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id QAA13818; Thu, 13 Feb 1997 16:35:37 -0500 (EST) % Received: from validgh.com by netra.validgh.com (SMI-8.6/SMI-SVR4) id NAA25325; Thu, 13 Feb 1997 13:01:16 -0800 % Received: by validgh.com (4.1/SMI-4.1) id AA06808; Thu, 13 Feb 97 12:55:08 PST % Received: from netra.validgh.com (netra32) by validgh.com (4.1/SMI-4.1) id AA06802; Thu, 13 Feb 97 12:55:00 PST % Received: from venus.Sun.COM by netra.validgh.com (SMI-8.6/SMI-SVR4) id MAA25274; Thu, 13 Feb 1997 12:54:37 -0800 % From: [email protected] % Received: from Eng.Sun.COM ([129.146.1.25]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA00875; Thu, 13 Feb 1997 12:54:15 -0800 % Received: from gww.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA05089; Thu, 13 Feb 1997 12:54:11 -0800 % Received: by gww.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA18563; Thu, 13 Feb 1997 12:55:55 -0800 % Date: Thu, 13 Feb 1997 12:55:55 -0800 % Message-Id: <[email protected]> % To: [email protected], [email protected] % Subject: Re: Java Numerics % Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected] % X-Sun-Charset: US-ASCII % Sender: [email protected] % Precedence: bulk % Reply-To: [email protected]
210.20	More Intervals	CAIRN::HARRIS	Kevin Harris, dtn 381-2039	`Thu Feb 20 1997 14:20`	58
	From: US2RMC::"[email protected]" "Keith Bierman QED" 13-FEB-1997 20:46:59.42 To: [email protected] CC: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected] Subj: Re: Java Numerics I must confess that since I'm in the middle of an ANSI meeting, and am behind in my email reading. >It would help in framing the discussion tomorrow to keep the intended Java Assuming the meeting hasn't happened yet >if Java users are dominated by people using embedded systems or other >low-level (from a numerical perspective) devices. However, "sameness" is not >as important as accuracy if (as appears to be happening) Java becomes adopted While there seem to be a bunch of people interesting in other uses, the core use of Java has been and should continue to be our focus, client/server network computing. It's what made this take off. Therefore sameness should be the requirement. Since clients may be small personal devices (that is embedded level), I feel that the core language should be essentially as it is now. IEEE and bit for bit compliance as a requirement. Other "java-like" languages may develop, and they may target other markets. There should be efforts to allow for interoperability perhaps. But don't get into the PL/1, Fortran, Cobol, et al. trap of trying to be all things to all people. A closely related "numerical java" which takes intervals as it's basis would, IMHO be a better thing to start with than tinkering with the C/S aka network java that is where the big money/explosive growth is. Now back to trying to get intervals into F2K .... % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail13.digital.com by us2rmc.zko.dec.com (5.65/rmc-22feb94) id AA26072; Thu, 13 Feb 97 20:13:16 -0500 % Received: from netra.validgh.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id UAA08738; Thu, 13 Feb 1997 20:08:11 -0500 (EST) % Received: from validgh.com by netra.validgh.com (SMI-8.6/SMI-SVR4) id QAA26840; Thu, 13 Feb 1997 16:39:40 -0800 % Received: by validgh.com (4.1/SMI-4.1) id AA07310; Thu, 13 Feb 97 16:38:25 PST % Received: from netra.validgh.com (netra32) by validgh.com (4.1/SMI-4.1) id AA07304; Thu, 13 Feb 97 16:38:20 PST % Received: from venus.Sun.COM by netra.validgh.com (SMI-8.6/SMI-SVR4) id QAA26830; Thu, 13 Feb 1997 16:38:17 -0800 % Received: from Eng.Sun.COM ([129.146.1.25]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id QAA26067; Thu, 13 Feb 1997 16:38:17 -0800 % Received: from chiba.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA04636; Thu, 13 Feb 1997 15:10:39 -0800 % Received: from chiba by chiba.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA07430; Thu, 13 Feb 1997 15:10:39 -0800 % Message-Id: <[email protected]> % To: [email protected] % Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected] % Subject: Re: Java Numerics % In-Reply-To: Your message of "Thu, 13 Feb 1997 12:55:55 PST." <[email protected]> % Date: Thu, 13 Feb 1997 15:10:39 -0800 % From: Keith Bierman QED <[email protected]> % Sender: [email protected] % Precedence: bulk % Reply-To: Keith Bierman QED <[email protected]>
210.21	More exceptions	CAIRN::HARRIS	Kevin Harris, dtn 381-2039	`Thu Feb 20 1997 14:20`	42
	From: US2RMC::"[email protected]" "Samuel A. Figueroa" 13-FEB-1997 22:25:48.30 To: [email protected], [email protected], [email protected], [email protected], [email protected] CC: [email protected], [email protected], [email protected], [email protected], [email protected] Subj: Re: Java Numerics Jerome Coonen writes (the first fragment is a quote from David Hough): > >> the performance penalties for adhering to Java's model are not > >> overwhelming and could be reduced further with a few modifications > >> in the next revisions of those architectures. >The inner product example of my original note showed that memory traffic >nearly doubled for compiled x86 code forced to adhere to Java's model. >Given that this penalty is suffered by users whose processors dominate >the market by orders of magnitude, one might expect this to be of more >than "not overwhelming" concern. Actually, the inner product example showed code that doesn't quite conform to Java's language specification in the case of underflow. (If underflow occurs [or more accurately, if the result is in the range of double precision denormals], simply storing the result to memory and reloading may lead to double rounding.) If underflow cannot be ruled out, then performance on a Pentium slows down by at least by a factor of ten for addition, subtraction, and multiplication. Sam Figueroa % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail13.digital.com by us2rmc.zko.dec.com (5.65/rmc-22feb94) id AA00535; Thu, 13 Feb 97 22:12:56 -0500 % Received: from netra.validgh.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id WAA28009; Thu, 13 Feb 1997 22:07:41 -0500 (EST) % Received: from validgh.com by netra.validgh.com (SMI-8.6/SMI-SVR4) id SAA27682; Thu, 13 Feb 1997 18:36:18 -0800 % Received: by validgh.com (4.1/SMI-4.1) id AA07695; Thu, 13 Feb 97 18:35:12 PST % Received: from netra.validgh.com (netra32) by validgh.com (4.1/SMI-4.1) id AA07689; Thu, 13 Feb 97 18:35:07 PST % Received: from slinky.cs.nyu.edu by netra.validgh.com (SMI-8.6/SMI-SVR4) id SAA27672; Thu, 13 Feb 1997 18:35:05 -0800 % Received: by slinky.cs.nyu.edu (SMI-8.6/1.20) id VAA01899; Thu, 13 Feb 1997 21:34:53 -0500 % Date: Thu, 13 Feb 1997 21:34:53 -0500 % From: [email protected] (Samuel A. Figueroa) % Message-Id: <[email protected]> % To: [email protected], [email protected], [email protected], [email protected], [email protected] % Subject: Re: Java Numerics % Cc: [email protected], [email protected], [email protected], [email protected], [email protected] % Sender: [email protected] % Precedence: bulk % Reply-To: [email protected] (Samuel A. Figueroa)
210.22	Overloading?	CAIRN::HARRIS	Kevin Harris, dtn 381-2039	`Thu Feb 20 1997 14:21`	54
	From: US2RMC::"[email protected]" "Samuel A. Figueroa" 13-FEB-1997 23:26:07.47 To: [email protected], [email protected] CC: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected] Subj: Re: Java Numerics Bill Joy writes: >ALTERNATIVE PROPOSAL: >I have an alternative proposal, which doesn't involve language changes: >provide operations mul, add, etc. defined as > double mul(double a, double b) throws FloatingPointOverflow, >FloatingPointUnderflow; > double add(double a, double b) throws FloatingPointOverflow, >FloatingPointUnderflow; >Add such methods to a library in a standard place, and let code which >wishes to have an exception on these operations use these routines. I am not a Java programmer, but in Ada, one could define multiple versions of such functions, with one version, for example, allowing you to specify the rounding mode for that one particular operation (most likely this would reduce performance significantly, but it might be exactly what somebody wants to do), and another version letting you tell the function, "Don't tell me if underflow occurred. I don't care about that, but do tell me if overflow occurs," or "If division by zero occurs, return the value x." Again, these versions would most likely reduce performance. Keith Bierman writes: >Other "java-like" languages may develop, and they may target other >markets. There should be efforts to allow for interoperability >perhaps. Perhaps we should redirect our efforts, then, to Limbo (a language from Bell Labs - see http://inferno.bell-labs.com/inferno), which I understand is already interoperable with Java, and allows more freedom for implementors in the area of floating-point arithmetic, though it is still IEEE-arithmetic based. Sam Figueroa % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail13.digital.com by us2rmc.zko.dec.com (5.65/rmc-22feb94) id AA02348; Thu, 13 Feb 97 23:07:43 -0500 % Received: from netra.validgh.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id XAA02791; Thu, 13 Feb 1997 23:00:36 -0500 (EST) % Received: from validgh.com by netra.validgh.com (SMI-8.6/SMI-SVR4) id TAA28134; Thu, 13 Feb 1997 19:32:16 -0800 % Received: by validgh.com (4.1/SMI-4.1) id AA07853; Thu, 13 Feb 97 19:31:20 PST % Received: from netra.validgh.com (netra32) by validgh.com (4.1/SMI-4.1) id AA07847; Thu, 13 Feb 97 19:31:16 PST % Received: from slinky.cs.nyu.edu by netra.validgh.com (SMI-8.6/SMI-SVR4) id TAA28124; Thu, 13 Feb 1997 19:31:13 -0800 % Received: by slinky.cs.nyu.edu (SMI-8.6/1.20) id WAA03109; Thu, 13 Feb 1997 22:31:15 -0500 % Date: Thu, 13 Feb 1997 22:31:15 -0500 % From: [email protected] (Samuel A. Figueroa) % Message-Id: <[email protected]> % To: [email protected], [email protected] % Subject: Re: Java Numerics % Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected] % Sender: [email protected] % Precedence: bulk % Reply-To: [email protected] (Samuel A. Figueroa)
210.23	decimal-float conversions, exceptions	CAIRN::HARRIS	Kevin Harris, dtn 381-2039	`Thu Feb 20 1997 14:22`	73
	From: US2RMC::"[email protected]" "Eric Grosse" 14-FEB-1997 12:07:22.48 To: [email protected] CC: Subj: Limbo (was: Java Numerics) Sam Figueroa writes: > Perhaps we should redirect our efforts, then, to Limbo (a language > from Bell Labs - see http://inferno.bell-labs.com/inferno) I've hesitated to jump into the discussion, because until I can deliver the complex type in the Inferno distribution, I hardly think the scientific computing community should take us seriously. (Interval arithmetic and more powerful arrays are almost as essential---and coming.) However, I would like to state two positions directly related to the current discussion. 1. Accurate binary/decimal conversion is absolutely essential to network computing, even if the heavy crunching is done on back-end servers in C or Fortran and only light-weight interactive work in the client. Inferno has had it from day one, based on David Gay's excellent work which we've made freely available. It puzzles me why Java has taken so long, but with Guy on the team surely it will happen. 2. We're all agreed that we want to mandate IEEE 754 format and deterministic operation sequences. Inferno and Java agree (in conflict with Coonen, I guess) that for the intended users of our languages the advantages of round-to-double in portability and lack of surprises outweigh possibly-better-average-accuracy on some machines. Thus we both propose ddot getting the same results everywhere, and nddot exploiting fused-multiply-add or whatever is available for better speed and accuracy. Where Java and Inferno differ is in treatment of over/underflow. Specifically, by mandating rounding-to-double but tolerating extended exponent range for intermediate expressions on Pentium, Inferno avoids the penalty in memory traffic that Coonen described. This means that, for computations that stay well in range, the same results are computed everywhere. Where not, Inferno's default of sending you to our nifty debugger on the first over/underflow at least warns you of the problem. I don't claim to have discovered the One True Answer; a lot of this is a matter of taste and balance. Inferno numerics behave the way I like, and Limbo itself is a sweet little language that you can get your mind around. If any of you are feeling adventurous and play around with the system, send me mail. The heavy commercial side doesn't care much about floating point yet, so we still have the flexibility to tweak details. Best wishes, Eric % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail2.digital.com by us2rmc.zko.dec.com (5.65/rmc-22feb94) id AA04998; Fri, 14 Feb 97 11:51:05 -0500 % Received: from netra.validgh.com by mail2.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA18179; Fri, 14 Feb 1997 08:35:23 -0800 % Received: from validgh.com by netra.validgh.com (SMI-8.6/SMI-SVR4) id HAA03260; Fri, 14 Feb 1997 07:59:39 -0800 % Received: by validgh.com (4.1/SMI-4.1) id AA10133; Fri, 14 Feb 97 07:58:17 PST % Received: from netra.validgh.com (netra32) by validgh.com (4.1/SMI-4.1) id AA10127; Fri, 14 Feb 97 07:58:12 PST % Received: from blue6.cs.bell-labs.com by netra.validgh.com (SMI-8.6/SMI-SVR4) id HAA03250; Fri, 14 Feb 1997 07:58:09 -0800 % Message-Id: <[email protected]> % Date: Fri, 14 Feb 1997 10:58:14 +0500 % From: Eric Grosse <[email protected]> % X-Url: http://cm.bell-labs.com/who/ehg/ % To: [email protected] % Subject: Limbo (was: Java Numerics) % Sender: [email protected] % Precedence: bulk % Reply-To: Eric Grosse <[email protected]>
210.24	Steele on conversions	CAIRN::HARRIS	Kevin Harris, dtn 381-2039	`Thu Feb 20 1997 14:23`	52
	From: US2RMC::"[email protected]" "Guy Steele - Sun Microsystems Labs" 17-FEB-1997 11:52:54.27 To: [email protected], [email protected] CC: [email protected] Subj: Re: Limbo (was: Java Numerics) From [email protected] Fri Feb 14 11:20:12 1997 ... However, I would like to state two positions directly related to the current discussion. 1. Accurate binary/decimal conversion is absolutely essential to network computing, even if the heavy crunching is done on back-end servers in C or Fortran and only light-weight interactive work in the client. Inferno has had it from day one, based on David Gay's excellent work which we've made freely available. It puzzles me why Java has taken so long, but with Guy on the team surely it will happen. Thanks for bringing this up! The Java language specification requires accurate binary/decimal conversion; any Java implementation that fails in this respect is incorrect. David Gay's work is indeed excellent. I consistently refer all inquiries on this subject to his report and code, which are available from netlib. --Guy % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail13.digital.com by us2rmc.zko.dec.com (5.65/rmc-22feb94) id AA12517; Mon, 17 Feb 97 11:37:23 -0500 % Received: from netra.validgh.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id LAA31114; Mon, 17 Feb 1997 11:29:35 -0500 (EST) % Received: from validgh.com by netra.validgh.com (SMI-8.6/SMI-SVR4) id HAA26901; Mon, 17 Feb 1997 07:57:55 -0800 % Received: by validgh.com (4.1/SMI-4.1) id AA17338; Mon, 17 Feb 97 07:52:59 PST % Received: from netra.validgh.com (netra32) by validgh.com (4.1/SMI-4.1) id AA17332; Mon, 17 Feb 97 07:52:54 PST % Received: from mercury.Sun.COM by netra.validgh.com (SMI-8.6/SMI-SVR4) id HAA26843; Mon, 17 Feb 1997 07:52:53 -0800 % Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA00018; Mon, 17 Feb 1997 07:52:54 -0800 % Received: from suneast.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3) id KAA12088; Mon, 17 Feb 1997 10:52:51 -0500 % Received: from orbit.East.Sun.COM by suneast.East.Sun.COM (SMI-8.6/SMI-SVR4) id KAA19579; Mon, 17 Feb 1997 10:52:51 -0500 % Received: by orbit.East.Sun.COM (SMI-8.6/SMI-SVR4) id KAA16580; Mon, 17 Feb 1997 10:52:43 -0500 % Date: Mon, 17 Feb 1997 10:52:43 -0500 % From: [email protected] (Guy Steele - Sun Microsystems Labs) % Message-Id: <[email protected]> % To: [email protected], [email protected] % Subject: Re: Limbo (was: Java Numerics) % Cc: [email protected] % X-Sun-Charset: US-ASCII % Sender: [email protected] % Precedence: bulk % Reply-To: [email protected] (Guy Steele - Sun Microsystems Labs)
210.25	Solaris conversions	CAIRN::HARRIS	Kevin Harris, dtn 381-2039	`Thu Feb 20 1997 14:24`	45
	From: US2RMC::"[email protected]" "Gregory V. Tarsy" 18-FEB-1997 16:01:27.56 To: [email protected], [email protected], [email protected] CC: Subj: Re: Limbo (was: Java Numerics) ) ) ) 1. Accurate binary/decimal conversion is absolutely essential to ) network computing, even if the heavy crunching is done on back-end ) servers in C or Fortran and only light-weight interactive work in ) the client. Inferno has had it from day one, based on David Gay's ) excellent work which we've made freely available. It puzzles me ) why Java has taken so long, but with Guy on the team surely it will ) happen. ) )Thanks for bringing this up! ) )The Java language specification requires accurate binary/decimal conversion; )any Java implementation that fails in this respect is incorrect. ) )David Gay's work is indeed excellent. I consistently refer all inquiries )on this subject to his report and code, which are available from netlib. Solaris libc has had correctly rounded base-conversion for several years. % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail13.digital.com by us2rmc.zko.dec.com (5.65/rmc-22feb94) id AA11630; Tue, 18 Feb 97 15:47:11 -0500 % Received: from netra.validgh.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id PAA30545; Tue, 18 Feb 1997 15:35:55 -0500 (EST) % Received: from validgh.com by netra.validgh.com (SMI-8.6/SMI-SVR4) id MAA08766; Tue, 18 Feb 1997 12:04:23 -0800 % Received: by validgh.com (4.1/SMI-4.1) id AA20088; Tue, 18 Feb 97 12:01:13 PST % Received: from netra.validgh.com (netra32) by validgh.com (4.1/SMI-4.1) id AA20082; Tue, 18 Feb 97 12:01:08 PST % Received: from venus.Sun.COM by netra.validgh.com (SMI-8.6/SMI-SVR4) id MAA08756; Tue, 18 Feb 1997 12:00:55 -0800 % Received: from Eng.Sun.COM ([129.146.1.25]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA03469; Tue, 18 Feb 1997 12:01:01 -0800 % Received: from susila.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA21074; Tue, 18 Feb 1997 12:00:32 -0800 % Received: by susila.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA29699; Tue, 18 Feb 1997 11:59:14 -0800 % Date: Tue, 18 Feb 1997 11:59:14 -0800 % From: [email protected] (Gregory V. Tarsy) % Message-Id: <[email protected]> % To: [email protected], [email protected], [email protected] % Subject: Re: Limbo (was: Java Numerics) % X-Sun-Charset: US-ASCII % Sender: [email protected] % Precedence: bulk % Reply-To: [email protected] (Gregory V. Tarsy)
210.26	more comments from Hough	RTL::JAFFE		`Fri Feb 21 1997 10:59`	116
	From: US2RMC::"[email protected]" "David G. Hough at validgh" 21-FEB-1997 02:16:20.57 To: [email protected], [email protected] CC: [email protected], [email protected], [email protected] Subj: Even more on Java numerics Coonen's comments having propagated to another mailing list, java-for-cse, I posted a reference to my response at http://www.validgh.com/java, which in turn elicited a reply by Russell Carter. Some of his points (with >) may be of interest to numeric-interest, as well as my comments (no >): > 1. On x86, and especially for Pentium and Pentium Pro CPUs, the statement > that "the performance penalty for adhering to Java's model are not > overwhelming..." is inaccurate at best. As David should well know it > is the ability to keep intermediate results on the stack, along with > judicious use of fxch that give these at best 1 result per cycle > processors their rather surprising sustained floating point performance. > Inducing an extra store/load at every floating point op will cause > a minimum of a factor of 2 in sustained performance. It surely looks > fortunate that Sun has the floating point architecture it does. > And I might also observe that it is possible to buy several compilers > that do The Right Thing for x86, and pgcc does not too bad for free. > So I think that maybe David's concern for the competence of x86 compiler > writers is misplaced, also. > > Taking the long view, it is likely that Sun will find that the market will > settle these issues. It's a nice try at hamstringing wintel/IBM, but > I don't think it will work. As the founders of Java have observed, the original target was embedded processors, of which Intel and IBM have plenty that would not find the Java language definition an impediment. Several chip companies are working on Java chip implementations besides Sun, so there's no particular advantage to any one of them. In any event the Java language definition does not cause Pentium or PowerPC chips to "run SLOW" compared to other architectures, although Pentium and PowerPC might run slower than they would if unconstrained. The major performance issues with these chips are that 1a) The x86 architecture is rather constrained by only eight floating-point registers; whatever is done to match load/store bandwidth to that constraint in general, will also tend to relieve any performance deficit due to loads/stores inserted to get Java-specified rounding. Indeed we can speculate that P7/Merced has already solved this problem, since the shortcomings of the x86 architecture have been known for years and some concessions must have been made to HP. Intel could lay such speculations to rest by being more forthcoming about its plans. 1b) The x86 architecture doesn't seem to have produced many compilers robust enough for scientific programming; none of those I have tested can compile and run UCBTEST and the LAPACK test and timing programs at maximum optimization levels, and problems are common at lower optimization levels too. This suggests to me that, although x86 floating-point units may be the most common in number, they are not particularly predominant among systems used primarily for performance-sensitive floating-point computation. 2) For whatever reasons, PowerPC's have only been popular for Macintosh computers, which are not much used for performance-sensitive floating-point computation. I have not had any reason to evaluate PowerPC compilers. And the net of these considerations is that not many users of these computers would notice these alleged performance deficits due to Java's definition, and there are much more fruitful avenues to obtaining higher numerical performance on systems built of these chips that would yield greater improvements than relaxing the definition of Java. > 2. As a practical matter the fused multiply operations on Power2 CPUs, > and the extended precision registers found in x86, have had essentially > NO discernible effect on the reproducible accuracy of nearly > all practical scientific calculations. It's certainly true that a lot of common scientific code, that runs acceptably on IBM 370, DEC VAX, Crays, and IEEE 754 systems of various flavors, is not much affected by arithmetic details because all such effects have been forcibly suppressed by great programming effort over many years. The focus of Java is to get the same effective portability without such great effort. > In fact, I would go so far as to say that Java numerical results are > going to differ across platforms a lot more from the immaturity of the > output formatting code than from any adherence to individual CPU > architectural enhancements. These differences are bugs and will be so handled. Unlike other languages, Java will not permit hardware bugs, optimizer errors, and library mistakes to masquerade as differences in roundoff or expression evaluation. Write once, test once, run anywhere is the goal. That's a simplification of course; you still need to test Java programs on each platform, if you are paranoid about those hardware bugs, optimizer errors, and library mistakes, but a satisfactory error analysis on one platform will hold for all, and discrepancies can be usefully analyzed because they do mean that something is wrong and there is no likelihood that they will ultimately have to be tolerated because somebody rightly or wrongly concluded that the discrepancies were "just roundoff". % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail13.digital.com by us2rmc.zko.dec.com (5.65/rmc-22feb94) id AA19622; Fri, 21 Feb 97 02:01:21 -0500 % Received: from netra.validgh.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id BAA27338; Fri, 21 Feb 1997 01:56:10 -0500 (EST) % Received: from validgh.com by netra.validgh.com (SMI-8.6/SMI-SVR4) id WAA01681; Thu, 20 Feb 1997 22:27:50 -0800 % Received: by validgh.com (4.1/SMI-4.1) id AA28934; Thu, 20 Feb 97 22:25:45 PST % Received: by validgh.com (4.1/SMI-4.1) id AA28919; Thu, 20 Feb 97 22:25:24 PST % Date: Thu, 20 Feb 97 22:25:24 PST % From: [email protected] (David G. Hough at validgh) % Message-Id: <[email protected]> % To: [email protected], [email protected] % Subject: Even more on Java numerics % Cc: [email protected], [email protected], [email protected] % Sender: [email protected] % Precedence: bulk % Reply-To: [email protected] (David G. Hough at validgh)
210.27	Russell Carter - marketplace supports x86	RTL::JAFFE		`Fri Feb 21 1997 14:40`	239
	From: US2RMC::"[email protected]" "Russell L. Carter" 21-FEB-1997 14:40:48.90 To: [email protected] (David G. Hough at validgh) CC: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected] Subj: Subject: Re: Even more on Java numerics In-reply-to: Your message of "Thu, 20 Feb 1997 22:25:24 PST." <[email protected]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii -------- Hi David, I ordinarily prefer not to get embroiled in numerics issues but due to the way numerical analysis arguments are being used to support Sun's Java floating point model I feel compelled to respond. In the following, one should not assume that I am an Intel partisan; certainly some at Intel would be surprised to hear me described that way. While the first part addresses peripheral issues, near the end some perhaps interesting numerics issues surface. Also, I'm cc'ing this to the java-for-cse list because I think it is important to understand systems issues when discussing java's scientific computing performance. David wrote: > > Coonen's comments having propagated to another mailing list, java-for-cse, > I posted a reference to my response at http://www.validgh.com/java, which > in turn elicited a reply by Russell Carter. Some of his points (with >) > may be of interest to numeric-interest, as well as my comments (no >): And I responded: > > > > Taking the long view, it is likely that Sun will find that the market will > > settle these issues. It's a nice try at hamstringing wintel/IBM, but > > I don't think it will work. > > As the founders of Java have observed, the original target was embedded > processors, of which Intel and IBM have plenty that would not find the > Java language definition an impediment. Several chip companies are working on > Java chip implementations besides Sun, so there's no particular advantage to > any one of them. In any event the Java language > definition does not cause Pentium or PowerPC chips to "run SLOW" compared to > other architectures, although Pentium and PowerPC might run slower than > they would if unconstrained. The major performance issues with these chips > are that No numerics here, but I note: 1. The dragon that is attempting to avoid being skewered by your spear does not care one whit that the forge you used to smith that spear originally produced horseshoes. 2. Future chip designs are irrelevant to the market as it exists for java today. Some might wish otherwise, but that is not the way the market works. > > 1a) The x86 architecture is rather constrained by only eight floating-point > registers; whatever is done to match load/store bandwidth to that constraint > in general, 1. In practice, what does "rather constrained" mean? We all know benchmarks are evil, but perhaps here an examination of the SPEC benchmark database, and a market survey on complete system prices would be in order. Those who have done such a survey consistently find a price/performance advantage of about a factor of 2 for x86 floating point performance, at least on the low end. Now exactly how does the x86 architecture impact the actual data on sustained performance? The evidence at hand implies all other solutions are suboptimal. 2. Load/store bandwidth is not the issue. The number of bits stored in registers is the issue. And that is an LCD argument for a standard when in fact the denominator is not common. Sustained x86 Load/store bandwidth is now in excess of 100 MByte/s, btw. > will also tend to relieve any performance deficit due to loads/stores inserted > to get Java-specified rounding. Indeed we can speculate that P7/Merced > has already solved this problem, since the shortcomings of the x86 architecture To the extent that P7/Merced does not implement solutions with nearly complete compatibility to the existing x86 instruction set it will be ignored. It will have in all likelihood the same success as MMX. It will not "solve" the problem wrt the overall composition of hardware hosting java machines. >1b) The x86 architecture doesn't seem to have produced many compilers robust > enough for scientific programming; none of those I have tested can compile and > run UCBTEST and the LAPACK test and timing programs at maximum optimization > levels, and problems are common at lower optimization levels too. Hmm, I've run a lot more x86 code through LAPACK than just the test and timing problems and have never had a problem. This is using various versions of gcc on various PC unices. I did have a problem with some of the eigenvalue test routines, but since I didn't need them, I ignored them. Maybe there's an accuracy scandal lurking there? I sorta doubt it. As for whether or not x86 is suitable for scientific programming, I guess an easy metric would be $ volume for sales by say, FEM and CFD commercial software. The market (again) indicates that x86 works just fine. > This suggests to me that, although x86 floating-point units may be > the most common in number, > they are not particularly predominant among systems used primarily for > performance-sensitive floating-point computation. If you mean here that most people are not trying to run so-called Grand Challange problems on PCs, we get to agree :) On the other hand, a walk through any National Lab or graduate school for that matter might be a bit depressing to an x86-phobe these days. > > And the net of these considerations is that not many users of these computers > would notice these alleged performance deficits due to Java's definition, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The performance deficit is not "alleged". It is real, and though the reasons for it may have been originally innocuous, they are now being used as a device to significantly reduce the floating point performance of 95% of the available systems on which to run Java. All's fair in the market of course, and if Sun can pull this gates off more power to them. > and there are much more fruitful avenues to obtaining higher numerical > performance on systems built of these chips that would yield greater > improvements than relaxing the definition of Java. To be precise, fruitful to Sun's hardware sales. Only. > > > 2. As a practical matter the fused multiply operations on Power2 CPUs, > > and the extended precision registers found in x86, have had essentially > > NO discernible effect on the reproducible accuracy of nearly > > all practical scientific calculations. > > It's certainly true that a lot of common scientific code, that runs > acceptably on IBM 370, DEC VAX, Crays, and IEEE 754 systems of various > flavors, is not much affected by arithmetic details because all such effects > have been forcibly suppressed by great programming > effort over many years. The focus > of Java is to get the same effective portability without such great effort. The phrase "programming effort" is more accurately replaced by "increased use of stable algorithms" by people pushing the boundaries of computation. That is language (and platform) independent. In a former life, I used access to a variety of computer arithmetic systems to explore stability of numerical algorithms. The actual number of algorithms that are sensitive to the differences in available arithmetic AND are numerically sound is analagous to a set of measure 0. They exist, but their rarity makes them priceless to a Kahan. Here we flirt with fundamental issues of computability. The desire for all programs to produce results identical to the ulp on all machines is essentially equivalent to the wish to have the fractionally insignificant number of numerically broken programs run identically on all machines, whether or not additional bits can be (accurately) computed. Should 95% of the people on the planet either have their current Java machine run slower by at least a factor of 2 or replace their current machine with Sun approved hardware in order to make sure that broken programs do not arouse suspicion by running (slightly) differently on different available platforms? Those who know x86 performance are probably wondering why I only quote a factor of 2. You're right, it's likely a bigger hit than that. > > > In fact, I would go so far as to say that Java numerical results are > > going to differ across platforms a lot more from the immaturity of the > > output formatting code than from any adherence to individual CPU > > architectural enhancements. > > These differences are bugs and will be so handled. Unlike other languages, > Java will not permit hardware bugs, optimizer errors, and library mistakes > to masquerade as differences in roundoff or expression evaluation. > Write once, test once, run anywhere is the goal. > > That's a simplification of course; you still need to test Java programs on ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ No kidding! A competent test on the floating point formatting accuracy of Java I/O routines in order to ensure identical results on all java machines will be hard to require in a branding campaign. > each platform, if you are paranoid about those hardware bugs, optimizer errors, > and library mistakes, > but a satisfactory error analysis on one platform will hold > for all, and discrepancies can be usefully analyzed because they do mean > that something is wrong and there is no likelihood that they will ultimately ^^^^^^^^^^^^^^^^^^^^^^ With the java machine, only. No way to tell about the program. By definition the program runs the same everywhere. > have to be tolerated because somebody rightly or wrongly concluded that > the discrepancies were "just roundoff". ^^^^^^^^^^^^^^^^^^^ ;-) Now, we can kill off most of the numerical analysts. Derive the error analysis and we're done with accuracy issues. Cheers, -- Russell L. Carter Voice:(520) 636-2600 FAX:(520) 636-2888 [email protected] Conceptual Systems & Software, P.O. Box 1129 Chino Valley AZ 86323 "Before sitting down, always look for ferrets." % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail13.digital.com by us2rmc.zko.dec.com (5.65/rmc-22feb94) id AA07629; Fri, 21 Feb 97 14:27:01 -0500 % Received: from netra.validgh.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id OAA24873; Fri, 21 Feb 1997 14:18:21 -0500 (EST) % Received: from validgh.com by netra.validgh.com (SMI-8.6/SMI-SVR4) id KAA06211; Fri, 21 Feb 1997 10:44:00 -0800 % Received: by validgh.com (4.1/SMI-4.1) id AA00991; Fri, 21 Feb 97 10:39:39 PST % Received: from netra.validgh.com (netra32) by validgh.com (4.1/SMI-4.1) id AA00982; Fri, 21 Feb 97 10:39:33 PST % Received: from usr02.primenet.com by netra.validgh.com (SMI-8.6/SMI-SVR4) id KAA06189; Fri, 21 Feb 1997 10:39:07 -0800 % Received: from primenet.com ([email protected] [206.165.5.52]) by usr02.primenet.com (8.8.5/8.8.5) with ESMTP id LAA23967; Fri, 21 Feb 1997 11:39:05 -0700 (MST) % Received: from conceptual.com (consys.com [207.218.17.187]) by primenet.com (8.8.5/8.8.5) with ESMTP id LAA29157; Fri, 21 Feb 1997 11:38:33 -0700 (MST) % Received: from conceptual.com (localhost [127.0.0.1]) by conceptual.com (8.8.5/8.6.9) with ESMTP id LAA01893; Fri, 21 Feb 1997 11:38:27 -0700 (MST) % Message-Id: <[email protected]> % X-Mailer: exmh version 2.0gamma 1/27/96 % To: [email protected] (David G. Hough at validgh) % Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected] % Date: Fri, 21 Feb 1997 11:38:27 -0700 % From: "Russell L. Carter" <[email protected]> % Sender: [email protected] % Precedence: bulk % Reply-To: "Russell L. Carter" <[email protected]>
210.28	David Hough	RTL::JAFFE		`Fri Feb 21 1997 14:51`	45
	From: US2RMC::"[email protected]" "David G. Hough at validgh" 21-FEB-1997 14:52:38.55 To: [email protected] CC: [email protected], [email protected], [email protected], [email protected], [email protected] Subj: ever more java > Should 95% of the people on the > planet either have their current Java machine run slower by at > least a factor of 2 or replace their current machine with Sun > approved hardware in order to make sure that broken programs > do not arouse suspicion by running (slightly) differently on > different available platforms? This is the heart of the argument. The great majority of Java users, past and present, will never use any capabilities more numerically intensive than whatever Java spreadsheets are introduced to compete with Excel. They will never see a 2X slowdown due to the Java language definition; perhaps in unusual circumstances they might be able to measure a 2% slowdown. People doing numerically-intensive computation on PC's are only one of many constituencies doing numerically-intensive computation, and not so much larger than the others; and they are mostly computing in other languages. How many will be doing numerically-intensive computation in Java on P7 systems, and at what performance penalty due to the Java language definition, remains to be seen. So far Intel seems to be less concerned about this issue than Microsoft, oddly enough. I'll leave further discussion of the points Russell raises to others. % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail13.digital.com by us2rmc.zko.dec.com (5.65/rmc-22feb94) id AA09092; Fri, 21 Feb 97 14:44:35 -0500 % Received: from netra.validgh.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id OAA03038; Fri, 21 Feb 1997 14:39:54 -0500 (EST) % Received: from validgh.com by netra.validgh.com (SMI-8.6/SMI-SVR4) id LAA06357; Fri, 21 Feb 1997 11:07:04 -0800 % Received: by validgh.com (4.1/SMI-4.1) id AA01116; Fri, 21 Feb 97 11:06:40 PST % Received: by validgh.com (4.1/SMI-4.1) id AA01101; Fri, 21 Feb 97 11:06:27 PST % Date: Fri, 21 Feb 97 11:06:27 PST % From: [email protected] (David G. Hough at validgh) % Message-Id: <[email protected]> % To: [email protected] % Subject: ever more java % Cc: [email protected], [email protected], [email protected], [email protected], [email protected] % Sender: [email protected] % Precedence: bulk % Reply-To: [email protected] (David G. Hough at validgh)
210.29	Vaughan Pratt	RTL::JAFFE		`Fri Feb 21 1997 15:18`	69
	From: US2RMC::"[email protected]" "Vaughan Pratt" 21-FEB-1997 15:20:43.03 To: [email protected], [email protected] CC: Subj: From: "Russell L. Carter" <[email protected]> Hmm, I've run a lot more x86 code through LAPACK than just the test and timing problems and have never had a problem. This is using various versions of gcc on various PC unices. I did have a problem with some of the eigenvalue test routines, but since I didn't need them, I ignored them. This is anecdotal evidence. That a package works for one happy user (or mostly happy in this case) is little consolation to users for whom it doesn't. The objective way to test a package is to torture it on an official rack, not on one's own software. Should 95% of the people on the planet either have their current Java machine run slower by at least a factor of 2 or replace their current machine with Sun approved hardware in order to make sure that broken programs do not arouse suspicion by running (slightly) differently on different available platforms?... Those who know x86 performance are probably wondering why I only quote a factor of 2. You're right, it's likely a bigger hit than that. Apparently the performance impact of suboptimal floating point is highly variable. Intel arrived at their celebrated 27,000 year period for encountering the Pentium division bug by estimating that in typical use a spreadsheet would perform 1,000 divisions a day. With that frequency, or even a much higher one, one would not see a noticeable slowdown with Mathworks' division bug workaround installed to eliminate the problem. Now we are being told that a workaround correcting for the vagaries of 80-bit extended precision will slow Java programs down by a factor of 2. It is hard to believe that Java programs are that much more numerical than spreadsheet programs. Apparently people make up whichever extreme statistics support their case as they go along, and have no shame when the two extremes differ by however many orders of magnitude it takes to get from 1000 divisions a day for a spreadsheet to a factor-of-two slowdown for a Java applet. Carter's overall argument is part technical and part polemical. That the above two flaws occurred in the technical parts, which I could understand, greatly undermined for me the credibility of the polemical parts, which I could not. Vaughan Pratt % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail13.digital.com by us2rmc.zko.dec.com (5.65/rmc-22feb94) id AA11211; Fri, 21 Feb 97 15:07:52 -0500 % Received: from netra.validgh.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id PAA12054; Fri, 21 Feb 1997 15:03:39 -0500 (EST) % Received: from validgh.com by netra.validgh.com (SMI-8.6/SMI-SVR4) id LAA06624; Fri, 21 Feb 1997 11:35:20 -0800 % Received: by validgh.com (4.1/SMI-4.1) id AA01359; Fri, 21 Feb 97 11:34:02 PST % Received: from netra.validgh.com (netra32) by validgh.com (4.1/SMI-4.1) id AA01353; Fri, 21 Feb 97 11:33:58 PST % Received: from Coraki.Stanford.EDU by netra.validgh.com (SMI-8.6/SMI-SVR4) id LAA06608; Fri, 21 Feb 1997 11:33:57 -0800 % Received: from localhost by Coraki.Stanford.EDU with SMTP (8.6.11/25-BOOLE-eef) id LAA27218; Fri, 21 Feb 1997 11:34:00 -0800 % Message-Id: <[email protected]> % From: Vaughan Pratt <[email protected]> % To: [email protected], [email protected] % In-Reply-To: Your message of "Fri, 21 Feb 1997 11:38:27 MST." <[email protected]> % Date: Fri, 21 Feb 1997 11:34:00 -0800 % Sender: [email protected] % Precedence: bulk % Reply-To: Vaughan Pratt <[email protected]>
210.30	Russell Carter responds	RTL::JAFFE		`Fri Feb 21 1997 16:55`	132
	From: US2RMC::"[email protected]" "Russell L. Carter" 21-FEB-1997 16:55:44.26 To: Vaughan Pratt <[email protected]> CC: [email protected], [email protected] Subj: > > From: "Russell L. Carter" <[email protected]> > > Hmm, I've run a lot more x86 code through LAPACK than just the > test and timing problems and have never had a problem. This is > using various versions of gcc on various PC unices. I did have > a problem with some of the eigenvalue test routines, but since > I didn't need them, I ignored them. > > This is anecdotal evidence. That a package works for one happy user > (or mostly happy in this case) is little consolation to users for whom > it doesn't. The objective way to test a package is to torture it on > an official rack, not on one's own software. David supplied anecdotal evidence, so did I. I suppose each conclusion has equal value. > > Should 95% of the people on the planet either have their > current Java machine run slower by at least a factor of 2 or > replace their current machine with Sun approved hardware in > order to make sure that broken programs do not arouse suspicion > by running (slightly) differently on different available > platforms?... Those who know x86 performance are probably > wondering why I only quote a factor of 2. You're right, it's > likely a bigger hit than that. > > Apparently the performance impact of suboptimal floating point is ^^^^^^^^^^^^^^^^^^^^^^^^^ > highly variable. Intel arrived at their celebrated 27,000 year period > for encountering the Pentium division bug by estimating that in typical > use a spreadsheet would perform 1,000 divisions a day. With that > frequency, or even a much higher one, one would not see a noticeable > slowdown with Mathworks' division bug workaround installed to eliminate > the problem. Suboptimal floating point? The Pentium fdiv bug was suboptimal, the various flavors of Cray arithmetic were surely suboptimal, original IBM 360 subtract-magnitude-with-no-guard-digit was suboptimal, but it's really hard to see how producing more accurate floating point results, faster, is suboptimal. In most practical codes, divisions are a rarity, especially in high performance floating point codes. Most cpus have terrible divide performance. Ordinarily, additions and multiplications vastly outnumber divisions. Studies are available that count the number of multiplications and divisions in interesting codes, compliments of the Cray hardware performance monitor. Now, what does the "workaround" really mean? Coonen's report describes the problem, but it appears many do not understand the crux. Both the P5 and P6 can be programmed to approach perhaps 2/3 of the peak performance of 1 FLOP/cycle. This is done through careful management of the 8 register stack, so that the 8 stage floating point pipeline is kept busy. The stack can be manipulated with no delay due to instruction pairing. As long as there are no "extra" loads or stores the pipeline can be kept mostly filled. If after each floating point operation the result must be written back to and read from memory, the pipeline drains and there is significant stall before the next floating point operation completes. I have written a number of versions of blocked DGEMM in x86 assembly code and I would guess a factor of 10 maybe higher performance loss writing and reading after each flop. Now none of this addresses locality of reference or main memory bandwidth in the system, which is why I suggest a factor of 2. [ this just in: I have read Sam Figueroa's note and he suggests a factor of 10 ] > > Now we are being told that a workaround correcting for the vagaries of > 80-bit extended precision will slow Java programs down by a factor of > 2. It is hard to believe that Java programs are that much more > numerical than spreadsheet programs. The issue is floating point in all programs, not just spreadsheets. I would like to know how it is proposed to do geometrical transformations or image processing in multimedia applications without floating point. > > Apparently people make up whichever extreme statistics support their > case as they go along, and have no shame when the two extremes differ > by however many orders of magnitude it takes to get from 1000 divisions > a day for a spreadsheet to a factor-of-two slowdown for a Java applet. :-) 2x or 1.02x, that surely is the question... > > Carter's overall argument is part technical and part polemical. That > the above two flaws occurred in the technical parts, which I could > understand, greatly undermined for me the credibility of the polemical > parts, which I could not. > > Vaughan Pratt > Oh well. Cheers, Russell % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail13.digital.com by us2rmc.zko.dec.com (5.65/rmc-22feb94) id AA19075; Fri, 21 Feb 97 16:42:55 -0500 % Received: from netra.validgh.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id QAA12203; Fri, 21 Feb 1997 16:31:36 -0500 (EST) % Received: from validgh.com by netra.validgh.com (SMI-8.6/SMI-SVR4) id NAA07235; Fri, 21 Feb 1997 13:01:10 -0800 % Received: by validgh.com (4.1/SMI-4.1) id AA01528; Fri, 21 Feb 97 12:59:45 PST % Received: from netra.validgh.com (netra32) by validgh.com (4.1/SMI-4.1) id AA01522; Fri, 21 Feb 97 12:59:41 PST % Received: from usr01.primenet.com by netra.validgh.com (SMI-8.6/SMI-SVR4) id MAA07219; Fri, 21 Feb 1997 12:59:31 -0800 % Received: from primenet.com ([email protected] [206.165.5.52]) by usr01.primenet.com (8.8.5/8.8.5) with ESMTP id NAA01557; Fri, 21 Feb 1997 13:59:31 -0700 (MST) % Received: from conceptual.com (consys.com [207.218.17.187]) by primenet.com (8.8.5/8.8.5) with ESMTP id NAA17143; Fri, 21 Feb 1997 13:59:21 -0700 (MST) % Received: from conceptual.com (localhost [127.0.0.1]) by conceptual.com (8.8.5/8.6.9) with ESMTP id NAA02620; Fri, 21 Feb 1997 13:59:20 -0700 (MST) % Message-Id: <[email protected]> % X-Mailer: exmh version 2.0gamma 1/27/96 % To: Vaughan Pratt <[email protected]> % Cc: [email protected], [email protected] % In-Reply-To: Your message of "Fri, 21 Feb 1997 11:34:00 PST." <[email protected]> % Mime-Version: 1.0 % Content-Type: text/plain; charset=us-ascii % Date: Fri, 21 Feb 1997 13:59:19 -0700 % From: "Russell L. Carter" <[email protected]> % Sender: [email protected] % Precedence: bulk % Reply-To: "Russell L. Carter" <[email protected]>
210.31	Tydeman on conversions	RTL::JAFFE		`Mon Feb 24 1997 11:36`	75
	From: US2RMC::"[email protected]" "Fred J. Tydeman" 24-FEB-1997 02:14:19.97 To: "numeric interest" <[email protected]> CC: Subj: Re: Comments on Java Numerics On Tue, 4 Feb 97 21:36:10 PST, David G. Hough at validgh wrote: > Java conversions from binary floating-point to decimal string >representations are intended to be correctly rounded but are somewhat limited >in releases so far. Correctly-rounded base conversion is an important >aspect of portable identical results. The following little test shows just how limited those conversions are. The three implementations where this has been run all print out '1' for both '1' and '1+eps'. /* * The Java API documentation says that a floating-point value will be * converted to a string with enough digits so that it can be distinguished * from all other floating-point values with different bit patterns, in * particular, the adjacent floating-point values. * * This program tests that requirement by printing the adjacent values * 1.0 and 1.0+eps. eps is about 2.220446e-16 * * -- Fred Tydeman, tydeman @ tybor.com / class testprnt { public static void main(String args[]){ double one; double onep1; double eps; long li; one = 1.0; li = Double.doubleToLongBits(one); li++; / add one to unit in last place to get to adjacent number / onep1 = Double.longBitsToDouble(li); eps = onep1 - one; System.out.println("1 is " + Double.toString(one)); System.out.println("eps is " + Double.toString(eps)); System.out.println("1+eps is " + Double.toString(onep1)); System.out.println("Did the above line print '1' or '1.00000000000000022e0'?"); }/ main / }/ class testprnt */ --- Fred J. Tydeman +49 (7031) 288-964 Tydeman Consulting Meisenweg 20 [email protected] Programming, testing, C/C++ training D-71032 Boeblingen Voting member of X3J11 (ANSI "C") Germany Sample FPCE tests: ftp://ftp.netcom.com/pub/ty/tydeman % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail13.digital.com by us2rmc.zko.dec.com (5.65/rmc-22feb94) id AA24750; Mon, 24 Feb 97 02:02:03 -0500 % Received: from netra.validgh.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id BAA09617; Mon, 24 Feb 1997 01:57:20 -0500 (EST) % Received: from validgh.com by netra.validgh.com (SMI-8.6/SMI-SVR4) id WAA28109; Sun, 23 Feb 1997 22:29:10 -0800 % Received: by validgh.com (4.1/SMI-4.1) id AA07295; Sun, 23 Feb 97 22:27:00 PST % Received: from netra.validgh.com (netra32) by validgh.com (4.1/SMI-4.1) id AA07289; Sun, 23 Feb 97 22:26:55 PST % Received: from hq.seicom.de by netra.validgh.com (SMI-8.6/SMI-SVR4) id WAA28099; Sun, 23 Feb 1997 22:26:55 -0800 % Received: from tybor.com by hq.seicom.de with smtp (Smail3.1.28.1) id m0vyt0g-000KgvC; Mon, 24 Feb 97 06:31 MET % Message-Id: <[email protected]> % From: "Fred J. Tydeman" <[email protected]> % To: "numeric interest" <[email protected]> % Date: Mon, 24 Feb 97 06:17:40 +0100 % Priority: Normal % X-Mailer: Fred J. Tydeman's Registered PMMail 1.9 For OS/2 % Mime-Version: 1.0 % Content-Type: text/plain; charset="iso-8859-1" % Content-Transfer-Encoding: 7bit % Subject: Re: Comments on Java Numerics % Sender: [email protected] % Precedence: bulk % Reply-To: "Fred J. Tydeman" <[email protected]>
210.32	Bill Walster, directed roundings	RTL::JAFFE		`Thu Feb 27 1997 09:41`	78
	From: US2RMC::"[email protected]" "MAIL-11 Daemon" 26-FEB-1997 22:09:47.88 To: [email protected], [email protected] CC: [email protected], [email protected], [email protected], [email protected], [email protected] Subj: JAVA and directed rounding ----- Begin Included Message ----- From [email protected] Tue Feb 25 05:44:36 1997 Date: Tue, 25 Feb 1997 14:38:00 +0100 From: Hoon Hong <[email protected]> To: [email protected] Cc: Bill.Walster@Eng Subject: Re: JAVA and directed rounding X-Lines: 36 Thanks Vladik, I am currently trying to decide which language to use for our software (large non-linear constraint solver, involving about 10 PhD students and 2 years) development. I checked many languages (from C++ to Haskell), and found that JAVA is the best among them. But one thing is blocking me from making the final decision: lack of support for "directional rounding". We need it ABSOUTELY for the software. I do know that we could use the "naitive" methods for this. But then, it diminishes the virture of JAVA from our point of view. I am quite curious about why JAVA documentation says that * it supports IEEE standard for floats * but it does not support the main feautre of it: directed rounding. Further, as I know, almost all float coprocessors now a days support directed rounding. Thus, I am doubly curious about the rationale behind the JAVA group's decision to omit the directed rounding. I really hope that this is supported. Best regards, Hoon ----- End Included Message ----- % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail13.digital.com by us2rmc.zko.dec.com (5.65/rmc-22feb94) id AA27222; Wed, 26 Feb 97 21:54:54 -0500 % Received: from netra.validgh.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id VAA20808; Wed, 26 Feb 1997 21:45:08 -0500 (EST) % Received: from validgh.com by netra.validgh.com (SMI-8.6/SMI-SVR4) id SAA27287; Wed, 26 Feb 1997 18:16:09 -0800 % Received: by validgh.com (4.1/SMI-4.1) id AA19625; Wed, 26 Feb 97 18:14:07 PST % Received: from netra.validgh.com (netra32) by validgh.com (4.1/SMI-4.1) id AA19615; Wed, 26 Feb 97 18:13:57 PST % Received: from venus.Sun.COM by netra.validgh.com (SMI-8.6/SMI-SVR4) id SAA27249; Wed, 26 Feb 1997 18:13:59 -0800 % From: [email protected] % Received: from Eng.Sun.COM ([129.146.1.25]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAA14665; Wed, 26 Feb 1997 18:13:31 -0800 % Received: from gww.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA16511; Wed, 26 Feb 1997 18:13:26 -0800 % Received: by gww.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA17041; Wed, 26 Feb 1997 18:15:16 -0800 % Date: Wed, 26 Feb 1997 18:15:16 -0800 % Message-Id: <[email protected]> % To: [email protected], [email protected] % Subject: JAVA and directed rounding % Cc: [email protected], [email protected], [email protected], [email protected], [email protected] % X-Sun-Charset: US-ASCII % Sender: [email protected] % Precedence: bulk % Reply-To: [email protected]
210.33	David Hough says Merced is delayed	RTL::JAFFE		`Fri Feb 28 1997 16:55`	29
	From: US2RMC::"[email protected]" "David G. Hough at validgh" 28-FEB-1997 16:57:04.33 To: [email protected] CC: Subj: Intel's 64-bit Microprocessor Delayed Until 1999 Relative to Java on x86 futures, Stuart McDonald directed me to http://techweb.cmp.com/iw/newsflash/nf619/0224_st3.htm which asserts that Merced will not be available until 1999, and then apparently primarily for servers - suggesting high-price low-volume availability in this millenium. % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail13.digital.com by us2rmc.zko.dec.com (5.65/rmc-22feb94) id AA17765; Fri, 28 Feb 97 16:49:43 -0500 % Received: from netra.validgh.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id QAA00680; Fri, 28 Feb 1997 16:44:50 -0500 (EST) % Received: from validgh.com by netra.validgh.com (SMI-8.6/SMI-SVR4) id NAA14589; Fri, 28 Feb 1997 13:16:06 -0800 % Received: by validgh.com (4.1/SMI-4.1) id AA27005; Fri, 28 Feb 97 13:13:25 PST % Received: by validgh.com (4.1/SMI-4.1) id AA26999; Fri, 28 Feb 97 13:13:21 PST % Date: Fri, 28 Feb 97 13:13:21 PST % From: [email protected] (David G. Hough at validgh) % Message-Id: <[email protected]> % To: [email protected] % Subject: Intel's 64-bit Microprocessor Delayed Until 1999 % Sender: [email protected] % Precedence: bulk % Reply-To: [email protected] (David G. Hough at validgh)
210.34	exceptions	RTL::JAFFE		`Wed Mar 26 1997 10:08`	68
	From: US2RMC::"[email protected]" "David G. Hough at validgh" 25-MAR-1997 20:52:35.79 To: [email protected] CC: Subj: IEEE 754 exceptions and Java Virtual Machine I just learned something of interest in our ongoing Java discussion. I'd proposed that Java needed some efficient method for supporting detecting the five IEEE 754 exceptions, at least in basic blocks of code, and I'd supposed that since almost all Java implementations are on systems that support IEEE 754 in hardware, this would not be a big deal to add. I hadn't thought about the fact that since the facility is not in the language, it's not in the Java Virtual Machine either, and therefore might not be implemented at all in new Java Virtual Machines implemented in hardware, or in software on systems with no floating-point hardware. This would be bad news, I think, from the point of view of supporting scientific computation. Sometimes the most efficient program is one that computes as fast as possible and traps out to do something else if something bad happens; sometimes it's best just to compute as fast as possible to the end and then check accrued exception flags and do something else if something bad happened. Possible syntax such as try { a = b * c ; } catch (overflow) { a = 3.0 ;} that one might propose adding to the language reflects such usages. So I think JVM implementors would do well to make sure the IEEE 754 exception flags at least are maintained through floating-point operations in the JVM, and give thought to hardware mechanisms for reading and writing those flags to support possible future language extensions. If asynchronous trapped IEEE 754 exceptions were treated as deterministically as other Java exceptions, stopping execution precisely at the point the exception arose, then that would be quite an advance in debuggability since there would be no uncertain side effects when exceptions, but it would cost a lot in execution time - far more than other issues we have discussed. Just supporting the flag model means that the whole computation in the try {} would proceed until it finished and then the flags would be checked synchronously, at no special cost in execution time of the block. Supporting detecting exceptions in external functions within a try {} raises lots of system issues and so might be much more expensive to support well. In contrast, the value of supporting dynamic IEEE rounding modes in the Java Virtual Machine seems much less to me. Static rounding modes suffice for interval arithmetic. The overall issue is how possible future directions for Java can be explored. Especially in the numerical area, I think academic projects to explore language and JVM extensions should be encouraged, with the understanding that perhaps none will necessarily be adopted. % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail13.digital.com by us2rmc.zko.dec.com (5.65/rmc-22feb94) id AA21312; Tue, 25 Mar 97 20:35:15 -0500 % Received: from netra.validgh.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id UAA27779; Tue, 25 Mar 1997 20:27:58 -0500 (EST) % Received: from validgh.com by netra.validgh.com (SMI-8.6/SMI-SVR4) id RAA20585; Tue, 25 Mar 1997 17:00:28 -0800 % Received: by validgh.com (4.1/SMI-4.1) id AA27492; Tue, 25 Mar 97 16:57:34 PST % Received: by validgh.com (4.1/SMI-4.1) id AA27483; Tue, 25 Mar 97 16:57:29 PST % Date: Tue, 25 Mar 97 16:57:29 PST % From: [email protected] (David G. Hough at validgh) % Message-Id: <[email protected]> % To: [email protected] % Subject: IEEE 754 exceptions and Java Virtual Machine % Sender: [email protected] % Precedence: bulk % Reply-To: [email protected] (David G. Hough at validgh)
210.35	News Brief in IEEE Computer, April 1997	CAIRN::HARRIS	Kevin Harris, dtn 381-2039	`Tue Apr 08 1997 12:23`	36
	The following short note appears in the April 1997 issue of IEEE Computer, the News Briefs section, p. 25. It shows that Coonen has an axe to grind that is somewhat larger than his own scientific interest: "JAVA AND FLOATING-POINT MATH Complex math applications written for Java do not take advantage of the enhanced calculation capabilities of Intel's x86 and Motorola's PowerPC microprocessors. This causes these chips to perform complex calculations less precisely and more slowly while using Java than they would otherwise. Sun, which developed Java, acknowledged that Java was designed to perform floating-point calculations at the minimum acceptable accuracy level called for in the IEEE 754 floating-point math standard, to make sure the programming language could support many platforms. However, this also means that Java's floating-point implementation does not take advantage of the extra precision afforded by the Intel and Motorola chips, said Jerome Coonen, a mathematics expert hired by Microsoft to study Java. Microsoft, which has based much of its product development strategy on its Windows operating system, has been battling the influence of the platform-independent Java in the marketplace. The x86 and PowerPC chips support three formats for floating-point calculations: 4-byte single, 8-byte double, and the extended format, which occupies at least 10 bytes and makes it at least 1000 times less likely that an error will occur in a complex math calculation. Java does not take full advantage of the extended format, Coonen said. The x86 and PowerPC chips thus must slow down and use the 8-byte format to perform floating-point calculations with Java. This means the resulting calculations won't be performed as quickly or precisely as they would with the extended format. Bill Joy, Sun's vice president for research, said the company is looking into ways to remedy these problems while maintaining Java's portability."