Re: [numbers] Bug in complex multiply + divide + isNaN

> On 7 Nov 2019, at 17:31, Eric Barnhill wrote: > > […] > > Well that's interesting, I did not see that the standard specified > all-vs-all methods in all those cases. There isn't a performance gain for > multiplying by an imaginary double like there is for a real double, Not for imaginary

Re: [numbers] Bug in complex multiply + divide + isNaN

> On 7 Nov 2019, at 17:31, Eric Barnhill wrote: > > On Thu, Nov 7, 2019 at 3:59 AM Alex Herbert > wrote: > >> >> There is a matrix for real/imaginary/complex all-vs-all additive and >> multiplicative operators in the standard (tables in G.5.1 and G.5.2). >> The question is do we want to

Re: [numbers] Bug in complex multiply + divide + isNaN

On Thu, Nov 7, 2019 at 3:59 AM Alex Herbert wrote: > > There is a matrix for real/imaginary/complex all-vs-all additive and > multiplicative operators in the standard (tables in G.5.1 and G.5.2). > The question is do we want to support the entire matrix: > > Covered: > >

Re: [numbers] Bug in complex multiply + divide + isNaN

Le jeu. 7 nov. 2019 à 12:59, Alex Herbert a écrit : > > > On 07/11/2019 11:45, Gilles Sadowski wrote: > > Hello. > > > >>> [...] > >>> > Also looking at Complex it would benefit from: > > public Complex subtractFrom(double minuend) { > return new Complex(minuend -

Re: [numbers] Bug in complex multiply + divide + isNaN

On 07/11/2019 11:45, Gilles Sadowski wrote: Hello. [...] Also looking at Complex it would benefit from: public Complex subtractFrom(double minuend) { return new Complex(minuend - real, imaginary); } Is it part of the "standard"? IMHO, it's fairly confusing, as nothing in

Re: [numbers] Bug in complex multiply + divide + isNaN

Hello. > > [...] > > > >> > >> Also looking at Complex it would benefit from: > >> > >>public Complex subtractFrom(double minuend) { > >>return new Complex(minuend - real, imaginary); > >>} > > > > Is it part of the "standard"? > > IMHO, it's fairly confusing, as nothing in the

Re: [numbers] Bug in complex multiply + divide + isNaN

Hi. Le jeu. 7 nov. 2019 à 01:48, Alex Herbert a écrit : > > > > > On 7 Nov 2019, at 00:34, Gilles Sadowski wrote: > > > > 2019-11-07 1:03 UTC+01:00, Alex Herbert > >: > >> > >> > >>> On 6 Nov 2019, at 23:17, Eric Barnhill >>> >

Re: [numbers] Bug in complex multiply + divide + isNaN

> On 7 Nov 2019, at 00:28, Gilles Sadowski wrote: > > 2019-11-06 23:38 UTC+01:00, Alex Herbert >: >> >> >>> On 6 Nov 2019, at 18:17, Gilles Sadowski wrote: >>> [...] Any objections to updating multiply/divide/isNaN to match the

Re: [numbers] Bug in complex multiply + divide + isNaN

> On 7 Nov 2019, at 00:34, Gilles Sadowski wrote: > > 2019-11-07 1:03 UTC+01:00, Alex Herbert >: >> >> >>> On 6 Nov 2019, at 23:17, Eric Barnhill >> > wrote: >>> >>> +1 on all suggestions. Thanks, Alex. >> >> I’ve borrowed

Re: [numbers] Bug in complex multiply + divide + isNaN

2019-11-07 1:03 UTC+01:00, Alex Herbert : > > >> On 6 Nov 2019, at 23:17, Eric Barnhill wrote: >> >> +1 on all suggestions. Thanks, Alex. > > I’ve borrowed the checkstyle, PMD and spot bugs config from commons-rng. I > updated the parent to 49 and updated the travis build script to run the >

Re: [numbers] Bug in complex multiply + divide + isNaN

2019-11-06 23:38 UTC+01:00, Alex Herbert : > > >> On 6 Nov 2019, at 18:17, Gilles Sadowski wrote: >> >>> [...] >>> >>> >>> Any objections to updating multiply/divide/isNaN to match the standard? >> >> Let me think... ;-) > > OK, I’ll fix it and double check the other tests against the c

Re: [numbers] Bug in complex multiply + divide + isNaN

> On 6 Nov 2019, at 23:17, Eric Barnhill wrote: > > +1 on all suggestions. Thanks, Alex. I’ve borrowed the checkstyle, PMD and spot bugs config from commons-rng. I updated the parent to 49 and updated the travis build script to run the check goal instead of creating reports. This requires

Re: [numbers] Bug in complex multiply + divide + isNaN

+1 on all suggestions. Thanks, Alex. On Wed, Nov 6, 2019 at 2:38 PM Alex Herbert wrote: > > > > On 6 Nov 2019, at 18:17, Gilles Sadowski wrote: > > > >> [...] > >> > >> > >> Any objections to updating multiply/divide/isNaN to match the standard? > > > > Let me think... ;-) > > OK, I’ll fix it

Re: [numbers] Bug in complex multiply + divide + isNaN

> On 6 Nov 2019, at 18:17, Gilles Sadowski wrote: > >> [...] >> >> >> Any objections to updating multiply/divide/isNaN to match the standard? > > Let me think... ;-) OK, I’ll fix it and double check the other tests against the c reference. > >> >> I'll add unit tests to hit the edge

Re: [numbers] Bug in complex multiply + divide + isNaN

> [...] > > > Any objections to updating multiply/divide/isNaN to match the standard? Let me think... ;-) > > I'll add unit tests to hit the edge cases that should fail with the > current implementation. Thanks, Gilles > > > [1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf > > [2]

[numbers] Bug in complex multiply + divide + isNaN

The method Complex::multiply(Complex) has the following check to recover infinities:     double x = ac - bd;     double y = ad + bc;     if (Double.isNaN(a) && Double.isNaN(b)) { The divide method checks x and y:     double x = Math.scalb( (a*c + b*d) / denom, -ilogbw);