[E-Lang] Seminar: TUESDAY, April 17

[Bill Frantz]

I attended this seminar, and met Alan Karp there.  Prof. Kahan said
that the notes from the lecture would be available on his web page
tomorrow (http://www.cs.berkeley.edu/~wkahan/).


The high points for language designers seem to be:


* Support the highest precision available on the platform (long double,
80 bit, etc).


* Make the truncation rules top down, not bottom up.  That is: if you
are multipling two 32 bit floats, and then adding them to a 64 bit
double, perform the multiplication as double to preserve the precision
of the product.


* Provide invocation level control over the rounding mode so a
questionable calculation can be run with several rounding modes to
check for rounding sensitivity.  Note that this procedure will not
catch 100% of round off generated errors, but may be the only technique
available for programs without source.


Some of the other papers on the web page may also be of interest, for
example, "How Java's Floating-Point Hurts Everyone Everywhere"


Pages Topics

3        Abstract

4 - 9    Overview: Java has evolved to target markets to which its
initial design decisions are ill-suited.

10       Pure Java's Two Cruel Delusions, promises Java cannot keep

11 - 15  Example: Complex Arithmetic Classes; should misplotted fluid
flows be exactly reproducible?

16       Example: Faster Matrix Multiply too valuable to forego for
unneeded exact reproducibility

17 - 18  Self-Discipline, Reproducibility, Controllability

19 Java purports to fix what ain't broken in Floating-point

20 - 24  Exceptions; Algebraical Completion; lack of Flags makes Java's
=46loating-Point Dangerous

25 - 26  Misconceptions about Floating-point

27 - 30  Example: Disassociate "Catastrophic" from "Cancellation";
Computation as a Web

31       An old Rule of Thumb is wrong because of misconceptions about
Precision and Accuracy

32 - 35  Why so many still believe this wrong rule of thumb; another
counter-example

36 - 41  What's wrong with it (and another counter-example); how it got
into so many programming languages

42 - 43  What to do instead; Four Rules of Thumb for best use of modern
floating-point hardware

44       Example: Angle at the eye; old Kernighan-Ritchie C semantics
are safer than Java's

45 - 47  Three Williams contend for Java's numerics, it should copy old
Kernighan-Ritchie C semantics

48 - 49  Example: 3-dimensional rectilinear geometry; Cross-products
work better as matrix products

50 - 52  Overloaded operators; Neat solutions for nearest-point
problems, =8A

53 - 55  turned into numerical junk by Java's floating-point, work well
in Kernighan-Ritchie C

56 - 57  Dynamic Directed Rounding Modes; Debugging Numerical
Instability

58 - 60  Example: Needle-like triangles' area and angles

61 - 64  IEEE 754 Double Extended reduces the risk of chagrin,
conserves monotonicity, =8A

65 - 66  =8A but not in Java. Three floating-point formats run fast; the
widest is valuable for =8A

67 - 73  Example: Cantilever calculation; Iterative refinement's
accuracy improves spectacularly more than 11 bits

74 - 75  The cheaper machines would always get better results but for
Java's and Microsoft's intransigence

76 - 79  How to support extra-precise arithmetic; anonymous indigenous
; Optimizations by the Compiler

80       Conclusions: Java's floating-point hurts Java vs. J++ , so
repair Java's floating-point soon.



At 10:52 AM -0700 4/12/01, Bill Frantz wrote:

>>SPEAKER: Prof. William Kahan

>>FROM:    Dept.  Mathematics, and Dept. Elect. Eng. & Computer Sci.,

>>         University of California, Berkeley

>>E-MAIL:  wkahan@cs.berkeley.edu

>>TITLE:   What has the  Volume of a Tetrahedron  to do with Computer

>>         Programming Languages?

>>

>>ABSTRACT: The computation of a tetrahedron's volume has been chosen
as

>>a didactic example elementary enough to be tolerated by the intended

>>audience (who have forgotten most of the calculus and linear algebra

>>they encountered in college) yet difficult enough to impart an

>>appreciation of the challenges faced by applications programmers

>>lacking in numerical experience though clever about other things.

>>These challenges are exacerbated by programming languages like C++
and

>>Java that perpetuate practices, accepted only as expedients in the

>>1960s, that now inflate the languages capture cross-section for
error.

>>By treating the tetrahedron's volume as a case study we can
formulate

>>better guidelines for programming languages to handle floating-point

>>arithmetic in ways compatible with the few rules of thumb that
should

>>be (but are still not being) taught to the vast majority of

>>programmers, who learn no more about floating-point than they hear
in

>>a programming class or read in a programming language manual.

>>Complaining about education rarely improves it; our efforts are
better

>>spent redesigning computer systems and languages to attenuate

>>occasional harm caused by well-intentioned ignorance among the

>>multitudes.


-------------------------------------------------------------------------

Bill Frantz       | Microsoft Outlook, the     | Periwinkle --
Consulting

(408)356-8506     | hacker's path to your      | 16345 Englewood Ave.

frantz@netcom.com | hard disk.                 | Los Gatos, CA 95032,
USA