Re: [numbers] Fraction

> On 9 Apr 2020, at 23:59, Gilles Sadowski wrote: > > Le jeu. 9 avr. 2020 à 23:20, Alex Herbert > a écrit : >> >> >> >>> On 9 Apr 2020, at 21:36, Gilles Sadowski wrote: >>> >>> Le jeu. 9 avr. 2020 à 22:20, Alex Herbert a >>> écrit : >>>

Re: [numbers] Fraction

Great +1 On Thu, Apr 9, 2020 at 3:59 PM Gilles Sadowski wrote: > Le jeu. 9 avr. 2020 à 23:20, Alex Herbert a > écrit : > > > > > > > > > On 9 Apr 2020, at 21:36, Gilles Sadowski wrote: > > > > > > Le jeu. 9 avr. 2020 à 22:20, Alex Herbert > a écrit : > > >> > > >> > > >> > > >>> On 9 Apr 2020

Re: [numbers] Fraction

Le jeu. 9 avr. 2020 à 23:20, Alex Herbert a écrit : > > > > > On 9 Apr 2020, at 21:36, Gilles Sadowski wrote: > > > > Le jeu. 9 avr. 2020 à 22:20, Alex Herbert a > > écrit : > >> > >> > >> > >>> On 9 Apr 2020, at 16:32, Gilles Sadowski wrote: > >>> > >>> > >>> > Given this I am thinking t

Re: [numbers] Fraction

> On 9 Apr 2020, at 21:36, Gilles Sadowski wrote: > > Le jeu. 9 avr. 2020 à 22:20, Alex Herbert a écrit : >> >> >> >>> On 9 Apr 2020, at 16:32, Gilles Sadowski wrote: >>> >>> >>> Given this I am thinking that using ZERO when possible is a better option and avoid 0 / -1. >>> >

Re: [numbers] Fraction

Le jeu. 9 avr. 2020 à 22:20, Alex Herbert a écrit : > > > > > On 9 Apr 2020, at 16:32, Gilles Sadowski wrote: > > > > > > > >> Given this I am thinking that using ZERO when possible is a better > >> option and avoid 0 / -1. > > > > Hmm, then I'm both +0 and -0 (which is the same, right?) > > on t

Re: [numbers] Fraction

> On 9 Apr 2020, at 16:32, Gilles Sadowski wrote: > > > >> Given this I am thinking that using ZERO when possible is a better >> option and avoid 0 / -1. > > Hmm, then I'm both +0 and -0 (which is the same, right?) > on this issue. ;-) Ironically the conversion to a double is a minor bug:

Re: [numbers] Fraction

> On 9 Apr 2020, at 16:32, Gilles Sadowski wrote: > > Le jeu. 9 avr. 2020 à 16:48, Alex Herbert > a écrit : >> >> >> On 09/04/2020 14:38, Gilles Sadowski wrote: >>> Le jeu. 9 avr. 2020 à 14:09, Alex Herbert a >>> écrit : On 09/04/2020 12:04, Alex

Re: [numbers] Fraction

Le jeu. 9 avr. 2020 à 16:48, Alex Herbert a écrit : > > > On 09/04/2020 14:38, Gilles Sadowski wrote: > > Le jeu. 9 avr. 2020 à 14:09, Alex Herbert a > > écrit : > >> > >> On 09/04/2020 12:04, Alex Herbert wrote: > > So if we are to support 0/-1 then I will add this to the standard test > >>

Re: [numbers] Fraction

On 09/04/2020 14:38, Gilles Sadowski wrote: Le jeu. 9 avr. 2020 à 14:09, Alex Herbert a écrit : On 09/04/2020 12:04, Alex Herbert wrote: So if we are to support 0/-1 then I will add this to the standard test cases to make sure it is correctly implemented. So I did this. No major functional

Re: [numbers] Fraction

Le jeu. 9 avr. 2020 à 14:09, Alex Herbert a écrit : > > > On 09/04/2020 12:04, Alex Herbert wrote: > > > >>> > >>> So if we are to support 0/-1 then I will add this to the standard test > >>> cases to make sure it is correctly implemented. > > So I did this. No major functionality failures. > > Ho

Re: [numbers] Fraction

On 09/04/2020 12:04, Alex Herbert wrote: So if we are to support 0/-1 then I will add this to the standard test cases to make sure it is correctly implemented. So I did this. No major functionality failures. However there is a discrepancy between multiply and other functions. Multiply wi

Re: [numbers] Fraction

Fowarded to ML due to a reply-to error. On 09/04/2020 11:52, Gilles Sadowski wrote: 2020-04-09 12:33 UTC+02:00, Alex Herbert : On 09/04/2020 10:54, Gilles Sadowski wrote: Hi. 2020-04-09 11:28 UTC+02:00, Alex Herbert : Two oddities in fraction: 1. Zero can be represented as 0 / 1 or 0 / -1

Re: [numbers] Fraction

2020-04-09 12:33 UTC+02:00, Alex Herbert : > > On 09/04/2020 10:54, Gilles Sadowski wrote: >> Hi. >> >> 2020-04-09 11:28 UTC+02:00, Alex Herbert : >>> Two oddities in fraction: >>> >>> 1. Zero can be represented as 0 / 1 or 0 / -1 >>> >>> I have not found any location where this manifest as a bug.

Re: [numbers] Fraction

On 09/04/2020 10:54, Gilles Sadowski wrote: Hi. 2020-04-09 11:28 UTC+02:00, Alex Herbert : Two oddities in fraction: 1. Zero can be represented as 0 / 1 or 0 / -1 I have not found any location where this manifest as a bug. :-) It is handled by the arithmetic and toString methods and the

Re: [numbers] Fraction

Hi. 2020-04-09 11:28 UTC+02:00, Alex Herbert : > Two oddities in fraction: > > 1. Zero can be represented as 0 / 1 or 0 / -1 > > I have not found any location where this manifest as a bug. :-) > It is > handled by the arithmetic and toString methods and the denominator is > not negated in the me

[numbers] Fraction

Two oddities in fraction: 1. Zero can be represented as 0 / 1 or 0 / -1 I have not found any location where this manifest as a bug. It is handled by the arithmetic and toString methods and the denominator is not negated in the method negate() and so negation of 0 / -1 returns the same value:

Re: [numbers-fraction] Double approximation constructor/factory method overhaul

Sure, no problem, thanks for letting me know! On 7/19/19 6:22 PM, Eric Barnhill wrote: I'm looking forward to reviewing your code within my limited knowledge, however I can't guarantee a quick time frame since Apache GSoC mentor milestones are due next week and I think that could get time consum

Re: [numbers-fraction] Double approximation constructor/factory method overhaul

I'm looking forward to reviewing your code within my limited knowledge, however I can't guarantee a quick time frame since Apache GSoC mentor milestones are due next week and I think that could get time consuming. Thanks for the contribution, Eric On Thu, Jul 18, 2019 at 4:13 PM Heinrich Bohne w

Re: [numbers-fraction] Double approximation constructor/factory method overhaul

So, I think the code I have so far is ripe for a pull request, so I submitted one. I changed the contracts of the epsilon and max-denominator factory methods, because the old specifications were not very useful, especially that of the max-denominator method – the only guarantee you could get from

Re: [numbers-fraction] Double approximation constructor/factory method overhaul

It just occured to me that you might have misunderstood my sentence: I am even more confused by your suggestion seeing as it was you who banned BigInteger from Fraction.addSub(Fraction, boolean) in https://issues.apache.org/jira/browse/NUMBERS-79  , which, even though you were not aware of it at

Re: [numbers-fraction] Double approximation constructor/factory method overhaul

The reason it was done was because Knuth proved (as in mathematical proof) that a long is insufficient for certain fraction multiplications where both numerator and denominator are large ints; 65 rather than 64 bits are necessary and a long will not suffice. You seem to have missed my comment in

Re: [numbers-fraction] Double approximation constructor/factory method overhaul

On Tue, Jul 16, 2019 at 2:41 PM Heinrich Bohne wrote: > > Do you think we really even need a BigFraction class at all in the > context > > of these upgrades? Or should one of the Fraction factory methods just > take > > BigInteger argumentsm and all fractions use the lazy dynamic method of > > ca

Re: [numbers-fraction] Double approximation constructor/factory method overhaul

Do you think we really even need a BigFraction class at all in the context of these upgrades? Or should one of the Fraction factory methods just take BigInteger argumentsm and all fractions use the lazy dynamic method of calculation you are proposing? I don't quite understand what you mean by th

Re: [numbers-fraction] Double approximation constructor/factory method overhaul

Sorry for the delay, I was on vacation. On Fri, Jul 5, 2019 at 2:09 PM Heinrich Bohne wrote: > Hello! > > I think a re-design of the factory method BigFraction.from(double, > double, int, int) is in order, because I see several problems with it: > > First, having a separate fraction class intend

Re: [numbers-fraction] Double approximation constructor/factory method overhaul

Hello Heinrich. Le ven. 5 juil. 2019 à 23:09, Heinrich Bohne a écrit : > > Hello! > > I think a re-design of the factory method BigFraction.from(double, > double, int, int) is in order, because I see several problems with it: > > First, having a separate fraction class intended to overcome the >

[numbers-fraction] Double approximation constructor/factory method overhaul

Hello! I think a re-design of the factory method BigFraction.from(double, double, int, int) is in order, because I see several problems with it: First, having a separate fraction class intended to overcome the limitations of the int range with a factory method (formerly a constructor) for approx

Re: [numbers-fraction] Documentation of fractions' reduction to lowest terms

Agreed, but it's not clear to me that it must be part of the public API. Yes, I admit that the public API doesn't really have anything to do with this, I realize that now. If my last email suggested otherwise, this was unintentional. On 7/1/19 11:52 PM, Gilles Sadowski wrote: Hello. Le lun.

Re: [numbers-fraction] Documentation of fractions' reduction to lowest terms

Hello. Le lun. 1 juil. 2019 à 20:23, Heinrich Bohne a écrit : > > > Is there a case where *not* knowing whether the fraction is reduced or > > not is detrimental? > > Hm, maybe you're right and specifying this (as well as where the sign is > stored) in the public API is not that important, as lon

Re: [numbers-fraction] Documentation of fractions' reduction to lowest terms

Is there a case where *not* knowing whether the fraction is reduced or not is detrimental? Hm, maybe you're right and specifying this (as well as where the sign is stored) in the public API is not that important, as long as the combination of returned numerator and denominator is valid. The only

Re: [numbers-fraction] Documentation of fractions' reduction to lowest terms

Hello. Le lun. 1 juil. 2019 à 12:35, Heinrich Bohne a écrit : > > > Couldn't it entail a loss of opportunity to allow "non-reduced" fractions > > for efficiency reason? > > Yes, it would, but I can't envision a scenario where this would be > detrimental. Of course, I may be missing something. Is

Re: [numbers-fraction] Documentation of fractions' reduction to lowest terms

Couldn't it entail a loss of opportunity to allow "non-reduced" fractions for efficiency reason? Yes, it would, but I can't envision a scenario where this would be detrimental. Of course, I may be missing something. But I don't follow; if it's an implementation detail, it should not appear any

Re: [numbers-fraction] Documentation of fractions' reduction to lowest terms

Hi. Le lun. 1 juil. 2019 à 03:52, Heinrich Bohne a écrit : > > I've recently been wondering about the following: > > With the resolution of NUMBERS-119 > (https://issues.apache.org/jira/browse/NUMBERS-119), all constructors in > Fraction and BigFraction reduce the created fraction to lowest terms

[numbers-fraction] Documentation of fractions' reduction to lowest terms

I've recently been wondering about the following: With the resolution of NUMBERS-119 (https://issues.apache.org/jira/browse/NUMBERS-119), all constructors in Fraction and BigFraction reduce the created fraction to lowest terms (in the constructor Fraction(double, double, int, int), this is not ob

Re: [numbers-fraction] Code duplication between FractionTest and BigFractionTest

I've created a pull request: https://github.com/apache/commons-numbers/pull/55 This pull request exterminates most the code duplication between the two classes. There is still some duplication left, most notably in the method testDigitLimitConstructor(), but I've found out that the Fraction(doubl

Re: [numbers-fraction] Code duplication between FractionTest and BigFractionTest

> > > If additional context is required it fails to meet the definition of > > a unit test and is instead an integration test, and the function being > > tested may require rethinking. > > Depends what you define as a unit test. I'd say the unit was BigFraction > or Fraction. An integration test i

Re: Re: Re: Re: [numbers-fraction] Code duplication between FractionTest and BigFractionTest

By the way, I've worked a bit on the draft in the meantime and pushed the changes I've made so far, in case anyone is interested in (re-)viewing them. Here's the link to the branch again: https://github.com/Schamschi/commons-numbers/tree/FractionCommonTestCases On 6/20/19 6:13 PM, Heinrich Bohne

Re: Re: Re: [numbers-fraction] Code duplication between FractionTest and BigFractionTest

Hello Eric, I'm not sure if I understand what you mean by "context" when you say that all context has to be within the unit test.Do you mean that the test should not rely on the functionality of other modules/methods/"units" than the one to be tested? If so, I agree with you, but I don't think th

Re: [numbers-fraction] Code duplication between FractionTest and BigFractionTest

On 20/06/2019 16:07, Eric Barnhill wrote: Sorry for the slow reply, I thought I sent this yesterday. I agree from a code architecture standpoint such a refactoring makes sense. However from the perspective of unit tests it makes it no longer a unit test. It is still testing a unit. Just the test

Re: Re: [numbers-fraction] Code duplication between FractionTest and BigFractionTest

Sorry for the slow reply, I thought I sent this yesterday. I agree from a code architecture standpoint such a refactoring makes sense. However from the perspective of unit tests it makes it no longer a unit test. IIUC it's best practice for a unit test that all context be within the test. If addi

Re: Re: [numbers-fraction] Code duplication between FractionTest and BigFractionTest

A quick looks shows that the BigFractionTest does have test cases for very large numbers. However the add, subtract, divide and multiply tests and a few others just use values that would work with Fraction. Possibly these can be moved to a shared common tests location too. That's what I was t

Re: [numbers-fraction] Code duplication between FractionTest and BigFractionTest

> On 20 Jun 2019, at 00:54, Heinrich Bohne wrote: > > An awful lot of code is duplicated between FractionTest and > BigFractionTest. Often, the test cases in the two classes only differ in > the types they use (e.g. Fraction vs. BigFraction), but the actual > values the tests use are the same.

[numbers-fraction] Code duplication between FractionTest and BigFractionTest

An awful lot of code is duplicated between FractionTest and BigFractionTest. Often, the test cases in the two classes only differ in the types they use (e.g. Fraction vs. BigFraction), but the actual values the tests use are the same. I think this could be mitigated by adding a new class that sto

Re: [numbers][fraction] pulling fraction-dev into master

Changed are merged; in particular the travis updates were kept; if you are working on Fraction kindly rebase. On Wed, Jun 5, 2019 at 3:40 PM Eric Barnhill wrote: > For some months I worked on the Fraction class on a fraction-dev branch, > now others are furthering it, but IIUC working off of mas

[numbers][fraction] pulling fraction-dev into master

For some months I worked on the Fraction class on a fraction-dev branch, now others are furthering it, but IIUC working off of master, plus it sounds like my edits are out of date in other ways. So within the next day, I will pull fraction-dev into master. I would request any other contributors co

[numbers-fraction] of() methods for BigFraction - take BigInteger only, or include long and int?

Almost done with Fraction here. Fraction() operates with int inputs only, due to the mathematical limitations of the fast algorithm, so of() methods only need to handle int inputs. But what about BigFraction()? Right now the of() methods handle BigIngeters only. Do we want to expand this so a Big

Re: [numbers-fraction] merging changes

Last commit I made to "commons-numbers-fraction", more than 3 months ago, is: ---CUT--- commit d0cff0d8f2a249e6c87df323fe635386749f62f4 Author: Gilles Sadowski Date: Mon Dec 17 12:59:24 2018 +0100 NUMBERS-83: Replace calls to JDK deprecated API. ---CUT--- So I've no

[numbers-fraction] merging changes

I'm rebasing fraction to master and the next merge is looking tricky. Gilles, am I correct that you have added an interface and some methods to Fraction, and pushed this to master? But master does not yet have the of() and from() method name changes that we discussed while my branch does, also my b

Re: [numbers-fraction] Maven surefire plugin error

Rebasing on master fixed the problem, thank you. On Mon, Mar 4, 2019 at 3:39 PM Gilles Sadowski wrote: > > > I'd recommend that you regularly rebase from "master". > > Regards, > Gilles > > > > > > Here is an excerpt of the exception trace (from running "mvn -e test"): > > > ---CUT--- > > > Caus

Re: [numbers-fraction] Maven surefire plugin error

fire plugin, but don't see it listed > >> as a dependency in numbers-fraction or numbers-core. I see it listed in > >> numbers-parent, but with no version number. Any ideas what I need to do to > >> get the tests running again? > > > > Version is probably

Re: [numbers-fraction] Maven surefire plugin error

> On 4 Mar 2019, at 23:10, Gilles Sadowski wrote: > > Hi. > > Le lun. 4 mars 2019 à 23:21, Eric Barnhill a écrit : >> >> I am getting a maven error for the surefire plugin, but don't see it listed >> as a dependency in numbers-fraction or numbers-core

Re: [numbers-fraction] Maven surefire plugin error

Hi. Le lun. 4 mars 2019 à 23:21, Eric Barnhill a écrit : > > I am getting a maven error for the surefire plugin, but don't see it listed > as a dependency in numbers-fraction or numbers-core. I see it listed in > numbers-parent, but with no version number. Any ideas what I ne

Re: [numbers-fraction] Maven surefire plugin error

r 2019, at 22:21, Eric Barnhill wrote: > > I am getting a maven error for the surefire plugin, but don't see it listed > as a dependency in numbers-fraction or numbers-core. I see it listed in > numbers-parent, but with no version number. Any ideas what I need to do to > get the

[numbers-fraction] Maven surefire plugin error

I am getting a maven error for the surefire plugin, but don't see it listed as a dependency in numbers-fraction or numbers-core. I see it listed in numbers-parent, but with no version number. Any ideas what I need to do to get the tests running again? I also get this error with other nu

Re: [numbers] Fraction() and Knuth 4.5.1 -- overflow, BigInteger, long, and rounding

Hi Eric. On Mon, 3 Dec 2018 10:01:39 -0800, Eric Barnhill wrote: Does this mean that computations can "unpredictably" overflow (or throw an exception)? The ArithmeticUtils() methods mulAndCheck and addAndCheck throw exceptions if there is overflow during primitive operations. That is the "

Re: [numbers] Fraction() and Knuth 4.5.1 -- overflow, BigInteger, long, and rounding

> > > Does this mean that computations can "unpredictably" overflow > (or throw an exception)? > The ArithmeticUtils() methods mulAndCheck and addAndCheck throw exceptions if there is overflow during primitive operations. That is the "check" part of the method name. > Is it acceptable, or should

Re: [numbers] Fraction() and Knuth 4.5.1 -- overflow, BigInteger, long, and rounding

l section that points out Knuth and how we may want to change things as a hint or request to contributors. Gary On Wed, Nov 7, 2018 at 10:52 AM Eric Barnhill wrote: > I read Kunth's "Art of Computer Programming 4.5.1" that is referenced many > times in the doc as the guida

Re: [numbers] Fraction() and Knuth 4.5.1 -- overflow, BigInteger, long, and rounding

gt; >> Gary >> >> On Wed, Nov 7, 2018 at 10:52 AM Eric Barnhill >> wrote: >> >> > I read Kunth's "Art of Computer Programming 4.5.1" that is referenced >> many >> > times in the doc as the guidance for the commons-math/commons-num

Re: [numbers] Fraction() and Knuth 4.5.1 -- overflow, BigInteger, long, and rounding

that is referenced > many > > times in the doc as the guidance for the commons-math/commons-numbers > > Fraction class. It is an interesting read. Also, for all the times it is > > cited in the doc, it is interesting that Fraction doesn't really use it > as > >

Re: [numbers] Fraction() and Knuth 4.5.1 -- overflow, BigInteger, long, and rounding

ot;Art of Computer Programming 4.5.1" that is referenced many > times in the doc as the guidance for the commons-math/commons-numbers > Fraction class. It is an interesting read. Also, for all the times it is > cited in the doc, it is interesting that Fraction doesn't really

Re: [numbers] Fraction() and Knuth 4.5.1 -- overflow, BigInteger, long, and rounding

Hi. On Wed, 7 Nov 2018 09:52:30 -0800, Eric Barnhill wrote: I read Kunth's "Art of Computer Programming 4.5.1" that is referenced many times in the doc as the guidance for the commons-math/commons-numbers Fraction class. It is an interesting read. Also, for all the times it

[numbers] Fraction() and Knuth 4.5.1 -- overflow, BigInteger, long, and rounding

I read Kunth's "Art of Computer Programming 4.5.1" that is referenced many times in the doc as the guidance for the commons-math/commons-numbers Fraction class. It is an interesting read. Also, for all the times it is cited in the doc, it is interesting that Fraction doesn