to a completely different
problem than the one I described, which is that the /arguments/ should
be treated as unsigned integers, not the result.
On 7/20/19 2:30 PM, Alex Herbert wrote:
On 20 Jul 2019, at 10:53, Heinrich Bohne wrote:
I have suggestion regarding what to do with the special cases
I have suggestion regarding what to do with the special cases
Integer.MIN_VALUE and Long.MIN_VALUE in the methods from ArithmeticUtils
that calculate the greatest common divisor of two ints or longs.
Currently, these methods throw an ArithmeticException if the GCD of the
arguments is 2^31 or
consuming.
Thanks for the contribution,
Eric
On Thu, Jul 18, 2019 at 4:13 PM Heinrich Bohne
wrote:
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
.
On 7/17/19 10:20 AM, Heinrich Bohne wrote:
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
7/17/19 10:10 AM, Heinrich Bohne wrote:
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.
with and without my suggested alterations.
On 7/17/19 2:29 AM, Eric Barnhill wrote:
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
ate approximation.
On 7/16/19 6:52 PM, Eric Barnhill wrote:
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:
Fi
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
Alex Herbert wrote:
On 03/07/2019 12:00, Heinrich Bohne wrote:
I think we are talking about two completely different issues here. I am
aware that 2 of my newly introduced lines (the IllegalArgumentException
cases you mentioned) are not covered. These are argument validations
inside private
so my pull request did
uncover these lines in BigFraction.toString(), contrary to what the
Coverall report says.
Excuse me, of course it should be "my pull request did *not*
uncover these lines"
On 7/3/19 1:00 PM, Heinrich Bohne wrote:
I think we are talking about two completely
/apache/commons/numbers/fraction/BigFraction.java#L1127
(the current master version)
On 7/3/19 12:32 PM, Alex Herbert wrote:
On 03/07/2019 10:35, Heinrich Bohne wrote:
But the detailed report you linked to is exactly where I got the
information about what existing lines have (purportedly) been
"COVERAGE CHANGED",
but it doesn't actually report any change in coverage, so maybe this has
something to do with the bug.
On 7/3/19 11:19 AM, Alex Herbert wrote:
On 3 Jul 2019, at 09:38, Heinrich Bohne wrote:
So this is the second time this happens to me. I've submitted a pull
reque
So this is the second time this happens to me. I've submitted a pull
request ( https://github.com/apache/commons-numbers/pull/63 ), and the
Coveralls reports says that several existing lines have been uncovered,
which is a lie, because the lines purportedly "uncovered" were already
not covered in
. 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 long as the
combination
more important in Fraction than in BigFraction,
because the magnitude of the values stored in these fields has an impact
on whether arithmetic operations overflow or don't.
On 7/1/19 7:03 PM, Gilles Sadowski wrote:
Hello.
Le lun. 1 juil. 2019 à 12:35, Heinrich Bohne a écrit :
Couldn't it entail
if I'm
not mistaken, is currently only specified in
Fraction.getReducedFraction(int, int), a method that is targeted for
deletion in https://issues.apache.org/jira/browse/NUMBERS-125 ).
On 7/1/19 9:32 AM, Gilles Sadowski wrote:
Hi.
Le lun. 1 juil. 2019 à 03:52, Heinrich Bohne a écrit :
I've rec
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
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
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
test, and the function being
tested may require rethinking.
This results in unit tests often being clunkily and awkwardly coded, but I
think it is the way they are typically written and it has its reasons.
So I am +0 .
On Thu, Jun 20, 2019, 02:01 Heinrich Bohne wrote:
A quick looks shows that
was thinking too – the draft was by no means intended to be
complete, I just created it to give a general idea of how I would go about
implementing this. I'll work some more on it before I create an actual pull
request.
On 6/20/19 10:40 AM, Alex Herbert wrote:
On 20 Jun 2019, at 00:54, Heinrich
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
Hello,
Not that I'm aware of, so I created one:
https://issues.apache.org/jira/browse/NUMBERS-115. I hope I included the
reference to the pull request the correct way.
On 6/18/19 1:31 PM, Gilles Sadowski wrote:
Hi.
Le lun. 17 juin 2019 à 00:03, Heinrich Bohne a écrit :
I made some
, Heinrich Bohne wrote:
Grimreaper and I finished work on the migration to JUnit 5 in the pull
request https://github.com/apache/commons-numbers/pull/48 , so the pull
request is ready for review.
-
To unsubscribe, e-mail: dev-unsubscr
Grimreaper and I finished work on the migration to JUnit 5 in the pull
request https://github.com/apache/commons-numbers/pull/48 , so the pull
request is ready for review.
-
To unsubscribe, e-mail:
Gary
On Wed, Jun 12, 2019 at 9:00 AM Heinrich Bohne
wrote:
I have been asked to request some feedback on this pull request:
https://github.com/apache/commons-numbers/pull/36– specifically, about
the introduction of code blocks in the commit "NUMBERS-100: Reduce scope
of local variables&q
Sorry, I messed up the link to the pull request:
https://github.com/apache/commons-numbers/pull/36
On 6/12/19 3:00 PM, Heinrich Bohne wrote:
I have been asked to request some feedback on this pull request:
https://github.com/apache/commons-numbers/pull/36– specifically, about
the introduction
I have been asked to request some feedback on this pull request:
https://github.com/apache/commons-numbers/pull/36– specifically, about
the introduction of code blocks in the commit "NUMBERS-100: Reduce scope
of local variables".
I had the idea with the code blocks when I wanted to add a test to
The class ArithmeticUtils in the commons-numbers-core module contains
several methods where, since Java 8, equivalent methods in
java.lang.Math exist. These methods are the following:
addAndCheck(int, int)
addAndCheck(long, long)
mulAndCheck(int, int)
mulAndCheck(long, long)
subAndCheck(int,
cts at work. It was
straightforward.
I vote for a clean cut, as well.
s/Before/BeforeEach/
s/After/AfterEach
and you are halfway through.
Sven
Gesendet: Montag, 27. Mai 2019 um 07:28 Uhr
Von: "Eitan Adler"
An: "Heinrich Bohne"
Cc: "Commons Developers List"
Betreff
I have been advised to raise this improvement suggestion on the
developers' mailing list. It is about the trial division algorithm in
the method SmallPrimes.boundedTrialDivision(int, int, List) in
the primes module. Currently, this algorithm skips multiples of 2 and 3
as trial candidates, which
ds,
Gilles
On Wed, 22 May 2019 at 15:30, Eric Barnhill wrote:
> +1
>
> On Wed, May 22, 2019 at 3:15 PM Gilles Sadowski
> wrote:
>
> > Hi.
> >
> > Le mer. 22 mai 2019 à 18:43, Heinrich Bohne
a
> > écrit :
> > >
> > > Right now, commons-nu
Right now, commons-numbers is using JUnit 4.12, the last stable version
of JUnit 4. As far as I am aware, there is no explicit syntax in JUnit
4.12 for testing whether an exception is thrown apart from either using
the deprecated class ExpectedException or adding the "expected"
parameter to the
33 matches
Mail list logo
