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

Le dim. 10 nov. 2019 à 00:33, Alex Herbert a écrit : > > > > > On 9 Nov 2019, at 18:10, Alex Herbert wrote: > > > > > > > >> On 9 Nov 2019, at 12:23, Gilles Sadowski >> > wrote: > >> > >>> Snip > >> > >> I think that I tried > >> $ mvn

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

> On 9 Nov 2019, at 18:10, Alex Herbert wrote: > > > >> On 9 Nov 2019, at 12:23, Gilles Sadowski > > wrote: >> >>> Snip >> >> I think that I tried >> $ mvn -Dcheckstyle.failOnViolation=false test >> >> And still it wouldn't run the test (because I had

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

> On 9 Nov 2019, at 12:23, Gilles Sadowski wrote: > >> Snip > > I think that I tried > $ mvn -Dcheckstyle.failOnViolation=false test > > And still it wouldn't run the test (because I had introduced the > "System.out" forbidden construct). Checkstyle is configured to run in the validate

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

> On 9 Nov 2019, at 12:23, Gilles Sadowski wrote: > > Hello Alex. > [...] I think at least the minimum implementation of the abstraction will be fairly easy. It can then be performance checked with a few variants. There currently is not a JMH module for numbers.

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

Hello Alex. >>> [...] >>> I think at least the minimum implementation of the abstraction will be >>> fairly easy. It can then be performance checked with a few variants. >>> >>> There currently is not a JMH module for numbers. Should I create one >>> under a module included with an optional

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

> On 9 Nov 2019, at 02:42, Gilles Sadowski wrote: > > Hi. > > Le sam. 9 nov. 2019 à 01:48, Alex Herbert > a écrit : >> >> >> >>> On 7 Nov 2019, at 23:29, Eric Barnhill wrote: >>> >>> On Thu, Nov 7, 2019 at 3:25 PM Gilles Sadowski wrote: >>> Le

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

Hi. Le sam. 9 nov. 2019 à 01:48, Alex Herbert a écrit : > > > > > On 7 Nov 2019, at 23:29, Eric Barnhill wrote: > > > > On Thu, Nov 7, 2019 at 3:25 PM Gilles Sadowski wrote: > > > >> Le jeu. 7 nov. 2019 à 18:36, Eric Barnhill a > >> écrit : > >>> > >>> I should also add on this note, my use

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

> On 7 Nov 2019, at 23:29, Eric Barnhill wrote: > > On Thu, Nov 7, 2019 at 3:25 PM Gilles Sadowski wrote: > >> Le jeu. 7 nov. 2019 à 18:36, Eric Barnhill a >> écrit : >>> >>> I should also add on this note, my use case for developing ComplexUtils >> in >>> the first place was compatibility

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

On Thu, Nov 7, 2019 at 3:25 PM Gilles Sadowski wrote: > Le jeu. 7 nov. 2019 à 18:36, Eric Barnhill a > écrit : > > > > I should also add on this note, my use case for developing ComplexUtils > in > > the first place was compatibility with JTransforms and JOCL. In both > cases > > I wanted to

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

Le jeu. 7 nov. 2019 à 18:36, Eric Barnhill a écrit : > > I should also add on this note, my use case for developing ComplexUtils in > the first place was compatibility with JTransforms and JOCL. In both cases > I wanted to convert Complex[] arrays into interleaved double[] arrays to > feed into

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

I should also add on this note, my use case for developing ComplexUtils in the first place was compatibility with JTransforms and JOCL. In both cases I wanted to convert Complex[] arrays into interleaved double[] arrays to feed into algorithms using those libraries. On Thu, Nov 7, 2019 at 9:34 AM

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

On Thu, Nov 7, 2019 at 6:09 AM Gilles Sadowski wrote: > > This is also what started this thread: The user called the Commons Math's > FFT utilities using arrays of "Complex" objects and got the "OutOfMemory" > error. Hence the question of whether storing many "Complex" objects is > ever useful,

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

> [...] > >>> > >>> public class ComplexArray { > >>> private final MultidimensionalCounter counter; > >>> // ... > >>> > >>> public ComplexArray(int... dimensions) { > >>> counter = new MultidimensionalCounter(dimensions); > >>> data = new data[counter.getSize()];

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

> On 6 Nov 2019, at 18:08, Gilles Sadowski wrote: > > Hi. > [...] >>> >>> public class ComplexArray { >>> private final MultidimensionalCounter counter; >>> // ... >>> >>> public ComplexArray(int... dimensions) { >>> counter = new

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

Hi. >>> [...] > > > > public class ComplexArray { > > private final MultidimensionalCounter counter; > > // ... > > > > public ComplexArray(int... dimensions) { > > counter = new MultidimensionalCounter(dimensions); > > data = new data[counter.getSize()]; > >

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

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

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

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

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

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

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

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