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
