[E-Lang] Operators #6: Multiplicative operators
Tue, 10 Apr 2001 13:56:05 -0700
At 10:12 AM -0700 4/10/01, Mark S. Miller wrote:
>At 08:18 AM Tuesday 4/10/01, Karp, Alan wrote:
>>Mark Miller wrote:
>>> x / y, when x and y are either integers or float64s, evaluates to the
>>> floating point number that's the appropriate approximation to the real
>>> quotient by the IEEE round-to-even rule (the rounding rule governing all
>>> floating point arithmetic in Java and E.) When x and y are float64s, "/"
>>> has the same meaning in E as in Java.
>>I think there needs to be a way to control the IEEE rounding mode. It's
>>particularly important when writing code to implement math functions like
>>log, exp, etc. While I expect there to be library routines for these,
>>special rounding modes are often used for computing special functions, such
>>as Bessel functions and spherical harmonics.
>Even once there's an ENative, E-on-pure-Java will continue to be one of the
>important implementations of E, and may continue to be *the* important
>implementation. As a result, E can only specify that which can be
>reasonably implemented in standard pure Java. So regarding float64s and
>IEEE, E conforms to "the deterministic subset of IEEE supported by standard
>Is there any way in standard pure Java to control the rounding mode?
The by now old Java Language Specification says that Java always uses
"round to nearest". I think if you need to change the rounding mode, you
will have to write in another language.
BTW - For the sake of defining the meaning of operators on various types of
object, I would divide the objects into two groups: those that give exact
results, and those that don't. As far as I know, IEEE floating point is
the only built in example of the latter.
For the inexact result group, we can accept many non-intuitive things, like
NaNs, a + b = a for non-zero b etc. The inexact group exists because for
many uses, engineering approximations are good enough. These behaviors are
engineering solutions for, and effects of this decision.
I suggest being much more concerned about non-mathematical behavior in the
exact results group.
Cheers - Bill
Bill Frantz | Microsoft Outlook, the | Periwinkle -- Consulting
(408)356-8506 | hacker's path to your | 16345 Englewood Ave.
email@example.com | hard disk. | Los Gatos, CA 95032, USA