[
https://issues.apache.org/jira/browse/NUMBERS-131?focusedWorklogId=462140&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-462140
]
ASF GitHub Bot logged work on NUMBERS-131:
------------------------------------------
Author: ASF GitHub Bot
Created on: 22/Jul/20 16:36
Start Date: 22/Jul/20 16:36
Worklog Time Spent: 10m
Work Description: aherbert commented on pull request #66:
URL: https://github.com/apache/commons-numbers/pull/66#issuecomment-662558604
This PR is out-of-date. The algorithm for BigFraction was rewritten since
this PR was made. But IIUC this contains a method to extend beyond the `long`
datatype for the numerator/denominator used in the current implementation.
If you care to rebase the code on the current master then I'll take a look.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 462140)
Time Spent: 1h (was: 50m)
> Re-designing BigFraction.from(double, double, int, int)
> -------------------------------------------------------
>
> Key: NUMBERS-131
> URL: https://issues.apache.org/jira/browse/NUMBERS-131
> Project: Commons Numbers
> Issue Type: Improvement
> Components: fraction
> Affects Versions: 1.0
> Reporter: Heinrich Bohne
> Priority: Minor
> Time Spent: 1h
> Remaining Estimate: 0h
>
> The method {{BigFraction.from(double, double, int, int)}} can be improved in
> several ways:
> * It only allows a maximum denominator in the {{int}} range, which defies the
> purpose of having a {{BigFraction}} class in addition to the class
> {{Fraction}}. Since {{BigFraction}} is {{BigInteger}} based, it would only be
> natural to allow the maximum denominator to be passed as a {{BigInteger}}.
> * It only calculates the convergents of the simple continued fraction, but
> not its semi-convergents, so it doesn't necessarily produce the closest
> possible approximation within the given bounds.
> * The design is awkward. Making the method's behavior dependent on the values
> of its arguments is confusing, even the documentation acknowledges this.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
