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 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. 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] 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 > >
