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]) Given all the alternative implementations, I agree it does not make sense to re implement transforms here. 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? To minimize bloat, the runtime dependencies could be made optional and need not be transitively included by default 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 Also do the Apache projects/ license allow for integration with non Apache software (jtransform /jblas do not use Apache license, jcuda uses MIT license) ? 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 > >
