Fraction
Joe Darcy
joe.darcy at oracle.com
Wed Jan 11 18:38:11 UTC 2012
Hello Dima,
On 01/09/2012 09:13 AM, Dmitry Nadezhin wrote:
> Hello Joe,
>
> Thank you for the clarification.
>
> What do you think about using BigBinary to solve the problem of a
> calculation class with higher precision.
> BigBinary implements arbitrary precision binary floating-point numbers
> and arithmetic operations on them.
> Although it rounds, the precision and rounding direction are controlled.
> It seems to me that binary floating-point numbers are more natural
> than decimal for scientific applications.
> Should such a class be in the JDK or outside?
Some time ago I filed and more recently deferred the JDK RFE
4529368 RFE: Add a BigBinary class for arbitrary precision
floating-point computation
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4529368
While this is a fine idea on a technical basis, given other priorities,
I don't anticipate Oracle's JDK group funding work on this in the
foreseeable future. However, the JEP process allows other parties to
propose and develop such efforts. [1]
>
> If you don't think that BigBinary is appropriate, then let me ask some
> other questions.
> IEEE 754-2008 defines three basic binary formats: Binary32, Binary64,
> Binary128 .
> Binary32 and Binary64 are already known in JDK as Float and Double
> (with rounding to nearest even).
> Should there be a software emulation of Binary128 in JDK (as a class
> with two private long fields)?
There would be some utility in having such a Binary128/Quad class, but
again I don't see the JDK group taking the initiative in its
development. (Note that while straightforward, direct use of the quad
type never really caught on. The type is supported in both the sparc
and pa-risc instruction sets, but never got direct hardware support on
those processors since customers typically found another approach to
address their numerical difficulties. On processor families with a fused
mac instruction, there are other relatively fast ways to implement
somewhat grubby higher-precision operations.)
> Should the JDK have a class with static methods that implement
> arithmetic operations on floats and doubles with directed rounding like
> http://java.net/projects/projectfortress/sources/sources/content/ProjectFortress/src/com/sun/fortress/numerics/DirectedRounding.java
> ?
From an API perspective, I think this functionality would be better
done as methods like
double add(double, double, java.math.RoundingMode)
> Is there a chance that Binary128 or DirectedRounding methods would be
> internalized in hotspot?
>
> These questions are important to me because I am working on an
> interval arithmetic library
> http://kenai.com/projects/jinterval/ and could use these new classes.
>
> I understand that the addition of numerical features to the JDK is closed.
> However, if there is a chance to add any new classes, I'd be glad to
> contibute to their development.
However, I don't think directed rounding methods will be added to the
JDK in JDK 8; if they were added, they would not likely have sufficient
duty-cycle to justify HotSpot intrinsics for them.
Cheers,
-Joe
[1] http://openjdk.java.net/jeps/0
> Cheers,
>
> -Dima
>
>
> On Fri, Jan 6, 2012 at 2:46 AM, Joe Darcy<joe.darcy at oracle.com> wrote:
>> Hello,
>>
>>
>> On 1/1/2012 8:54 AM, Tom Eugelink wrote:
>>>
>>> Hello guys,
>>>
>>> I was wondering if it was of any interest to OpenJFX to have a calculation
>>> class that does not round. I've got "Fraction" laying around, which does
>>> math using two BigIntegers, so it never even rounds. The API is roughly
>>> equivalent to BigDecimal, so you have methods like add, divide, etc.
>>>
>>> Any interest in adding such a class to Java?
>>>
>> The BigDecimal class can already preform exact computations. To get exact
>> behavior, use the version of add, subtract, etc. that takes a single
>> BigDecimal argument or the version that takes a BigDecimal argument and a
>> MathContext argument and pass a MathContext object with a precision of 0.
>> Of the four basic arithmetic operations, the most interesting operation is
>> divide since it can result in infinite inputs (fractions that are
>> non-terminating in decimal) from finite inputs while the other operations
>> cannot.
>>
>> In terms of its representation, BigDecimal class uses a floating-point style
>> scaled representation so that very large or very small numbers that are
>> low-precision don't use a lot of storage.
>>
>> When doing general computations, there is a need to round result
>> periodically to avoid unbounded growth in the sizes of the numbers being
>> operated on. BigDecimal supports various rounding operations, including
>> rounding to a given number of places after the decimal point and rounding to
>> a given number of total digits. These styles of rounding are relatively
>> easy to understand, but still quite vexing for numerical analysis.
>>
>> The rounding options I'm familiar with for rational packages are fixed slash
>> vs floating-slash, that is, given constraints on the sizes of the numerator
>> and denominator, return the nearest fraction to the exact result. AFAIK,
>> such system are less studied if not more difficult to work with than
>> traditional rounding.
>>
>> In short, while there would be some use cases, without additional
>> justification I don't see the need to add a rational number package to the
>> JDK.
>>
>> Cheers,
>>
>> -Joe
>>
More information about the core-libs-dev
mailing list