Fraction

[Joe Darcy]

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
>>