classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: java.lang.StrictMath


From: Eric Blake
Subject: Re: java.lang.StrictMath
Date: Thu, 14 Feb 2002 21:55:35 -0700

Hmm, maybe you are right.  On second reading, Sun specifies the
following in StrictMath:

"To help ensure portability of Java programs, the definitions of many of
the numeric functions in this package require that they produce the same
results as certain published algorithms.... These algorithms, which are
written in the C programming language, are then to be understood as
executed with all floating-point operations following the rules of Java
floating-point arithmetic."

Then, in Math, they state:

"By default many of the Math methods simply call the equivalent method
in StrictMath for their implementation. Code generators are encouraged
to use platform-specific native libraries or microprocessor
instructions, where available, to provide higher-performance
implementations of Math methods. Such higher-performance implementations
still must conform to the specification for Math."

I had interpreted it to mean that Math may be native, but StrictMath
should be pure.  Besides, the less native code there is, the less
maintainance problems and more portable Classpath becomes.  But maybe it
is worth it after all for StrictMath to have native implementations,
provided such implementations match the ones I just submitted in the
Java language.  Is the overhead of calling a native method offset by the
speed of doing this number crunching without going through bytecode?

Per Bothner wrote:
> 
> Eric Blake wrote:
> > StrictMath is required to be implemented in pure Java, not
> > in native code;
> 
> Where is this peculiar requirement stated?  No proper
> specification would make any such requirement (not to
> suggest that Java has a proper specification) - most
> standards have an "as-if" rule:  The implementation must
> behave *as if* it used the specified algorithm or code,
> but as long as no valid program can tell the difference,
> the implementation is free to use some other algorithm.
> --
>         --Per Bothner
> address@hidden   http://www.bothner.com/per/

-- 
This signature intentionally left boring.

Eric Blake             address@hidden
  BYU student, free software programmer




reply via email to

[Prev in Thread] Current Thread [Next in Thread]