Hello. Le jeu. 26 mai 2022 à 07:04, Sumanth Rajkumar <rajkumar.suma...@gmail.com> a écrit : > > Hi, > > My proposal was accepted into GSoC 2022 to work on the Numbers-186 [1] Jira > of the Commons Numbers project. > > I first want to ask if I can be assigned to this Jira
Done. > since my GSoC > proposal was accepted. > > Next, I wanted to mention how I plan to start this project and was hoping > to get some feedback. > > As per my proposal, the first thing I wanted to start with was the API > design which would have interfaces to represent complex numbers, methods to > convert to/from linear primitive arrays, Java 8 functional interfaces for > unary/binary operators and for functions for complex operations and > transforms involving: complex number and real numbers, complex vectors and > scalars, complex matrix, vectors and scalars. For each of the mentioned functionalities, types and operations, please provide a concrete example of what you propose, indicating whether it is a new feature or a change and whethe it is backwards comptable (BC) or not. [These details can be further discussed on the JIRA page.] Whenever possible, please ensure that the proposed changes do not break the build. [You can test this by opening a PR, which should trigger an automated build.] > > Working on the API, am I on the right track to start with refactoring all > the existing methods in the Complex class as static functions for use as > lambdas? > > I already refactored some methods which can be viewed here [2] Renaming is typically something to be first discussed here and/or on JIRA. Unless other non BC changes are foreseen for the next release, such "cosmetic" changes must be avoided. Thanks, Gilles > > Thanks, > > Sumanth > > [1] https://issues.apache.org/jira/browse/NUMBERS-186 > > [2] > https://github.com/sumanth-rajkumar/commons-numbers/tree/sumanth-gsoc-22/commons-numbers-complex/src/main/java/org/apache/commons/numbers/complex > > On Mon, Mar 28, 2022, 7:01 PM Gilles Sadowski <gillese...@gmail.com> wrote: > > > Hello. > > > > Le lun. 28 mars 2022 à 00:32, Sumanth Rajkumar > > <rajkumar.suma...@gmail.com> a écrit : > > > > > > Thanks Alex and Gilles for your feedback > > > > > > So currently Commons Math transform depends on Common complex numbers, > > and > > > the API involves usage of Complex Object Arrays instead of primitive > > array > > > data structures > > > > > > I also briefly looked into other library implementations besides > > Jtransform > > > and EJML that are not pure java but have java bindings such as JBLAS[1] > > and > > > NAG[2] > > > All of the implementation use single array data structures to represent > > > Complex Lists and higher dimensional matrices > > > > > > Since these involve parallel data pipelines I looked into libraries that > > > use SIMD [3] operations that use GP GPU (jcuda [4][5] /aparapi [6]) and > > CPU > > > (Java 17 Vector API [7]) > > > > Thanks for the investigation! > > > > > > > > Given all the alternative implementations, I agree it does not make sense > > > to re implement transforms here. > > > > Some transforms are (already) implemented here. > > Of course, it makes sense to wonder whether to keep maintaining those > > codes, or rely on external dependencies. The decision would depend on > > performance comparisons and whether users are able (or allowed) to > > interface with native libraries. [I know of one project where "pure Java" > > was a requirement...] > > > > > > > > So instead would it be useful to provide users with > > > 1) a complex numbers Linear Algebra and transforms API to compile against > > > and run with any of existing providers (apache commons, jtransform, EJML, > > > jblas) > > > AND > > > 2) a service provider interface to allow adapter implementations to > > > integrate existing and future providers such as jcudas/aparapi/vector > > APIs > > > > > > Do the commons library modularization dependency requirements apply to > > > compile time dependencies only or runtime also? > > > > Which "dependency requirements" are you referring to? > > > > > To minimize bloat, the runtime dependencies could be made optional and > > need > > > not be transitively included by default > > > > Flexibility would be ideal, indeed. > > > > > > > > Providing a Complex linear algebra and transforms API that can run with > > > different runtime providers would allow users to take advantage of > > hardware > > > capabilities and gracefully fallback to reference implementations > > > It could allow users to take advantage of Java 17 Vector APIs when > > > available without refactoring their existing libraries > > > > That looks great. > > > > > > > > Also do the Apache projects/ license allow for integration with non > > Apache > > > software (jtransform /jblas do not use Apache license, jcuda uses MIT > > > license) ? > > > > Licence issues are detailed here: > > https://www.apache.org/legal/resolved.html > > > > Best regards, > > Gilles > > > > > > > > Thanks > > > Sumanth > > > > > > [1] http://jblas.org/ > > > > > > [2] > > https://www.nag.com/numeric/nl/nagdoc_latest/clhtml/c06/c06conts.html > > > > > > [3] > > https://blogs.oracle.com/javamagazine/post/programming-the-gpu-in-java > > > > > > [4] http://jcuda.org/jcuda/jcufft/JCufft.html > > > > > > [5] > > > > > https://github.com/jcuda/jcuda-samples/tree/master/JCudaSamples/src/main/java/jcuda/jcufft/samples > > > > > > [6] http://aparapi.github.io/ > > > > > > [7] https://openjdk.java.net/jeps/414 > > > > > > > > > On Tue, 22 Mar 2022 at 10:07, Gilles Sadowski <gillese...@gmail.com> > > wrote: > > > > > > > Hello. > > > > > > > > > [...] > > > > > > > > > > > > Are we expecting complex-numbers to be an efficient pure java > > library > > > > that > > > > > > could be used by other java libraries such as commons-imaging for > > data > > > > > > compression (DCT /JPEG lossy compression)? > > > > > > > > > > > > > > > > Numbers should be seen as a toolbox to be used by other Java > > > > applications. > > > > > The best location for routines is something to discuss on the mailing > > > > list. > > > > > In the example of DCT, I am not aware if imaging currently has an > > encoder > > > > > implementation for this. There is a decoder: > > > > > org/apache/commons/imaging/formats/jpeg/decoder/Dct.jav > > > > > > > > Also: > > > > > > > > > > https://gitbox.apache.org/repos/asf?p=commons-math.git;a=blob;f=commons-math-transform/src/main/java/org/apache/commons/math4/transform/FastCosineTransform.java > > > > > > > > It would be a maintenance boon if "Commons" could come up with > > > > a consensus about which components must be dependency-free and > > > > which could depend on other (lower-level) "Commons" components. > > > > > > > > [Imaging] is clearly higher-level than [Math] and that such non-obvious > > > > algorithms should be maintained in a single place. Through the process > > > > of modularizing [Math], we have "commons-math-transform" module, > > > > with zero dependency, so it would bring zero bloat to [Imaging] users > > if > > > > we consolidate usage. > > > > > > > > Of course, that would imply testing and benchmarking all current > > > > implementations, and retain the best (taking various axes into account: > > > > performance, robustness, flexibility). > > > > > > > > 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
