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
