Java浮点数陷阱：为何它无处不在地影响所有人

3星 · 超过75%的资源需积分: 17 27 浏览量更新于2024-08-02 收藏 280KB PDF 举报

《Java浮点运算如何困扰全球：一个深入剖析》本文由加州大学伯克利分校的电子工程与计算机科学教授W. Kahan和Joseph D. Darcy撰写，最初发表于1998年3月的ACM Java for High-Performance Network Computing研讨会，旨在探讨Java设计决策对于其目标市场的影响，以及浮点运算在Java中的局限性。文章指出，随着Java的发展，其初衷并不完全适应某些关键领域的高精度需求，特别是涉及到科学计算、数值分析和数据一致性时。一、概述 Java的设计初衷是面向广泛市场，但其对浮点数处理的实现方式却导致了一些核心问题。纯Java中的两个主要误导承诺，即无法实现的精确性和性能，对用户产生了实际的负面影响。随着技术的进步和性能要求的提高，这些问题变得更加显著。二、Java的两个残酷幻觉 1. **精确性承诺**：Java宣传其可以提供一致的浮点运算结果，但实际上，由于浮点数表示的不精确性（如舍入误差），这在处理复杂数学运算，如复数算术或涉及液体流动模拟等场景中，可能导致看似可预测的结果出现不可预期的变化。 2. **性能与精确性的权衡**：为了追求更快的矩阵乘法等计算速度，Java牺牲了不必要的精确性。然而，在某些应用中，如金融交易或科学研究，确保精确的重现性至关重要，而Java在这种情况下显得力不从心。三、例子分析 1. **复数运算类**：Java的复数类设计可能无法满足某些科学计算对精确性的要求，比如处理需要精确控制的流体动力学模拟，结果的再现性可能会受到质疑。 2. **矩阵乘法优化**：尽管Java试图通过优化提高矩阵乘法的速度，但这可能牺牲了对于结果精确性的控制，这对于那些依赖于准确度的应用，如图像处理或机器学习，是一个潜在的问题。四、自我约束与可控制性面对这些问题，作者提倡程序员和开发者应具备更高的自我约束力，明确了解并处理浮点运算的局限性。他们强调，为了确保可重复性和可控性，开发者应该选择合适的算法，并在必要时采用外部库或者自定义解决方案来满足特定领域的精确度需求。这篇文章揭示了Java在浮点运算处理上的挑战，呼吁开发者在设计和使用Java进行科学计算和高性能应用时，要充分考虑精度和性能之间的权衡，以避免潜在的错误和不一致性。同时，它也提出了开发者自我教育和采取适当策略以适应这些局限性的必要性。

How Java’s Floating-Point Hurts Everyone Everywhere

July 30, 2004 6:28 pm Work in Progress — Subject to Supersession Page 14

Lifting Flow past Joukowski’s Aerofoil

Correctly Plotted Streamlines Where is this wing’s bottom ?

Plotted using C9X–like Complex and Imaginary Misplotted using Fortran–like Complex

A circulating component, necessary to generate lift, speeds the ﬂow of an idealized ﬂuid above the wing and slows

it below. One streamline splits at the wing’s leading edge and recombines at the trailing edge. But when –0 is

mishandled, as Fortran-style Complex arithmetic must mishandle it, that streamline goes only over the wing.

The computation solves numerically nontrivial transcendental equations involving complex logarithms. Both plots

come from the same program using different Complex Class libraries, ﬁrst with and second without an Imaginary

Class. Experienced practitioners programming in Fortran or C++ have learned to replace the split streamline by

two streamlines, one above and one below, separated by as few rounding errors as produce a good-looking plot.

How Java’s Floating-Point Hurts Everyone Everywhere

July 30, 2004 6:28 pm Work in Progress — Subject to Supersession Page 15

Why such plots malfunction, and a very simple way to correct them, were explained long ago in …

“ Branch Cuts for Complex Elementary Functions, or Much Ado About Nothing's Sign Bit ” by W. Kahan, ch.

7 in The State of the Art in Numerical Analysis ( 1987 ) ed. by M. Powell and A. Iserles for Oxford U.P.

A streamline goes astray when the complex functions SQRT and LOG are implemented, as is

necessary in Fortran and in libraries currently distributed with C/C++ compilers, in a way that

disregards the sign of

± 0.0 in IEEE 754 arithmetic and consequently violates identities like

SQRT(

CONJ( Z ) ) = CONJ( SQRT( Z ) ) and LOG( CONJ( Z ) ) = CONJ( LOG( Z ) )

whenever the COMPLEX variable Z takes negative real values. Such anomalies are unavoidable if

Complex Arithmetic operates on pairs (x, y) instead of notional sums x + ı·y of real and imaginary

variables. The language of pairs is incorrect for Complex Arithmetic; it needs the Imaginary type.

A controversial Complex Arithmetic Extension to the programming language C incorporating

that correction, among other things, has been put before ANSI X3J11, custodian of the C language

standard, as part of the C9X proposal. It is controversial because it purports to help programmers

cope with certain physically important discontinuities by suspending thereat ( and nowhere else ) the

logical proposition that “ x == y ” implies “ f(x) == f(y) ”. Many a programmer will

prefer this anomaly to its alternatives.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

The moral of this story: There will always be good reasons ( and bad ) to call diverse versions of

hard- and software, including mathematical software, by the same name.

Nobody can copyright “ Complex Class.”

How Java’s Floating-Point Hurts Everyone Everywhere

July 30, 2004 6:28 pm Work in Progress — Subject to Supersession Page 16

Besides programs with the same name but designed for slightly different results,

there are programs with the same name designed to produce essentially the same results

as quickly as possible

which must therefore produce slightly different results on different computers.

Roundoff causes results to differ slightly not because different computers round arithmetic differently

but because they manage memory, caches and register ﬁles differently.

Example: Matrix multiplication C := A·B … i.e. c

:= ∑

·b

= a

·b

+ a

·b

+ a

·b

+ …

To keep pipelines full and avoid unnecessary cache misses, different computer architectures have to perform

multiplications a

·b

and their subsequent additions in different orders. In the absence of roundoff the order

would not affect C because addition would be associative. Order affects accuracy only a little in the presence of

roundoff because, for all suitable matrix norms ||…|| , ||C - A·B||/(||A||·||B||) cannot much exceed the roundoff

threshold regardless of order, and this constraint upon C sufﬁces for most applications even if

C varies very noticeably from one computer to another.

Ordering affects speed a lot. On most processors today, the most obvious matrix multiply program runs at least

three times slower than a program with optimal blocking and loop-unrolling. Optimization depends delicately upon

processor and cache details. For matrices of large dimensions, a code optimized for an UltraSPARC, about three

times faster thereon than an unoptimized code, runs on a Pentium Pro ( after recompilation ) slower than a naive

code and about six times slower than its optimal code. Speed degradation becomes worse on multi-processors.

Faster matrix multiplication is usually too valuable to forego for unneeded exact reproducibility.

Conclusion: Linguistically legislated exact reproducibility is unenforceable.

剩余80页未读，继续阅读

zhouhs1985

粉丝: 1
资源: 6

Java浮点数陷阱：为何它无处不在地影响所有人

浮点计算误差分析——我自己写的

How Java's Floating-Point Hurts Everyone Everywhere

Fixed-point-and-floating-point.rar_dsp_floating_floating point D

floating-point-alternative-.rar_floating

Floating-Point Fused Multiply-Add Architectures

32-bit-Floating-Point-ALU:单精度浮点加法系统

Floating-point arithmetic in C

Floating-Point-Library-for-FlashForth:FlashForth 的浮点库实现

IEEE Standard for Floating-Point Arithmetic

求极限lim的matlab代码-Floating-Point-Arithmetic:浮点运算

最新资源