Re: [Numbers] Arrays of "Complex" objects and RAM

[Alex Herbert]

> On 6 Nov 2019, at 18:08, Gilles Sadowski  wrote:
> 
> Hi.
> 
 [...]
>>> 
>>> public class ComplexArray {
>>> private final MultidimensionalCounter counter;
>>> // ...
>>> 
>>> public ComplexArray(int... dimensions) {
>>> counter = new MultidimensionalCounter(dimensions);
>>> data = new data[counter.getSize()];
>>> }
>>> 
>>> /**
>>>  * @param indices Storage location.
>>>  * @return the complex number stored at the given location.
>>>  */
>>> public Complex get(int... indices) {
>>> return data[counter.getCount(indices)];
>>> }
>>> }
>>> 
>>> Or perhaps the data cube should be an additional abstraction on top of
>>> "ComplexArray" (?).
>> I think adding the abstraction on top is easier.
>> 
>> Array can be renamed to Collection/List? Thus the count is the only
>> thing that matters, and optionally a constant time access get(int index)
>> method.
> 
> +1
> 
>> 
>> This can later be reshaped to a Matrix representation using the
>> MultidimensionalCounter pattern.
>> 
>> We have two use cases:
>> 
>> 1. You know the final count of Complex objects
>> 2. You do not know the count of Complex objects
>> 
>> Use case 2 is used in streams where the ComplexList must be expandable
>> for use as a collector. This can be satisfied with a constructor with an
>> initial capacity. The ComplexList would thus offer a specialisation of
>> ArrayList by storing the Complex objects using primitive array(s).
>> 
>> Use case 2 rules out the possibility of immutability. This is the type
>> of functionality under discussion and could be served using an interface
>> to allow different implementations:
>> 
>> public interface ComplexList {
>> [...]
>> }
> 
> +1
> 
>> This could be separated to put the set and add methods in a
>> sub-interface allowing the top level interface to be an immutable object.
> 
> Perhaps better to follow the JDK convention and provide a
>public static ComplexList unmodifiableList(ComplexList delegate)
> method.
> 
>> However the apply functions currently are specified using Complex.
>> Efficiency would be gained using primitive specialisations for operating
>> on 1 or 2 complex numbers and outputting the results to a provided consumer:
>> 
>> public interface ComplexProvider {
>> /**
>>  * Gets the real component of the complex number.
>>  *
>>  * @return the real component
>>  */
>> double getReal();
>> 
>> /**
>>  * Gets the imaginary component of the complex number.
>>  *
>>  * @return the imaginary component
>>  */
>> double getImaginary();
>> }
>> 
>> public interfaceComplexProvider {
>> /**
>>  * Accept the components of the complex number.
>>  * Optionally return a new ComplexProvider with the components.
>>  *
>>  * @param real the real
>>  * @param imaginary the imaginary
>>  * @return the complex provider (or null)
>>  */
>> ComplexProvider accept(double real, double imaginary);
>> }
> 
> What is gained wrt using "Complex" instances directly?

The above is a typo. The accept method should be in a ComplexConsumer interface.

If the data is in a primitive array you would like to be able to access it, and 
then set it back to the same array or a different array without going through 
creation of a Complex for each (real, imaginary) pair. So the ComplexProvider 
and ComplexConsumer provide an input and output for any function that changes 
the complex data. I’ve made it a bit more complicated with the ComplexConsumer 
returning a ComplexProvider just to allow all the methods in Complex to be 
rewritten to provide static methods that can use these interfaces.

A simpler approach is for the ComplexList to allow modification in-place by 
providing a list cursor that can traverse the list (like an iterator) and also 
skip to positions. It would allow get and set of the data at the current 
position. This cursor could be used by another class to apply functions in 
place to the data. The functions could be a user specified generic function 
using the ComplexFunction interface I suggested.

I think that performance would have to be assessed for various prototypes. Some 
of the methods in Complex have a lot of work. So the creation of a Complex for 
each position may not be a big overhead allowing a stream approach to build a 
custom process pipeline which is then collected into a new list at the end. For 
operations that are fast such as negate, add, subtract, conjugate these would 
be easy to code into the ComplexList to operate directly on the data array. 

> 
>> [...]
>> 
>> Unfortunately processing the stream as encountered may result in out of
>> order elements if parallelisation occurs so the results may not be
>> collected back in the same order.
> 
> IIUC, this would be a non-starter for the data cube abstraction.
> 
>> Here there are 

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

[Alex Herbert]

> 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 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 cases that should fail with the
 current implementation.
>>> 
>>> Thanks,
>>> Gilles
>> 
>> Are changes to numbers going under Jira tickets?
> 
> There is a JIRA project:
>https://issues.apache.org/jira/projects/NUMBERS 
> 
> for reference in the git commit (for non-trivial changes).
> 
> But we don't really keep track (no "changes.xml") until the first
> official release (getting close now, I hope...).
> 
>> 
>> It looks like it needs an update to checkstyle, PMD, spotbugs, the
>> commons-parent and travis.
> 
> Yes.  I try to copy from or refer to Commons RNG.
> 
>> Checkstyle config from commons-rng finds:
>> 
>> [INFO] There are 115 errors reported by Checkstyle 8.20 with
>> /Users/ah403/git/commons-numbers/commons-numbers-core/../src/main/resources/checkstyle/checkstyle.xml
>> ruleset.
>> [INFO] There are 202 errors reported by Checkstyle 8.20 with
>> /Users/ah403/git/commons-numbers/commons-numbers-complex/../src/main/resources/checkstyle/checkstyle.xml
>> ruleset.
>> [INFO] There are 102 errors reported by Checkstyle 8.20 with
>> /Users/ah403/git/commons-numbers/commons-numbers-complex-streams/../src/main/resources/checkstyle/checkstyle.xml
>> ruleset.
>> [INFO] There are 276 errors reported by Checkstyle 8.20 with
>> /Users/ah403/git/commons-numbers/commons-numbers-primes/../src/main/resources/checkstyle/checkstyle.xml
>> ruleset.
>> [INFO] There are 68 errors reported by Checkstyle 8.20 with
>> /Users/ah403/git/commons-numbers/commons-numbers-quaternion/../src/main/resources/checkstyle/checkstyle.xml
>> ruleset.
>> [INFO] There are 289 errors reported by Checkstyle 8.20 with
>> /Users/ah403/git/commons-numbers/commons-numbers-fraction/../src/main/resources/checkstyle/checkstyle.xml
>> ruleset.
>> [INFO] There are 10 errors reported by Checkstyle 8.20 with
>> /Users/ah403/git/commons-numbers/commons-numbers-angle/../src/main/resources/checkstyle/checkstyle.xml
>> ruleset.
>> [INFO] There are 3503 errors reported by Checkstyle 8.20 with
>> /Users/ah403/git/commons-numbers/commons-numbers-gamma/../src/main/resources/checkstyle/checkstyle.xml
>> ruleset.
>> [INFO] There are 56 errors reported by Checkstyle 8.20 with
>> /Users/ah403/git/commons-numbers/commons-numbers-combinatorics/../src/main/resources/checkstyle/checkstyle.xml
>> ruleset.
>> [INFO] There are 50 errors reported by Checkstyle 8.20 with
>> /Users/ah403/git/commons-numbers/commons-numbers-arrays/../src/main/resources/checkstyle/checkstyle.xml
>> ruleset.
>> [INFO] There are 10 errors reported by Checkstyle 8.20 with
>> /Users/ah403/git/commons-numbers/commons-numbers-field/../src/main/resources/checkstyle/checkstyle.xml
>> ruleset.
>> [INFO] There are 4 errors reported by Checkstyle 8.20 with
>> /Users/ah403/git/commons-numbers/commons-numbers-rootfinder/../src/main/resources/checkstyle/checkstyle.xml
>> ruleset.
>> 
>> The mass of errors is white space style in the test classes.
> 
> The bulk of the tests was ported from Commons Math where
> CheckStyle was not enforced for unit test classes.
> 
>> Without the
>> test classes the result is:
>> 
>> [INFO] There are 12 errors reported by Checkstyle 8.20 with
>> /Users/ah403/git/commons-numbers/commons-numbers-core/../src/main/resources/checkstyle/checkstyle.xml
>> ruleset.
>> [INFO] There are 54 errors reported by Checkstyle 8.20 with
>> /Users/ah403/git/commons-numbers/commons-numbers-complex/../src/main/resources/checkstyle/checkstyle.xml
>> ruleset.
>> [INFO] There are 19 errors reported by Checkstyle 8.20 with
>> /Users/ah403/git/commons-numbers/commons-numbers-complex-streams/../src/main/resources/checkstyle/checkstyle.xml
>> ruleset.
>> [INFO] There are 49 errors reported by Checkstyle 8.20 with
>> /Users/ah403/git/commons-numbers/commons-numbers-primes/../src/main/resources/checkstyle/checkstyle.xml
>> ruleset.
>> [INFO] There are 5 errors reported by Checkstyle 8.20 with
>> /Users/ah403/git/commons-numbers/commons-numbers-quaternion/../src/main/resources/checkstyle/checkstyle.xml
>> ruleset.
>> [INFO] There are 6 errors reported by Checkstyle 8.20 with
>> /Users/ah403/git/commons-numbers/commons-numbers-fraction/../src/main/resources/checkstyle/checkstyle.xml
>> ruleset.
>> [INFO] There are 3 errors reported by Checkstyle 8.20 with
>> /Users/ah403/git/commons-numbers/commons-numbers-angle/../src/main/resources/checkstyle/checkstyle.xml
>> ruleset.
>> [INFO] There are 20 errors reported by Checkstyle 8.20 with
>> 

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

[Alex Herbert]

> 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 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.
> 
> I had updated the PMD configuration (copying from [RNG] and removing
> references to specific classes) this afternoon.

I did not really change the PMD config. Just a bump of the PMD versions.

However pmd:check was never run so this is now in the default goal and run on 
travis.

Travis currently has a problem with the length of the log file being too long 
as Maven downloads the entire internet. So I’m trying a fix for that.

> 
>> 
>> This requires disabling checkstyle:check and pmd:check from failing.
>> Checkstyle errors were previously listed. PMD has the following errors:
>> 
>> [INFO] You have 23 PMD violations. For more details see:
>> /Users/ah403/git/commons-numbers/commons-numbers-core/target/pmd.xml
>> [INFO] You have 16 PMD violations. For more details see:
>> /Users/ah403/git/commons-numbers/commons-numbers-complex/target/pmd.xml
>> [INFO] You have 30 PMD violations. For more details see:
>> /Users/ah403/git/commons-numbers/commons-numbers-complex-streams/target/pmd.xml
>> [INFO] You have 30 PMD violations. For more details see:
>> /Users/ah403/git/commons-numbers/commons-numbers-primes/target/pmd.xml
>> [INFO] You have 13 PMD violations. For more details see:
>> /Users/ah403/git/commons-numbers/commons-numbers-quaternion/target/pmd.xml
>> [INFO] You have 42 PMD violations. For more details see:
>> /Users/ah403/git/commons-numbers/commons-numbers-fraction/target/pmd.xml
>> [INFO] You have 3 PMD violations. For more details see:
>> /Users/ah403/git/commons-numbers/commons-numbers-angle/target/pmd.xml
>> [INFO] You have 192 PMD violations. For more details see:
>> /Users/ah403/git/commons-numbers/commons-numbers-gamma/target/pmd.xml
>> [INFO] You have 35 PMD violations. For more details see:
>> /Users/ah403/git/commons-numbers/commons-numbers-combinatorics/target/pmd.xml
>> [INFO] You have 14 PMD violations. For more details see:
>> /Users/ah403/git/commons-numbers/commons-numbers-arrays/target/pmd.xml
>> [INFO] You have 10 PMD violations. For more details see:
>> /Users/ah403/git/commons-numbers/commons-numbers-field/target/pmd.xml
>> [INFO] You have 1 PMD violation. For more details see:
>> /Users/ah403/git/commons-numbers/commons-numbers-rootfinder/target/pmd.xml
> 
> Yes, those should be fixed (and perhaps some could be considered
> as false positives).

I’m not planning on doing a lot of fixing. With RNG I made most of the PMD 
issues go away with some rule tweaking.

I will fix checkstyle though. This can be semi automated.

> 
>> 
>> A simple fix for apache-rat:check and spotbugs:check was needed.
>> 
>> Javadoc:javadoc builds on JDK 11 which is strict so that is good.
>> 
>> All the changes are in a PR which passes 'mvn test site’. If travis is OK
>> I’ll merge to master and then set to fixing checkstyle and PMD.
>> 
>> Then I’ll fix Complex.
> 
> OK.
> 
> Regards,
> Gilles
> 
>> 
>>> 
>>> 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 and double check the other tests against the c
 reference.
 
> 
>> 
>> I'll add unit tests to hit the edge cases that should fail with the
>> current implementation.
> 
> Thanks,
> Gilles
 
 Are changes to numbers going under Jira tickets?
 
 It looks like it needs an update to checkstyle, PMD, spotbugs, the
 commons-parent and travis.
 
 Checkstyle config from commons-rng finds:
 
 [INFO] There are 115 errors reported by Checkstyle 8.20 with
 /Users/ah403/git/commons-numbers/commons-numbers-core/../src/main/resources/checkstyle/checkstyle.xml
 ruleset.
 [INFO] There are 202 errors reported by Checkstyle 8.20 with
 /Users/ah403/git/commons-numbers/commons-numbers-complex/../src/main/resources/checkstyle/checkstyle.xml
 ruleset.
 [INFO] There are 102 errors reported by Checkstyle 8.20 with
 /Users/ah403/git/commons-numbers/commons-numbers-complex-streams/../src/main/resources/checkstyle/checkstyle.xml
 ruleset.
 [INFO] There are 276 errors reported by Checkstyle 8.20 with
 /Users/ah403/git/commons-numbers/commons-numbers-primes/../src/main/resources/checkstyle/checkstyle.xml
 ruleset.
 [INFO] There are 68 errors reported by Checkstyle 8.20 with
 

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

[Gilles Sadowski]

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
> check goal instead of creating reports.

I had updated the PMD configuration (copying from [RNG] and removing
references to specific classes) this afternoon.

>
> This requires disabling checkstyle:check and pmd:check from failing.
> Checkstyle errors were previously listed. PMD has the following errors:
>
> [INFO] You have 23 PMD violations. For more details see:
> /Users/ah403/git/commons-numbers/commons-numbers-core/target/pmd.xml
> [INFO] You have 16 PMD violations. For more details see:
> /Users/ah403/git/commons-numbers/commons-numbers-complex/target/pmd.xml
> [INFO] You have 30 PMD violations. For more details see:
> /Users/ah403/git/commons-numbers/commons-numbers-complex-streams/target/pmd.xml
> [INFO] You have 30 PMD violations. For more details see:
> /Users/ah403/git/commons-numbers/commons-numbers-primes/target/pmd.xml
> [INFO] You have 13 PMD violations. For more details see:
> /Users/ah403/git/commons-numbers/commons-numbers-quaternion/target/pmd.xml
> [INFO] You have 42 PMD violations. For more details see:
> /Users/ah403/git/commons-numbers/commons-numbers-fraction/target/pmd.xml
> [INFO] You have 3 PMD violations. For more details see:
> /Users/ah403/git/commons-numbers/commons-numbers-angle/target/pmd.xml
> [INFO] You have 192 PMD violations. For more details see:
> /Users/ah403/git/commons-numbers/commons-numbers-gamma/target/pmd.xml
> [INFO] You have 35 PMD violations. For more details see:
> /Users/ah403/git/commons-numbers/commons-numbers-combinatorics/target/pmd.xml
> [INFO] You have 14 PMD violations. For more details see:
> /Users/ah403/git/commons-numbers/commons-numbers-arrays/target/pmd.xml
> [INFO] You have 10 PMD violations. For more details see:
> /Users/ah403/git/commons-numbers/commons-numbers-field/target/pmd.xml
> [INFO] You have 1 PMD violation. For more details see:
> /Users/ah403/git/commons-numbers/commons-numbers-rootfinder/target/pmd.xml

Yes, those should be fixed (and perhaps some could be considered
as false positives).

>
> A simple fix for apache-rat:check and spotbugs:check was needed.
>
> Javadoc:javadoc builds on JDK 11 which is strict so that is good.
>
> All the changes are in a PR which passes 'mvn test site’. If travis is OK
> I’ll merge to master and then set to fixing checkstyle and PMD.
>
> Then I’ll fix Complex.

OK.

Regards,
Gilles

>
>>
>> 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 and double check the other tests against the c
>>> reference.
>>>

>
> I'll add unit tests to hit the edge cases that should fail with the
> current implementation.

 Thanks,
 Gilles
>>>
>>> Are changes to numbers going under Jira tickets?
>>>
>>> It looks like it needs an update to checkstyle, PMD, spotbugs, the
>>> commons-parent and travis.
>>>
>>> Checkstyle config from commons-rng finds:
>>>
>>> [INFO] There are 115 errors reported by Checkstyle 8.20 with
>>> /Users/ah403/git/commons-numbers/commons-numbers-core/../src/main/resources/checkstyle/checkstyle.xml
>>> ruleset.
>>> [INFO] There are 202 errors reported by Checkstyle 8.20 with
>>> /Users/ah403/git/commons-numbers/commons-numbers-complex/../src/main/resources/checkstyle/checkstyle.xml
>>> ruleset.
>>> [INFO] There are 102 errors reported by Checkstyle 8.20 with
>>> /Users/ah403/git/commons-numbers/commons-numbers-complex-streams/../src/main/resources/checkstyle/checkstyle.xml
>>> ruleset.
>>> [INFO] There are 276 errors reported by Checkstyle 8.20 with
>>> /Users/ah403/git/commons-numbers/commons-numbers-primes/../src/main/resources/checkstyle/checkstyle.xml
>>> ruleset.
>>> [INFO] There are 68 errors reported by Checkstyle 8.20 with
>>> /Users/ah403/git/commons-numbers/commons-numbers-quaternion/../src/main/resources/checkstyle/checkstyle.xml
>>> ruleset.
>>> [INFO] There are 289 errors reported by Checkstyle 8.20 with
>>> /Users/ah403/git/commons-numbers/commons-numbers-fraction/../src/main/resources/checkstyle/checkstyle.xml
>>> ruleset.
>>> [INFO] There are 10 errors reported by Checkstyle 8.20 with
>>> /Users/ah403/git/commons-numbers/commons-numbers-angle/../src/main/resources/checkstyle/checkstyle.xml
>>> ruleset.
>>> [INFO] There are 3503 errors reported by Checkstyle 8.20 with
>>> /Users/ah403/git/commons-numbers/commons-numbers-gamma/../src/main/resources/checkstyle/checkstyle.xml
>>> ruleset.
>>> [INFO] There are 56 errors reported by Checkstyle 8.20 with
>>> 

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

[Gilles Sadowski]

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 reference.
>
>>
>>>
>>> I'll add unit tests to hit the edge cases that should fail with the
>>> current implementation.
>>
>> Thanks,
>> Gilles
>
> Are changes to numbers going under Jira tickets?

There is a JIRA project:
https://issues.apache.org/jira/projects/NUMBERS
for reference in the git commit (for non-trivial changes).

But we don't really keep track (no "changes.xml") until the first
official release (getting close now, I hope...).

>
> It looks like it needs an update to checkstyle, PMD, spotbugs, the
> commons-parent and travis.

Yes.  I try to copy from or refer to Commons RNG.

> Checkstyle config from commons-rng finds:
>
> [INFO] There are 115 errors reported by Checkstyle 8.20 with
> /Users/ah403/git/commons-numbers/commons-numbers-core/../src/main/resources/checkstyle/checkstyle.xml
> ruleset.
> [INFO] There are 202 errors reported by Checkstyle 8.20 with
> /Users/ah403/git/commons-numbers/commons-numbers-complex/../src/main/resources/checkstyle/checkstyle.xml
> ruleset.
> [INFO] There are 102 errors reported by Checkstyle 8.20 with
> /Users/ah403/git/commons-numbers/commons-numbers-complex-streams/../src/main/resources/checkstyle/checkstyle.xml
> ruleset.
> [INFO] There are 276 errors reported by Checkstyle 8.20 with
> /Users/ah403/git/commons-numbers/commons-numbers-primes/../src/main/resources/checkstyle/checkstyle.xml
> ruleset.
> [INFO] There are 68 errors reported by Checkstyle 8.20 with
> /Users/ah403/git/commons-numbers/commons-numbers-quaternion/../src/main/resources/checkstyle/checkstyle.xml
> ruleset.
> [INFO] There are 289 errors reported by Checkstyle 8.20 with
> /Users/ah403/git/commons-numbers/commons-numbers-fraction/../src/main/resources/checkstyle/checkstyle.xml
> ruleset.
> [INFO] There are 10 errors reported by Checkstyle 8.20 with
> /Users/ah403/git/commons-numbers/commons-numbers-angle/../src/main/resources/checkstyle/checkstyle.xml
> ruleset.
> [INFO] There are 3503 errors reported by Checkstyle 8.20 with
> /Users/ah403/git/commons-numbers/commons-numbers-gamma/../src/main/resources/checkstyle/checkstyle.xml
> ruleset.
> [INFO] There are 56 errors reported by Checkstyle 8.20 with
> /Users/ah403/git/commons-numbers/commons-numbers-combinatorics/../src/main/resources/checkstyle/checkstyle.xml
> ruleset.
> [INFO] There are 50 errors reported by Checkstyle 8.20 with
> /Users/ah403/git/commons-numbers/commons-numbers-arrays/../src/main/resources/checkstyle/checkstyle.xml
> ruleset.
> [INFO] There are 10 errors reported by Checkstyle 8.20 with
> /Users/ah403/git/commons-numbers/commons-numbers-field/../src/main/resources/checkstyle/checkstyle.xml
> ruleset.
> [INFO] There are 4 errors reported by Checkstyle 8.20 with
> /Users/ah403/git/commons-numbers/commons-numbers-rootfinder/../src/main/resources/checkstyle/checkstyle.xml
> ruleset.
>
> The mass of errors is white space style in the test classes.

The bulk of the tests was ported from Commons Math where
CheckStyle was not enforced for unit test classes.

> Without the
> test classes the result is:
>
> [INFO] There are 12 errors reported by Checkstyle 8.20 with
> /Users/ah403/git/commons-numbers/commons-numbers-core/../src/main/resources/checkstyle/checkstyle.xml
> ruleset.
> [INFO] There are 54 errors reported by Checkstyle 8.20 with
> /Users/ah403/git/commons-numbers/commons-numbers-complex/../src/main/resources/checkstyle/checkstyle.xml
> ruleset.
> [INFO] There are 19 errors reported by Checkstyle 8.20 with
> /Users/ah403/git/commons-numbers/commons-numbers-complex-streams/../src/main/resources/checkstyle/checkstyle.xml
> ruleset.
> [INFO] There are 49 errors reported by Checkstyle 8.20 with
> /Users/ah403/git/commons-numbers/commons-numbers-primes/../src/main/resources/checkstyle/checkstyle.xml
> ruleset.
> [INFO] There are 5 errors reported by Checkstyle 8.20 with
> /Users/ah403/git/commons-numbers/commons-numbers-quaternion/../src/main/resources/checkstyle/checkstyle.xml
> ruleset.
> [INFO] There are 6 errors reported by Checkstyle 8.20 with
> /Users/ah403/git/commons-numbers/commons-numbers-fraction/../src/main/resources/checkstyle/checkstyle.xml
> ruleset.
> [INFO] There are 3 errors reported by Checkstyle 8.20 with
> /Users/ah403/git/commons-numbers/commons-numbers-angle/../src/main/resources/checkstyle/checkstyle.xml
> ruleset.
> [INFO] There are 20 errors reported by Checkstyle 8.20 with
> /Users/ah403/git/commons-numbers/commons-numbers-gamma/../src/main/resources/checkstyle/checkstyle.xml
> ruleset.
> [INFO] There are 19 errors reported by Checkstyle 8.20 with
> /Users/ah403/git/commons-numbers/commons-numbers-combinatorics/../src/main/resources/checkstyle/checkstyle.xml
> ruleset.
> [INFO] There are 4 errors reported 

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

[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 check 
goal instead of creating reports.

This requires disabling checkstyle:check and pmd:check from failing. Checkstyle 
errors were previously listed. PMD has the following errors:

[INFO] You have 23 PMD violations. For more details see: 
/Users/ah403/git/commons-numbers/commons-numbers-core/target/pmd.xml
[INFO] You have 16 PMD violations. For more details see: 
/Users/ah403/git/commons-numbers/commons-numbers-complex/target/pmd.xml
[INFO] You have 30 PMD violations. For more details see: 
/Users/ah403/git/commons-numbers/commons-numbers-complex-streams/target/pmd.xml
[INFO] You have 30 PMD violations. For more details see: 
/Users/ah403/git/commons-numbers/commons-numbers-primes/target/pmd.xml
[INFO] You have 13 PMD violations. For more details see: 
/Users/ah403/git/commons-numbers/commons-numbers-quaternion/target/pmd.xml
[INFO] You have 42 PMD violations. For more details see: 
/Users/ah403/git/commons-numbers/commons-numbers-fraction/target/pmd.xml
[INFO] You have 3 PMD violations. For more details see: 
/Users/ah403/git/commons-numbers/commons-numbers-angle/target/pmd.xml
[INFO] You have 192 PMD violations. For more details see: 
/Users/ah403/git/commons-numbers/commons-numbers-gamma/target/pmd.xml
[INFO] You have 35 PMD violations. For more details see: 
/Users/ah403/git/commons-numbers/commons-numbers-combinatorics/target/pmd.xml
[INFO] You have 14 PMD violations. For more details see: 
/Users/ah403/git/commons-numbers/commons-numbers-arrays/target/pmd.xml
[INFO] You have 10 PMD violations. For more details see: 
/Users/ah403/git/commons-numbers/commons-numbers-field/target/pmd.xml
[INFO] You have 1 PMD violation. For more details see: 
/Users/ah403/git/commons-numbers/commons-numbers-rootfinder/target/pmd.xml

A simple fix for apache-rat:check and spotbugs:check was needed.

Javadoc:javadoc builds on JDK 11 which is strict so that is good.

All the changes are in a PR which passes 'mvn test site’. If travis is OK I’ll 
merge to master and then set to fixing checkstyle and PMD.

Then I’ll fix Complex.

> 
> 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 and double check the other tests against the c reference.
>> 
>>> 
 
 I'll add unit tests to hit the edge cases that should fail with the
 current implementation.
>>> 
>>> Thanks,
>>> Gilles
>> 
>> Are changes to numbers going under Jira tickets?
>> 
>> It looks like it needs an update to checkstyle, PMD, spotbugs, the
>> commons-parent and travis.
>> 
>> Checkstyle config from commons-rng finds:
>> 
>> [INFO] There are 115 errors reported by Checkstyle 8.20 with
>> /Users/ah403/git/commons-numbers/commons-numbers-core/../src/main/resources/checkstyle/checkstyle.xml
>> ruleset.
>> [INFO] There are 202 errors reported by Checkstyle 8.20 with
>> /Users/ah403/git/commons-numbers/commons-numbers-complex/../src/main/resources/checkstyle/checkstyle.xml
>> ruleset.
>> [INFO] There are 102 errors reported by Checkstyle 8.20 with
>> /Users/ah403/git/commons-numbers/commons-numbers-complex-streams/../src/main/resources/checkstyle/checkstyle.xml
>> ruleset.
>> [INFO] There are 276 errors reported by Checkstyle 8.20 with
>> /Users/ah403/git/commons-numbers/commons-numbers-primes/../src/main/resources/checkstyle/checkstyle.xml
>> ruleset.
>> [INFO] There are 68 errors reported by Checkstyle 8.20 with
>> /Users/ah403/git/commons-numbers/commons-numbers-quaternion/../src/main/resources/checkstyle/checkstyle.xml
>> ruleset.
>> [INFO] There are 289 errors reported by Checkstyle 8.20 with
>> /Users/ah403/git/commons-numbers/commons-numbers-fraction/../src/main/resources/checkstyle/checkstyle.xml
>> ruleset.
>> [INFO] There are 10 errors reported by Checkstyle 8.20 with
>> /Users/ah403/git/commons-numbers/commons-numbers-angle/../src/main/resources/checkstyle/checkstyle.xml
>> ruleset.
>> [INFO] There are 3503 errors reported by Checkstyle 8.20 with
>> /Users/ah403/git/commons-numbers/commons-numbers-gamma/../src/main/resources/checkstyle/checkstyle.xml
>> ruleset.
>> [INFO] There are 56 errors reported by Checkstyle 8.20 with
>> /Users/ah403/git/commons-numbers/commons-numbers-combinatorics/../src/main/resources/checkstyle/checkstyle.xml
>> ruleset.
>> [INFO] There are 50 errors reported by Checkstyle 8.20 with
>> /Users/ah403/git/commons-numbers/commons-numbers-arrays/../src/main/resources/checkstyle/checkstyle.xml
>> ruleset.
>> [INFO] There are 10 errors reported by Checkstyle 8.20 with
>> 

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

[Eric Barnhill]

+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 and double check the other tests against the c reference.
>
> >
> >>
> >> I'll add unit tests to hit the edge cases that should fail with the
> >> current implementation.
> >
> > Thanks,
> > Gilles
>
> Are changes to numbers going under Jira tickets?
>
> It looks like it needs an update to checkstyle, PMD, spotbugs, the
> commons-parent and travis.
>
> Checkstyle config from commons-rng finds:
>
> [INFO] There are 115 errors reported by Checkstyle 8.20 with
> /Users/ah403/git/commons-numbers/commons-numbers-core/../src/main/resources/checkstyle/checkstyle.xml
> ruleset.
> [INFO] There are 202 errors reported by Checkstyle 8.20 with
> /Users/ah403/git/commons-numbers/commons-numbers-complex/../src/main/resources/checkstyle/checkstyle.xml
> ruleset.
> [INFO] There are 102 errors reported by Checkstyle 8.20 with
> /Users/ah403/git/commons-numbers/commons-numbers-complex-streams/../src/main/resources/checkstyle/checkstyle.xml
> ruleset.
> [INFO] There are 276 errors reported by Checkstyle 8.20 with
> /Users/ah403/git/commons-numbers/commons-numbers-primes/../src/main/resources/checkstyle/checkstyle.xml
> ruleset.
> [INFO] There are 68 errors reported by Checkstyle 8.20 with
> /Users/ah403/git/commons-numbers/commons-numbers-quaternion/../src/main/resources/checkstyle/checkstyle.xml
> ruleset.
> [INFO] There are 289 errors reported by Checkstyle 8.20 with
> /Users/ah403/git/commons-numbers/commons-numbers-fraction/../src/main/resources/checkstyle/checkstyle.xml
> ruleset.
> [INFO] There are 10 errors reported by Checkstyle 8.20 with
> /Users/ah403/git/commons-numbers/commons-numbers-angle/../src/main/resources/checkstyle/checkstyle.xml
> ruleset.
> [INFO] There are 3503 errors reported by Checkstyle 8.20 with
> /Users/ah403/git/commons-numbers/commons-numbers-gamma/../src/main/resources/checkstyle/checkstyle.xml
> ruleset.
> [INFO] There are 56 errors reported by Checkstyle 8.20 with
> /Users/ah403/git/commons-numbers/commons-numbers-combinatorics/../src/main/resources/checkstyle/checkstyle.xml
> ruleset.
> [INFO] There are 50 errors reported by Checkstyle 8.20 with
> /Users/ah403/git/commons-numbers/commons-numbers-arrays/../src/main/resources/checkstyle/checkstyle.xml
> ruleset.
> [INFO] There are 10 errors reported by Checkstyle 8.20 with
> /Users/ah403/git/commons-numbers/commons-numbers-field/../src/main/resources/checkstyle/checkstyle.xml
> ruleset.
> [INFO] There are 4 errors reported by Checkstyle 8.20 with
> /Users/ah403/git/commons-numbers/commons-numbers-rootfinder/../src/main/resources/checkstyle/checkstyle.xml
> ruleset.
>
> The mass of errors is white space style in the test classes. Without the
> test classes the result is:
>
> [INFO] There are 12 errors reported by Checkstyle 8.20 with
> /Users/ah403/git/commons-numbers/commons-numbers-core/../src/main/resources/checkstyle/checkstyle.xml
> ruleset.
> [INFO] There are 54 errors reported by Checkstyle 8.20 with
> /Users/ah403/git/commons-numbers/commons-numbers-complex/../src/main/resources/checkstyle/checkstyle.xml
> ruleset.
> [INFO] There are 19 errors reported by Checkstyle 8.20 with
> /Users/ah403/git/commons-numbers/commons-numbers-complex-streams/../src/main/resources/checkstyle/checkstyle.xml
> ruleset.
> [INFO] There are 49 errors reported by Checkstyle 8.20 with
> /Users/ah403/git/commons-numbers/commons-numbers-primes/../src/main/resources/checkstyle/checkstyle.xml
> ruleset.
> [INFO] There are 5 errors reported by Checkstyle 8.20 with
> /Users/ah403/git/commons-numbers/commons-numbers-quaternion/../src/main/resources/checkstyle/checkstyle.xml
> ruleset.
> [INFO] There are 6 errors reported by Checkstyle 8.20 with
> /Users/ah403/git/commons-numbers/commons-numbers-fraction/../src/main/resources/checkstyle/checkstyle.xml
> ruleset.
> [INFO] There are 3 errors reported by Checkstyle 8.20 with
> /Users/ah403/git/commons-numbers/commons-numbers-angle/../src/main/resources/checkstyle/checkstyle.xml
> ruleset.
> [INFO] There are 20 errors reported by Checkstyle 8.20 with
> /Users/ah403/git/commons-numbers/commons-numbers-gamma/../src/main/resources/checkstyle/checkstyle.xml
> ruleset.
> [INFO] There are 19 errors reported by Checkstyle 8.20 with
> /Users/ah403/git/commons-numbers/commons-numbers-combinatorics/../src/main/resources/checkstyle/checkstyle.xml
> ruleset.
> [INFO] There are 4 errors reported by Checkstyle 8.20 with
> /Users/ah403/git/commons-numbers/commons-numbers-arrays/../src/main/resources/checkstyle/checkstyle.xml
> ruleset.
> [INFO] There are 6 errors reported by Checkstyle 8.20 with
> /Users/ah403/git/commons-numbers/commons-numbers-field/../src/main/resources/checkstyle/checkstyle.xml
> ruleset.
>
>
> Also looking at Complex it 

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

[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 reference.

> 
>> 
>> I'll add unit tests to hit the edge cases that should fail with the
>> current implementation.
> 
> Thanks,
> Gilles

Are changes to numbers going under Jira tickets?

It looks like it needs an update to checkstyle, PMD, spotbugs, the 
commons-parent and travis.

Checkstyle config from commons-rng finds:

[INFO] There are 115 errors reported by Checkstyle 8.20 with 
/Users/ah403/git/commons-numbers/commons-numbers-core/../src/main/resources/checkstyle/checkstyle.xml
 ruleset.
[INFO] There are 202 errors reported by Checkstyle 8.20 with 
/Users/ah403/git/commons-numbers/commons-numbers-complex/../src/main/resources/checkstyle/checkstyle.xml
 ruleset.
[INFO] There are 102 errors reported by Checkstyle 8.20 with 
/Users/ah403/git/commons-numbers/commons-numbers-complex-streams/../src/main/resources/checkstyle/checkstyle.xml
 ruleset.
[INFO] There are 276 errors reported by Checkstyle 8.20 with 
/Users/ah403/git/commons-numbers/commons-numbers-primes/../src/main/resources/checkstyle/checkstyle.xml
 ruleset.
[INFO] There are 68 errors reported by Checkstyle 8.20 with 
/Users/ah403/git/commons-numbers/commons-numbers-quaternion/../src/main/resources/checkstyle/checkstyle.xml
 ruleset.
[INFO] There are 289 errors reported by Checkstyle 8.20 with 
/Users/ah403/git/commons-numbers/commons-numbers-fraction/../src/main/resources/checkstyle/checkstyle.xml
 ruleset.
[INFO] There are 10 errors reported by Checkstyle 8.20 with 
/Users/ah403/git/commons-numbers/commons-numbers-angle/../src/main/resources/checkstyle/checkstyle.xml
 ruleset.
[INFO] There are 3503 errors reported by Checkstyle 8.20 with 
/Users/ah403/git/commons-numbers/commons-numbers-gamma/../src/main/resources/checkstyle/checkstyle.xml
 ruleset.
[INFO] There are 56 errors reported by Checkstyle 8.20 with 
/Users/ah403/git/commons-numbers/commons-numbers-combinatorics/../src/main/resources/checkstyle/checkstyle.xml
 ruleset.
[INFO] There are 50 errors reported by Checkstyle 8.20 with 
/Users/ah403/git/commons-numbers/commons-numbers-arrays/../src/main/resources/checkstyle/checkstyle.xml
 ruleset.
[INFO] There are 10 errors reported by Checkstyle 8.20 with 
/Users/ah403/git/commons-numbers/commons-numbers-field/../src/main/resources/checkstyle/checkstyle.xml
 ruleset.
[INFO] There are 4 errors reported by Checkstyle 8.20 with 
/Users/ah403/git/commons-numbers/commons-numbers-rootfinder/../src/main/resources/checkstyle/checkstyle.xml
 ruleset.

The mass of errors is white space style in the test classes. Without the test 
classes the result is:

[INFO] There are 12 errors reported by Checkstyle 8.20 with 
/Users/ah403/git/commons-numbers/commons-numbers-core/../src/main/resources/checkstyle/checkstyle.xml
 ruleset.
[INFO] There are 54 errors reported by Checkstyle 8.20 with 
/Users/ah403/git/commons-numbers/commons-numbers-complex/../src/main/resources/checkstyle/checkstyle.xml
 ruleset.
[INFO] There are 19 errors reported by Checkstyle 8.20 with 
/Users/ah403/git/commons-numbers/commons-numbers-complex-streams/../src/main/resources/checkstyle/checkstyle.xml
 ruleset.
[INFO] There are 49 errors reported by Checkstyle 8.20 with 
/Users/ah403/git/commons-numbers/commons-numbers-primes/../src/main/resources/checkstyle/checkstyle.xml
 ruleset.
[INFO] There are 5 errors reported by Checkstyle 8.20 with 
/Users/ah403/git/commons-numbers/commons-numbers-quaternion/../src/main/resources/checkstyle/checkstyle.xml
 ruleset.
[INFO] There are 6 errors reported by Checkstyle 8.20 with 
/Users/ah403/git/commons-numbers/commons-numbers-fraction/../src/main/resources/checkstyle/checkstyle.xml
 ruleset.
[INFO] There are 3 errors reported by Checkstyle 8.20 with 
/Users/ah403/git/commons-numbers/commons-numbers-angle/../src/main/resources/checkstyle/checkstyle.xml
 ruleset.
[INFO] There are 20 errors reported by Checkstyle 8.20 with 
/Users/ah403/git/commons-numbers/commons-numbers-gamma/../src/main/resources/checkstyle/checkstyle.xml
 ruleset.
[INFO] There are 19 errors reported by Checkstyle 8.20 with 
/Users/ah403/git/commons-numbers/commons-numbers-combinatorics/../src/main/resources/checkstyle/checkstyle.xml
 ruleset.
[INFO] There are 4 errors reported by Checkstyle 8.20 with 
/Users/ah403/git/commons-numbers/commons-numbers-arrays/../src/main/resources/checkstyle/checkstyle.xml
 ruleset.
[INFO] There are 6 errors reported by Checkstyle 8.20 with 
/Users/ah403/git/commons-numbers/commons-numbers-field/../src/main/resources/checkstyle/checkstyle.xml
 ruleset.


Also looking at Complex it would benefit from:

public Complex subtractFrom(double minuend) {
return new Complex(minuend - real, imaginary);
}

This would avoid:

Complex a = …;
double b = …;
Complex c  = Complex.ofCartesian(b - a.real(), 

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

[Gilles Sadowski]

> [...]
>
>
> 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] http://www.open-std.org/JTC1/SC22/WG14/www/standards

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Numbers] Arrays of "Complex" objects and RAM

[Gilles Sadowski]

Hi.

>>> [...]
> >
> > public class ComplexArray {
> >  private final MultidimensionalCounter counter;
> >  // ...
> >
> >  public ComplexArray(int... dimensions) {
> >  counter = new MultidimensionalCounter(dimensions);
> >  data = new data[counter.getSize()];
> >  }
> >
> >  /**
> >   * @param indices Storage location.
> >   * @return the complex number stored at the given location.
> >   */
> >  public Complex get(int... indices) {
> >  return data[counter.getCount(indices)];
> >  }
> > }
> >
> > Or perhaps the data cube should be an additional abstraction on top of
> > "ComplexArray" (?).
> I think adding the abstraction on top is easier.
>
> Array can be renamed to Collection/List? Thus the count is the only
> thing that matters, and optionally a constant time access get(int index)
> method.

+1

>
> This can later be reshaped to a Matrix representation using the
> MultidimensionalCounter pattern.
>
> We have two use cases:
>
> 1. You know the final count of Complex objects
> 2. You do not know the count of Complex objects
>
> Use case 2 is used in streams where the ComplexList must be expandable
> for use as a collector. This can be satisfied with a constructor with an
> initial capacity. The ComplexList would thus offer a specialisation of
> ArrayList by storing the Complex objects using primitive array(s).
>
> Use case 2 rules out the possibility of immutability. This is the type
> of functionality under discussion and could be served using an interface
> to allow different implementations:
>
> public interface ComplexList {
> [...]
> }

+1

> This could be separated to put the set and add methods in a
> sub-interface allowing the top level interface to be an immutable object.

Perhaps better to follow the JDK convention and provide a
public static ComplexList unmodifiableList(ComplexList delegate)
method.

> However the apply functions currently are specified using Complex.
> Efficiency would be gained using primitive specialisations for operating
> on 1 or 2 complex numbers and outputting the results to a provided consumer:
>
>  public interface ComplexProvider {
>  /**
>   * Gets the real component of the complex number.
>   *
>   * @return the real component
>   */
>  double getReal();
>
>  /**
>   * Gets the imaginary component of the complex number.
>   *
>   * @return the imaginary component
>   */
>  double getImaginary();
>  }
>
>  public interface ComplexConsumer {
>  /**
>   * Accept the components of the complex number.
>   * Optionally return a new ComplexProvider with the components.
>   *
>   * @param real the real
>   * @param imaginary the imaginary
>   * @return the complex provider (or null)
>   */
>  ComplexProvider accept(double real, double imaginary);
>  }

What is gained wrt using "Complex" instances directly?

> [...]
>
> Unfortunately processing the stream as encountered may result in out of
> order elements if parallelisation occurs so the results may not be
> collected back in the same order.

IIUC, this would be a non-starter for the data cube abstraction.

> Here there are solutions to different problems. So which are we trying
> to solve:
>
> 1. Efficient storage of large amounts of complex numbers.
>
> 2. Efficient computation on large amounts of complex numbers.

Those two IMO.

>
> 3. Custom computation on complex numbers.

Not sure what you mean.

>
> 4. Computation on large amounts of complex numbers in-place.

This would assume very, very, large amounts of data.
For applications that would manage with data that fill at most half the
available memory, this could be emulated with
   ComplexList data = ...
   data = function.apply(data);

And, with a "data cube" abstraction with several underlying blocks
of data, the amount of needed "spare" RAM could be reduced at will:
Instead of storing one block of 1000 x 1000, one could store 4 of
500 x 500; process them sequentially would require four times less
spare RAM.

> For 1 we can use the abstraction to a collection (e.g. ComplexList).
>
> For 2 we can duplicate all methods in Complex to work directly on the
> underlying data.
>
> For 2/3 we can rewrite computation of Complex to work on input providers
> and output consumers and allow functions to be applied to the collection.
>
> For 4 we require different mutability of the collection.

I don't think that immutability is a very useful requirement when handling
very large amounts of data.  E.g. the data cube should probably allow this
kinf of usage:
   ComplexCube c = ...
   c.transformInPlace(function);

> I will continue to think about this as the solution to all issues is not
> straightforward.

I didn't want to push this too far.  The sole use-case I was aware of is an
"OutOfMemoryError" due to storing "Complex" 

[numbers] Bug in complex multiply + divide + isNaN

[Alex Herbert]

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);
    double y = Math.scalb( (b*c - a*d) / denom, -ilogbw);
    if (Double.isNaN(x) && Double.isNaN(y)) {

So the multiply method should be checking if x and y are NaN.

The multiply method also has this apparent cut-and-paste error:

    a = Math.copySign(Double.isInfinite(a) ? 1.0 : 0.0, a);
    b = Math.copySign(Double.isInfinite(a) ? 1.0 : 0.0, a);

where b should be assigned the sign from b not a.

I tried to find the C.99 standard for this as mentioned in the javadoc 
and came up with this [1]. The implementation of multiply is provided on 
page 470 and matches that in Complex without the afore mentioned bugs.


The definition for divide suggests switching from

    !Double.isInfinite

to

    Double.isFinite

which will return false for values that are NaN (where as 
!Double.isInfinite will be true for NaN leading to an incorrect choice 
in the algorithm).


The second correction statement is wrong:

    } else if ((Double.isInfinite(a) && Double.isInfinite(b)) &&
    !Double.isInfinite(c) && !Double.isInfinite(d)) {
should be:

    } else if ((Double.isInfinite(a) || Double.isInfinite(b)) &&
    !Double.isInfinite(c) && !Double.isInfinite(d)) {

The rest of divide is correct.


About isNaN:

"A complex or imaginary value with at least one infinite part is 
regarded as an infinity
(even if its other part is a NaN). A complex or imaginary value is a 
finite number if each
of its parts is a finite number (neither infinite nor NaN). A complex or 
imaginary value is

a zero if each of its parts is a zero."

So Complex::isInfinite is defined correctly but Complex::isNaN does not 
check if components are infinite, only if one of them is NaN. This means 
you can be both infinite and NaN which does not seem correct.


This suggests updating isNaN to:

    public boolean isNaN() {
    return Double.isNaN(real) &&
    Double.isNaN(imaginary);
    }

I do not know how this will effect any computations that use isNaN().


The C.99 standard I found was a draft but the main host site states that 
the working paper is the consolidated standard [2].



Any objections to updating multiply/divide/isNaN to match the standard?

I'll add unit tests to hit the edge cases that should fail with the 
current implementation.



[1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf

[2] http://www.open-std.org/JTC1/SC22/WG14/www/standards




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Numbers] Arrays of "Complex" objects and RAM

[Alex Herbert]

On 06/11/2019 12:41, Gilles Sadowski wrote:

Hello.

Le mar. 5 nov. 2019 à 18:38, Alex Herbert  a écrit :

On 05/11/2019 00:09, Eric Barnhill wrote:

That's interesting. The JTransforms library performs Fourier transforms
that can take complex input, output, or both. They do this with interleaved
double[] arrays, which I suppose is much more space efficient, and the
status of a number as real or imaginary is implicit by its location being
odd or even.

The packing of multi-dimensional structures into a single array is
common in image processing. It has computational efficiency when
operating on the entire set of numbers.

It is used a lot in image processing to pack 2D data as a single array.
In this case even random access to the (x,y) index as:

2D: [x][y]
1D: [y * maxx + x]

is comparable in speed as the later avoids the second array dereference.

I suspected that it might be the case.
If you have benchmark data that confirm it, then is there ever any
advantage to a multidimensional array?


A single array has advantages for a copy operation as it requires a
single .clone() method call. The disadvantage is that the ultimate size
of the multi-dimension array is limited by the size of an array.

That's ~17 GB, and more than 1 billion complex numbers.
And if there are use-cases that require very large data cubes, then the
abstraction would allow to add further indirections.


In the case of complex numbers the use of alternating indices to store
real and imaginary allows the array to be easily resized and extended.
Operations that process all positions only need to cache in memory a
sub-section of the array.

[re1, im1, re2, im2, re3, im3]

The alternative is to store real and imaginary in a large block in
either 1 array or 2 arrays:

[re1, re2, re3, im1, im2, im3]

[re1, re2, re3]
[im1, im2, im3]

This has advantages for operations that require either the real or the
imaginary components on their own. It is a bit more work to extend the
data as it requires two copies of the existing data and packing of the
new values as the appropriate position.

For small sizes the use of 2 arrays this would be less efficient memory
wise. It would require some type of pointer to hold the pair. However it
could store double the amount of complex numbers.

The MultidimensionalCounter functionality you mention is for example known
in Matlab as ind2sub() and sub2ind() . It allows for 1d vectorizing of
certain functions which can improve performance. Some people swear by it. I
always found it an additional mental exercise that I didn't want to occupy
myself with unless I absolutely had to. So, maybe it makes sense to
"advertise" this approach like you say, but some users may just want the 3D
arrays for more rapid prototyping-ish applications.

As Alex has shown, the 1D representation is abstracted away: The data is
accessed as a multi-dimensional array and the user never needs to remember
that it is interleaved.


I wonder if there isn't some streaming solution for this -- the numbers are
stored as an interleaved 1D array, but are streamed through a Complex
constructor before any needed operations are performed.

My initial thought is not as double values. A DoubleStream processes
single values. To collect the real and imaginary components would
require that the stream can be processed two at a time.

This structure would work:

class ComplexArray {
  // Must be even in length. Packed as (real, imaginary)
  double[] data;
  int size;

  Stream stream() {
  return IntStream.range(0, size / 2)
  .mapToObj(i -> Complex.ofCartesian(data[i*2], 
data[i*2+1]));
  }

  void add(Complex c) {
  checkCapacity(2);
  data[size++] = c.getReal();
  data[size++] = c.getImaginary();
  }

Perhaps "store" would be less confusing (?).
Final API names should have some consensus vote. At the moment this is a 
prototype for functionality.



  void combine(ComplexArray c) {
  checkCapacity(c.size);
  System.arraycopy(c.data, 0, data, size, c.size);
  size += c.size;
  }

  private void checkCapacity(int length) {
  final int minCapacity = size + length;
  final int oldCapacity = data.length;
  if (minCapacity > oldCapacity) {
  int newCapacity = ((oldCapacity * 3) >>> 1) + 1;
  if (newCapacity < minCapacity) {
  newCapacity = minCapacity;
  }
  data = Arrays.copyOf(data, newCapacity);
  }
  }
}

To allow easy usage as a multidimensional array, the API should contain
the "MultidimensionalCounter"[1] or equivalent:

public class ComplexArray {
 private final MultidimensionalCounter counter;
 // ...

 public ComplexArray(int... dimensions) {
 counter = new MultidimensionalCounter(dimensions);
 data = new data[counter.getSize()];
 }

 /**
  * @param indices Storage location.
  * @return the 

Re: [IO] Travis build fails due to missing package documentation

[Gary Gregory]

Thanks for your pointer to your GH page, I'll take a look over the
weekend...

Gary

On Tue, Nov 5, 2019 at 6:18 PM Rob Spoor  wrote:

> See https://travis-ci.org/apache/commons-io/jobs/607784753. The reason
> is commit 14d6f4c6dbb429ebb915b530ea61fe911d36b20b, which added
> interface IOConsumer in package org.apache.commons.io.function, but
> forgot to add a package-info.java or package.html.
>
> In case you're interested, you can possibly use something I wrote a
> while ago: https://github.com/robtimus/io-functions. This contains an
> almost identical IOConsumer plus a lot more copies of the interfaces in
> java.util.function.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [IO] Travis build fails due to missing package documentation

[Gary Gregory]

Hi Rob,

Thank you for the note. I added minimal package level Javadoc.

Gary

On Tue, Nov 5, 2019 at 6:18 PM Rob Spoor  wrote:

> See https://travis-ci.org/apache/commons-io/jobs/607784753. The reason
> is commit 14d6f4c6dbb429ebb915b530ea61fe911d36b20b, which added
> interface IOConsumer in package org.apache.commons.io.function, but
> forgot to add a package-info.java or package.html.
>
> In case you're interested, you can possibly use something I wrote a
> while ago: https://github.com/robtimus/io-functions. This contains an
> almost identical IOConsumer plus a lot more copies of the interfaces in
> java.util.function.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [Numbers] Arrays of "Complex" objects and RAM

[Gilles Sadowski]

Hello.

Le mar. 5 nov. 2019 à 18:38, Alex Herbert  a écrit :
>
> On 05/11/2019 00:09, Eric Barnhill wrote:
> > That's interesting. The JTransforms library performs Fourier transforms
> > that can take complex input, output, or both. They do this with interleaved
> > double[] arrays, which I suppose is much more space efficient, and the
> > status of a number as real or imaginary is implicit by its location being
> > odd or even.
>
> The packing of multi-dimensional structures into a single array is
> common in image processing. It has computational efficiency when
> operating on the entire set of numbers.
>
> It is used a lot in image processing to pack 2D data as a single array.
> In this case even random access to the (x,y) index as:
>
> 2D: [x][y]
> 1D: [y * maxx + x]
>
> is comparable in speed as the later avoids the second array dereference.

I suspected that it might be the case.
If you have benchmark data that confirm it, then is there ever any
advantage to a multidimensional array?

> A single array has advantages for a copy operation as it requires a
> single .clone() method call. The disadvantage is that the ultimate size
> of the multi-dimension array is limited by the size of an array.

That's ~17 GB, and more than 1 billion complex numbers.
And if there are use-cases that require very large data cubes, then the
abstraction would allow to add further indirections.

> In the case of complex numbers the use of alternating indices to store
> real and imaginary allows the array to be easily resized and extended.
> Operations that process all positions only need to cache in memory a
> sub-section of the array.
>
> [re1, im1, re2, im2, re3, im3]
>
> The alternative is to store real and imaginary in a large block in
> either 1 array or 2 arrays:
>
> [re1, re2, re3, im1, im2, im3]
>
> [re1, re2, re3]
> [im1, im2, im3]
>
> This has advantages for operations that require either the real or the
> imaginary components on their own. It is a bit more work to extend the
> data as it requires two copies of the existing data and packing of the
> new values as the appropriate position.
>
> For small sizes the use of 2 arrays this would be less efficient memory
> wise. It would require some type of pointer to hold the pair. However it
> could store double the amount of complex numbers.
> >
> > The MultidimensionalCounter functionality you mention is for example known
> > in Matlab as ind2sub() and sub2ind() . It allows for 1d vectorizing of
> > certain functions which can improve performance. Some people swear by it. I
> > always found it an additional mental exercise that I didn't want to occupy
> > myself with unless I absolutely had to. So, maybe it makes sense to
> > "advertise" this approach like you say, but some users may just want the 3D
> > arrays for more rapid prototyping-ish applications.

As Alex has shown, the 1D representation is abstracted away: The data is
accessed as a multi-dimensional array and the user never needs to remember
that it is interleaved.

> >
> > I wonder if there isn't some streaming solution for this -- the numbers are
> > stored as an interleaved 1D array, but are streamed through a Complex
> > constructor before any needed operations are performed.
>
> My initial thought is not as double values. A DoubleStream processes
> single values. To collect the real and imaginary components would
> require that the stream can be processed two at a time.
>
> This structure would work:
>
> class ComplexArray {
>  // Must be even in length. Packed as (real, imaginary)
>  double[] data;
>  int size;
>
>  Stream stream() {
>  return IntStream.range(0, size / 2)
>  .mapToObj(i -> Complex.ofCartesian(data[i*2], 
> data[i*2+1]));
>  }
>
>  void add(Complex c) {
>  checkCapacity(2);
>  data[size++] = c.getReal();
>  data[size++] = c.getImaginary();
>  }

Perhaps "store" would be less confusing (?).

>
>  void combine(ComplexArray c) {
>  checkCapacity(c.size);
>  System.arraycopy(c.data, 0, data, size, c.size);
>  size += c.size;
>  }
>
>  private void checkCapacity(int length) {
>  final int minCapacity = size + length;
>  final int oldCapacity = data.length;
>  if (minCapacity > oldCapacity) {
>  int newCapacity = ((oldCapacity * 3) >>> 1) + 1;
>  if (newCapacity < minCapacity) {
>  newCapacity = minCapacity;
>  }
>  data = Arrays.copyOf(data, newCapacity);
>  }
>  }
> }

To allow easy usage as a multidimensional array, the API should contain
the "MultidimensionalCounter"[1] or equivalent:

public class ComplexArray {
private final MultidimensionalCounter counter;
// ...

public ComplexArray(int... dimensions) {
counter = new MultidimensionalCounter(dimensions);
data = new data[counter.getSize()];
}

/**
 * @param indices Storage