First commit to commons-complex git page

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

First commit to commons-complex git page

Eric Barnhill
To enable others to work on the code, I have posted the first commit to
commons-complex.

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.

I am happy to keep plugging away on these testing issues as they help me
learn more about the math library as currently structured; however the
learning curve gets a little steep at times 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.

Best,
Eric
Reply | Threaded
Open this post in threaded view
|

[complex] Re: First commit to commons-complex git page

Gilles Sadowski
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: [hidden email]
For additional commands, e-mail: [hidden email]