Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 7bit
Date: Wed, 04 Jan 2017 15:56:15 +0100
From: Gilles <gilles@harfang.homelinux.org>
To: <dev@commons.apache.org>
Subject: [complex] Re: First commit to commons-complex git page
In-Reply-To: <CAJcp7jsFBV4zXNYMcuVQKRKcKm3QW5hhwJwG0A7dM3_S6jg_BQ@mail.gmail.com>
References: <CAJcp7jsFBV4zXNYMcuVQKRKcKm3QW5hhwJwG0A7dM3_S6jg_BQ@mail.gmail.com>
Message-ID: <72c1d86dd7533b9356c12c54b6e640de@scarlet.be>
User-Agent: Scarlet Webmail
X-DCC-scarlet.be-Metrics: hel; whitelist
X-Virus-Scanned: clamav-milter 0.98.1-exp at hel
X-Virus-Status: Clean
archived-at: Wed, 04 Jan 2017 14:56:21 -0000

Hi Eric.

On Wed, 4 Jan 2017 11:14:40 +0100, Eric Barnhill wrote:
> To enable others to work on the code, I have posted the first commit 
> to
> commons-complex.

Thanks.

>
> Please note that the code compiles but does not yet pass mvn test. 
> This is
> what I am working on right now.
>
> Between replacing Precision.equals() type methods with private local
> equals() methods for each class, and also replacing the customized 
> math
> exceptions with more generic ones (such as IllegalStateException) and 
> only
> using custom strings, I have apparently created a library that does 
> not
> handle null very well.

You also did what Gary warned against; see e.g. "ComplexUtils" (line 
1406).

> I am happy to keep plugging away on these testing issues as they help 
> me
> learn more about the math library as currently structured;

Better to let us know what you plan to do; thus others can
work on other things.
Also, now is a good time to change whatever needs to (rather
than only port code from one repository to the other).

> however the
> learning curve gets a little steep at times

Perhaps a sign that the design is not as simple as it could (?).

> so I am not going very quickly.
>
> These issues shouldn't interfere with anyone who wants to make more
> substantial changes to the complex library at this time.

A quick (and partial) browse turned up many probably[1]
inefficient methods in "ComplexUtils": e.g.
---CUT---
d = new double[width][2 * height][depth];
for (int x = 0; x < width; x++) {
   for (int y = 0; y < height; y++) {
     for (int z = 0; z < depth; z++) {
       d[x][y * 2][z] = c[x][y][z].getReal();
       d[x][y * 2 + 1][z] = c[x][y][z].getImaginary();
     }
   }
}
---CUT---
The above should rather be:
---CUT---
d = new double[width][2 * height][depth];
for (int x = 0; x < width; x++) {
   final double[][] cX = c[x];
   final double[][] dX = d[x];
   for (int y = 0; y < height; y++) {
     final double[] cXY = cX[y];
     final int twoY = y * 2;
     final double[] dXY0 = dX[twoY];
     final double[] dXY1 = dX[twoY + 1];
     for (int z = 0; z < depth; z++) {
       final Complex cXYZ = cXY[z];
       dXY0[z] = cXYZ.getReal();
       dXY1[z] = cXYZ.getImaginary();
     }
   }
}
---CUT---

Best regards,
Gilles

[1] Unless the JIT compiler is now able to do the right thing...

>
> Best,
> Eric


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