Re: [geometry] PointMap and PointSet
Gilles, > it would be great to keep the tutorials/userguide in sync. Sounds good. I'll update the user guide in this PR. > I'm a little bit confused: Isn't it always the case that getEntry(p).getKey() will return the originally inserted (i.e. "canonical") point (i.e. not "p")? Map does not contain a "getEntry" method. If it did, that would indeed be preferable. > Unless I'm missing a standard use-case, the specialized methods "closestFirst" and "farthestFirst" don't seem useful (and wasteful of computing resources: If iterating over the whole set, why would one want to start from some particular point?). Could you post this comment on the JIRA issue and we can continue the discussion there? Regards, Matt On Sun, Mar 13, 2022 at 11:25 AM Gilles Sadowski wrote: > > Hello Matt. > > Le dim. 13 mars 2022 à 15:41, Matt Juntunen > a écrit : > > > > Hello, > > > > > Is there a gentle introduction to how it works and/or the intended > > use cases? > > > > Not specifically. The implementations are used the same way as JDK > > Maps and Sets so usage should be very familiar. As far as the internal > > implementation details, I've tried to describe that in the javadocs > > for the implementing classes. > > > > One example use case is construction of meshes from a stream of > > triangles. This is used internally in > > o.a.c.geometry.euclidean.threed.mesh.SimpleTriangleMesh. Another use > > case is finding unique entries in a cloud of points, where many points > > are close but not exactly equal to each other. This case was actually > > posted on the user mailing list (I believe) way back when I started > > implementing this feature. > > I know; but as the code base provides more and more functionality > (thank you!) it would be great to keep the tutorials/userguide in sync. > A simple "How to..." is often enough (and faster than browsing the > Javadoc) in order to get at the most common usage. > > > > > > Does it entail issues about some use cases or applications that > > need this functionality? Or do they not generally care about that > > contract? > > If so, maybe this collection shouldn't implement the standard JDK > > interfaces (?). > > > > No, there shouldn't be any issues. java.util.TreeMap documents that > > it's behavior is well-defined and consistent even when a Comparator > > that doesn't match equals is given, such as > > String.CASE_INSENSITIVE_ORDER. This is the same sort of situation. The > > map/set is still quite useful even without the strict contract. > > > > > Where does the anticipation come from? > > > > The approach I used for helping to maintain somewhat balanced trees in > > Euclidean 2D and 3D and spherical 2D regardless of insertion order is > > not based on a well-known algorithm or paper since I was unable to > > find one. The literature on the subject seems to focus on situations > > where the inserted points are all known beforehand and can be inserted > > in a particular order. I did not want to enforce this condition on the > > API. What I ended up with is just an idea I had for tree balancing > > that seems to work pretty well. As such, I fully expect that there > > will be a better option discovered later on. > > IMHO, the above two Q & A are worth mentioning in the userguide. > The second especially may attract some user's attention who could > provide the missing info. [Of course, it should also appear at the > relevant places in the Javadoc.] > > > > > > I don't quite follow; which are the corresponding "non-canonical" > > accessors? > > > > My thought here is that there will be situations where a set of points > > is placed into a map/set and then these points are queried using > > values determined from some other source, such as through computations > > of some sort. > > Indeed. > > > These query points may vary from the originally inserted > > points by distances allowed by the Precision.DoubleEquivalence. In > > these cases, it's useful to be able to obtain the exact value of the > > originally inserted (i.e. "canonical") point. This is the purpose of > > the "resolve" methods. > > I'm a little bit confused: Isn't it always the case that > getEntry(p).getKey() > will return the originally inserted (i.e. "canonical") point (i.e. not "p")? > > Anyways, I'd suggest that this be illustrated in the userguide (linked > to a working application in "commons-geometry-examples"). > > > > > > Is there a notion of neighbours (as in: return the "n" entries that > > are closest to a given point)? > > > > I am picturing that functionality being implemented in a follow-up issue. > > [1] > > Thanks. > However, my impression is that the API should be more general: > ---CUT--- > public Iterable closestInRange(P point, double radius); > ---CUT--- > > Unless I'm missing a standard use-case, the specialized methods > "closestFirst" and "farthestFirst" don't seem useful (and wasteful > of computing resources: If iterating over the whole set, why would > one want to start from some
Re: [geometry] PointMap and PointSet
Hello. Le lun. 14 mars 2022 à 16:19, Matt Juntunen a écrit : > > Gilles, > > > it would be great to keep the tutorials/userguide in sync. > > Sounds good. I'll update the user guide in this PR. > > > I'm a little bit confused: Isn't it always the case that > getEntry(p).getKey() > will return the originally inserted (i.e. "canonical") point (i.e. not "p")? > > Map does not contain a "getEntry" method. If it did, that would indeed > be preferable. Do I understand correctly that the "resolveEntry" method which you added behaves as my above "getEntry"? If so, the latter can replace both "resolve" methods, for a (c)leaner API. > > Unless I'm missing a standard use-case, the specialized methods > "closestFirst" and "farthestFirst" don't seem useful (and wasteful > of computing resources: If iterating over the whole set, why would > one want to start from some particular point?). > > Could you post this comment on the JIRA issue and we can continue the > discussion there? Done. Regards, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons Daemon 1.3.0 based on RC1
On 11/03/2022 13:32, Mark Thomas wrote: Please review the release candidate and vote. This vote will close no sooner that 72 hours from now. [X] +1 Release these artifacts [ ] +0 OK, but... [ ] -0 OK, but really should fix... [ ] -1 I oppose this release because... Tested with Apache Tomcat 10.1.0-M12 on Windows 2022 server. Mark - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons Daemon 1.3.0 based on RC1
Hi PMC folk, we need more reviews please. Gary On Fri, Mar 11, 2022, 08:32 Mark Thomas wrote: > Since the 1.2.4 release, the minimum Java version has been updated to > Java 7 and a handful of bugs have been fixed so I would like to release > Apache Commons Daemon 1.3.0. > > Apache Commons Daemon 1.3.0 RC1 is available for review here: > https://dist.apache.org/repos/dist/dev/commons/daemon/1.3.0-RC1 > (svn revision 52984) > > The Git tag commons-daemon-1.3.0-RC1 commit for this RC is > 73708a0d774304cd4e02eb675fc599f42bc5e150 which you can browse here: > > > https://gitbox.apache.org/repos/asf?p=commons-daemon.git;a=commit;h=73708a0d774304cd4e02eb675fc599f42bc5e150 > You may checkout this tag using: > git clone https://gitbox.apache.org/repos/asf/commons-daemon.git > --branch commons-daemon-1.3.0-RC1 commons-daemon-1.3.0-RC1 > > Maven artifacts are here: > > > https://repository.apache.org/content/repositories/orgapachecommons-1579/commons-daemon/commons-daemon/1.3.0/ > > These are the artifacts and their hashes: > > #Release SHA-512s > > commons-daemon-1.3.0.jar=748f3ac828feb9284b192e9c3f7d50cbe3c3bc101ba477a269070b296b9a3a69f626cd546bab45e7a24ac9b9503c01a56d7774192c16765b5995a96f8fc3c3e0 > > commons-daemon-1.3.0-bin.tar.gz=53c1fee9bb14ae84034ec06e45693b86927493124fb050a598928884a985c54878710f63063e45b095469ffe45050ed87663de320df2140e0678642e21938592 > > commons-daemon-1.3.0-bin.zip=cacc6d59b5baa9bd4c94da2ae1818d08d32cb25ddab6a21aa9e44e735b274cc78599c6342a3af34337152c3915e84055b28e4081e18b6c29e8cb73a604af4e70 > > commons-daemon-1.3.0-bin-windows.zip=ff545f4b1c8a5f10b471e579e0b4c739e6e1f393f74f36ff35cfe62cced3febef20451b15b418e534c9e3640a9502e4c9da47a59e7ff3c772b439f8b8929f223 > > commons-daemon-1.3.0-native-src.tar.gz=86588c1ce9e26a365235d8629137a6fea8b7bd1f4920063d620f7bf713e17bafc2fd152f46a52edd420d8090122dac4250a531e683b435948ae12462175807b4 > > commons-daemon-1.3.0-native-src.zip=2732e26dd0e98867d01155bbcec8dc01810a4c573bc4eeb1ab398071428bafc698588238365e1436cc8ba9838735769637f43a899f51440b3112d7b42283bfb1 > > commons-daemon-1.3.0-src.tar.gz=392ae1a4f36294c31f8f549c61bdf0a9fcd59a1e4eee3c54ceba30473066184271636b11ee6073526640c245d3f3a94d1d4d34413787c5b3323e6eedc7026816 > > commons-daemon-1.3.0-src.zip=932d907ae51d59818f67d083fcd8f769b71644ac2d7af7131550b1abe729299a25bbada617cb418af4159006f2a3fc2cc44f8292e058ab6e1aa5b1072c1ffad1 > > Note the Windows binaries are also signed using the Digicert ONE code > signing service with the Commons PMC key. > > > Details of changes since 1.2.4 are in the release notes: > > > https://dist.apache.org/repos/dist/dev/commons/daemon/1.3.0-RC1/RELEASE-NOTES.txt > > > https://dist.apache.org/repos/dist/dev/commons/daemon/1.3.0-RC1/site/changes-report.html > > KEYS: >https://www.apache.org/dist/commons/KEYS > > Please review the release candidate and vote. > This vote will close no sooner that 72 hours from now. > >[ ] +1 Release these artifacts >[ ] +0 OK, but... >[ ] -0 OK, but really should fix... >[ ] -1 I oppose this release because... > > Thank you, > > Mark Thomas, > Release Manager (using key 10C01C5A2F6059E7) > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [VOTE] Release Apache Commons Daemon 1.3.0 based on RC1
On it, as soon as I have some spare time between tasks at $work. Voting in the next hours. Cheers, Bruno On Tue, 15 Mar 2022 at 09:48, Gary Gregory wrote: > Hi PMC folk, we need more reviews please. > > Gary > > On Fri, Mar 11, 2022, 08:32 Mark Thomas wrote: > > > Since the 1.2.4 release, the minimum Java version has been updated to > > Java 7 and a handful of bugs have been fixed so I would like to release > > Apache Commons Daemon 1.3.0. > > > > Apache Commons Daemon 1.3.0 RC1 is available for review here: > > https://dist.apache.org/repos/dist/dev/commons/daemon/1.3.0-RC1 > > (svn revision 52984) > > > > The Git tag commons-daemon-1.3.0-RC1 commit for this RC is > > 73708a0d774304cd4e02eb675fc599f42bc5e150 which you can browse here: > > > > > > > https://gitbox.apache.org/repos/asf?p=commons-daemon.git;a=commit;h=73708a0d774304cd4e02eb675fc599f42bc5e150 > > You may checkout this tag using: > > git clone https://gitbox.apache.org/repos/asf/commons-daemon.git > > --branch commons-daemon-1.3.0-RC1 commons-daemon-1.3.0-RC1 > > > > Maven artifacts are here: > > > > > > > https://repository.apache.org/content/repositories/orgapachecommons-1579/commons-daemon/commons-daemon/1.3.0/ > > > > These are the artifacts and their hashes: > > > > #Release SHA-512s > > > > > commons-daemon-1.3.0.jar=748f3ac828feb9284b192e9c3f7d50cbe3c3bc101ba477a269070b296b9a3a69f626cd546bab45e7a24ac9b9503c01a56d7774192c16765b5995a96f8fc3c3e0 > > > > > commons-daemon-1.3.0-bin.tar.gz=53c1fee9bb14ae84034ec06e45693b86927493124fb050a598928884a985c54878710f63063e45b095469ffe45050ed87663de320df2140e0678642e21938592 > > > > > commons-daemon-1.3.0-bin.zip=cacc6d59b5baa9bd4c94da2ae1818d08d32cb25ddab6a21aa9e44e735b274cc78599c6342a3af34337152c3915e84055b28e4081e18b6c29e8cb73a604af4e70 > > > > > commons-daemon-1.3.0-bin-windows.zip=ff545f4b1c8a5f10b471e579e0b4c739e6e1f393f74f36ff35cfe62cced3febef20451b15b418e534c9e3640a9502e4c9da47a59e7ff3c772b439f8b8929f223 > > > > > commons-daemon-1.3.0-native-src.tar.gz=86588c1ce9e26a365235d8629137a6fea8b7bd1f4920063d620f7bf713e17bafc2fd152f46a52edd420d8090122dac4250a531e683b435948ae12462175807b4 > > > > > commons-daemon-1.3.0-native-src.zip=2732e26dd0e98867d01155bbcec8dc01810a4c573bc4eeb1ab398071428bafc698588238365e1436cc8ba9838735769637f43a899f51440b3112d7b42283bfb1 > > > > > commons-daemon-1.3.0-src.tar.gz=392ae1a4f36294c31f8f549c61bdf0a9fcd59a1e4eee3c54ceba30473066184271636b11ee6073526640c245d3f3a94d1d4d34413787c5b3323e6eedc7026816 > > > > > commons-daemon-1.3.0-src.zip=932d907ae51d59818f67d083fcd8f769b71644ac2d7af7131550b1abe729299a25bbada617cb418af4159006f2a3fc2cc44f8292e058ab6e1aa5b1072c1ffad1 > > > > Note the Windows binaries are also signed using the Digicert ONE code > > signing service with the Commons PMC key. > > > > > > Details of changes since 1.2.4 are in the release notes: > > > > > > > https://dist.apache.org/repos/dist/dev/commons/daemon/1.3.0-RC1/RELEASE-NOTES.txt > > > > > > > https://dist.apache.org/repos/dist/dev/commons/daemon/1.3.0-RC1/site/changes-report.html > > > > KEYS: > >https://www.apache.org/dist/commons/KEYS > > > > Please review the release candidate and vote. > > This vote will close no sooner that 72 hours from now. > > > >[ ] +1 Release these artifacts > >[ ] +0 OK, but... > >[ ] -0 OK, but really should fix... > >[ ] -1 I oppose this release because... > > > > Thank you, > > > > Mark Thomas, > > Release Manager (using key 10C01C5A2F6059E7) > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > >
Re: [VOTE] Release Apache Commons Daemon 1.3.0 based on RC1
[x] +1 Release these artifacts Strangely `mvn clean test install site` generated the site with a layout that looked really old, but with the correct data (release notes, changes, reports, etc). Not too concerned as we can fix the site later if needed (more likely to be something on my environment.) Release notes look OK, notice file too. I think I got accustomed to the changes being listed in the release notes, but we can think about it later. Checked signatures of files in the dist area, no issues found. Inspected a couple files manually, license/release/notice are all in place and looking OK. Apache Maven 3.8.2 (ea98e05a04480131370aa0c110b8c54cf726c06f) Maven home: /opt/apache-maven-3.8.2 Java version: 11.0.14, vendor: Ubuntu, runtime: /usr/lib/jvm/java-11-openjdk-amd64 Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "5.4.0-104-generic", arch: "amd64", family: "unix" Thanks Mark! Bruno On Tue, 15 Mar 2022 at 10:16, Bruno Kinoshita wrote: > On it, as soon as I have some spare time between tasks at $work. Voting in > the next hours. > > Cheers, > Bruno > > On Tue, 15 Mar 2022 at 09:48, Gary Gregory wrote: > >> Hi PMC folk, we need more reviews please. >> >> Gary >> >> On Fri, Mar 11, 2022, 08:32 Mark Thomas wrote: >> >> > Since the 1.2.4 release, the minimum Java version has been updated to >> > Java 7 and a handful of bugs have been fixed so I would like to release >> > Apache Commons Daemon 1.3.0. >> > >> > Apache Commons Daemon 1.3.0 RC1 is available for review here: >> > https://dist.apache.org/repos/dist/dev/commons/daemon/1.3.0-RC1 >> > (svn revision 52984) >> > >> > The Git tag commons-daemon-1.3.0-RC1 commit for this RC is >> > 73708a0d774304cd4e02eb675fc599f42bc5e150 which you can browse here: >> > >> > >> > >> https://gitbox.apache.org/repos/asf?p=commons-daemon.git;a=commit;h=73708a0d774304cd4e02eb675fc599f42bc5e150 >> > You may checkout this tag using: >> > git clone https://gitbox.apache.org/repos/asf/commons-daemon.git >> > --branch commons-daemon-1.3.0-RC1 commons-daemon-1.3.0-RC1 >> > >> > Maven artifacts are here: >> > >> > >> > >> https://repository.apache.org/content/repositories/orgapachecommons-1579/commons-daemon/commons-daemon/1.3.0/ >> > >> > These are the artifacts and their hashes: >> > >> > #Release SHA-512s >> > >> > >> commons-daemon-1.3.0.jar=748f3ac828feb9284b192e9c3f7d50cbe3c3bc101ba477a269070b296b9a3a69f626cd546bab45e7a24ac9b9503c01a56d7774192c16765b5995a96f8fc3c3e0 >> > >> > >> commons-daemon-1.3.0-bin.tar.gz=53c1fee9bb14ae84034ec06e45693b86927493124fb050a598928884a985c54878710f63063e45b095469ffe45050ed87663de320df2140e0678642e21938592 >> > >> > >> commons-daemon-1.3.0-bin.zip=cacc6d59b5baa9bd4c94da2ae1818d08d32cb25ddab6a21aa9e44e735b274cc78599c6342a3af34337152c3915e84055b28e4081e18b6c29e8cb73a604af4e70 >> > >> > >> commons-daemon-1.3.0-bin-windows.zip=ff545f4b1c8a5f10b471e579e0b4c739e6e1f393f74f36ff35cfe62cced3febef20451b15b418e534c9e3640a9502e4c9da47a59e7ff3c772b439f8b8929f223 >> > >> > >> commons-daemon-1.3.0-native-src.tar.gz=86588c1ce9e26a365235d8629137a6fea8b7bd1f4920063d620f7bf713e17bafc2fd152f46a52edd420d8090122dac4250a531e683b435948ae12462175807b4 >> > >> > >> commons-daemon-1.3.0-native-src.zip=2732e26dd0e98867d01155bbcec8dc01810a4c573bc4eeb1ab398071428bafc698588238365e1436cc8ba9838735769637f43a899f51440b3112d7b42283bfb1 >> > >> > >> commons-daemon-1.3.0-src.tar.gz=392ae1a4f36294c31f8f549c61bdf0a9fcd59a1e4eee3c54ceba30473066184271636b11ee6073526640c245d3f3a94d1d4d34413787c5b3323e6eedc7026816 >> > >> > >> commons-daemon-1.3.0-src.zip=932d907ae51d59818f67d083fcd8f769b71644ac2d7af7131550b1abe729299a25bbada617cb418af4159006f2a3fc2cc44f8292e058ab6e1aa5b1072c1ffad1 >> > >> > Note the Windows binaries are also signed using the Digicert ONE code >> > signing service with the Commons PMC key. >> > >> > >> > Details of changes since 1.2.4 are in the release notes: >> > >> > >> > >> https://dist.apache.org/repos/dist/dev/commons/daemon/1.3.0-RC1/RELEASE-NOTES.txt >> > >> > >> > >> https://dist.apache.org/repos/dist/dev/commons/daemon/1.3.0-RC1/site/changes-report.html >> > >> > KEYS: >> >https://www.apache.org/dist/commons/KEYS >> > >> > Please review the release candidate and vote. >> > This vote will close no sooner that 72 hours from now. >> > >> >[ ] +1 Release these artifacts >> >[ ] +0 OK, but... >> >[ ] -0 OK, but really should fix... >> >[ ] -1 I oppose this release because... >> > >> > Thank you, >> > >> > Mark Thomas, >> > Release Manager (using key 10C01C5A2F6059E7) >> > >> > - >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> > For additional commands, e-mail: dev-h...@commons.apache.org >> > >> > >> >
Re: [geometry] PointMap and PointSet
Hello, > Do I understand correctly that the "resolveEntry" method which you added behaves as my above "getEntry"? Correct. > If so, the latter can replace both "resolve" methods, for a (c)leaner API. That would work. I would need to add a matching "get" method to PointSet to provide the same functionality there. One consideration here is that the "resolveEntry" method creates and returns an immutable Entry instance with each call. The "resolveKey" method avoids this. I'm not sure if this will have an impact on performance. I'll try reducing the API as you suggest and include it in the PR if it doesn't make a difference in performance. Do you prefer the "get" verb over "resolve", e.g. "getEntry" vs "resolveEntry"? Regards, Matt On Mon, Mar 14, 2022 at 2:19 PM Gilles Sadowski wrote: > > Hello. > > Le lun. 14 mars 2022 à 16:19, Matt Juntunen > a écrit : > > > > Gilles, > > > > > it would be great to keep the tutorials/userguide in sync. > > > > Sounds good. I'll update the user guide in this PR. > > > > > I'm a little bit confused: Isn't it always the case that > > getEntry(p).getKey() > > will return the originally inserted (i.e. "canonical") point (i.e. not "p")? > > > > Map does not contain a "getEntry" method. If it did, that would indeed > > be preferable. > > Do I understand correctly that the "resolveEntry" method which > you added behaves as my above "getEntry"? If so, the latter can > replace both "resolve" methods, for a (c)leaner API. > > > > Unless I'm missing a standard use-case, the specialized methods > > "closestFirst" and "farthestFirst" don't seem useful (and wasteful > > of computing resources: If iterating over the whole set, why would > > one want to start from some particular point?). > > > > Could you post this comment on the JIRA issue and we can continue the > > discussion there? > > Done. > > Regards, > Gilles > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [numbers][gsoc] GSoC 2022 - NUMBERS-186 Proposal
Hi Alex/Gilles
Thank you both for the detailed review. I think I have a better
understanding now.
1) Refactor using Functional Interfaces and move current instance methods
to static methods
As suggested, I have attempted to refactor the Complex class to extract
the functions out to static methods and use Functional interfaces
I have added following Complex Functional interfaces similar to Functions
and Operators defined in java.util.function but only using primitive
doubles and avoiding any Object creation overheads
@FunctionalInterface
public interface ComplexFunction {
R apply(double r, double i, ComplexResult result);
}
@FunctionalInterface
public interface ComplexBiFunction {
R apply(double r1, double i1, double r2, double i2,
ComplexResult result);
}
@FunctionalInterface
public interface ComplexResult {
R apply(double r, double i);
default ComplexResult andThen(Function
after) {
Objects.requireNonNull(after);
return (r, i) -> after.apply(apply(r, i));
}
default ComplexResult compose(ComplexFunction before) {
Objects.requireNonNull(before);
return (r, i) -> before.apply(r, i, (x, y) -> apply(x, y));
}
}
I have refactored a few Functions (exp, conj, asin) and a few BFunctions
(multiply, divide) as static functions into a new ComplexFunctions class
I have modified the existing implementations for above in the Complex
class to use the new static functions using the new Function interfaces
I have also refactored ComplexList to apply the above function
interfaces in forEach methods as suggested. These apply the results in
place without incurring object overheads
Refactored source is available here for review
https://github.com/sumanth-rajkumar/commons-numbers/tree/sumanth-gsoc-22/commons-numbers-complex/src/main/java/org/apache/commons/numbers/complex
Please let me know if the above changes are on expected lines?
2) List Implementation
Thanks for the feedback on the license issue. I should be able refactor
this as suggested just using the javadoc specifications
-Sumanth.
On Sun, 13 Mar 2022 at 21:39, Alex Herbert wrote:
> Hi,
>
> Thanks for your interest in Commons Numbers.
>
> On Mon, 14 Mar 2022 at 00:09, Gilles Sadowski
> wrote:
>
> > >
> > > My partial implementation (with TODOs for many operations) is available
> > > here.
> > >
> >
> https://github.com/sumanth-rajkumar/commons-numbers/blob/sumanth-gsoc-22/commons-numbers-complex/src/main/java/org/apache/commons/numbers/complex/ComplexList.java
>
>
> Thanks for the implementation idea. This is a literal implementation of a
> List. I think we should take a step back and find use cases for a
> large set of complex numbers. That should drive the API design.
>
> For example a common operation with complex numbers is to conjugate
> multiply the fast fourier transform of two data arrays. The conjugate
> multiply in the frequency domain is equivalent to the correlation in the
> spatial domain. So I would require:
>
> ComplexList a;
> ComplexList b;
>
> a.conj().multiply(b);
>
> But what is the most appropriate method to do this? I do not think we want
> to implement full matrix functionality for multiplication of arrays. But we
> should allow an API that makes this type of work efficient in terms of
> memory usage, i.e. zero object allocation during computation (avoid
> creating Complex instances) and ideally no intermediate array allocation.
> So in the above I do not want to create an entire list of conjugates before
> multiplying by another complex number. I also want the option to write to a
> new array or back to the original one.
>
> So should we have some type of generic interface for an operation on a
> Complex:
>
> interface ComplexFunction {
>interface ComplexResult {
> void complex(double real, double imag);
>}
>void apply(double re, double im, ComplexResult);
> }
>
> Then a list to allow operations on elements in place. For example to
> compute the conjugate:
>
> ComplexList a;
> a.forEach((re, im, result) -> result.complex(re, -im));
>
> All operations in the Complex class can be rewritten as static methods
> using a minimal set of functional interfaces.
>
> static void conj(double re, double im, ComplexResult result) {
> result.complex(re, -im);
> }
>
> The operation then becomes:
>
> ComplexList a;
> a.forEach(Complex::conj);
>
> Which is a bit less cumbersome to write.
>
> Operations could be chained using a 'andThen' method in the interface:
>
> ComplexList a;
> a.forEach(((ComplexFunction) Complex::conj).andThen(Complex::sin));
>
> I've not considered exactly how this will work in practice.
>
> Functions that convert to a real number (such as abs()) could write 0 to
> the imaginary.
>
> The specifics will depend on all the operations in Complex. So a start
> point may be to refactor the class to expose all the instance methods as
> static methods that take input and write the result to a destination. These
> can
