On Sat, 11 Jun 2022 at 06:30, Sumanth Rajkumar <rajkumar.suma...@gmail.com> wrote:
> On Fri, Jun 10, 2022, 19:30 Gilles Sadowski <gillese...@gmail.com> wrote: > > > The current implementation of "Complex" encapsulates two "double" fields > > (not > > a "double[]"). > > Should we make two, at first separate, discussions: One for the > > implementation > > of the "complex number" concept, and another for (n-dimensional) lists of > > them? > > > > Yes. We could also change existing Complex type from two double fields to > double[] and even make it implement new ComplexNumber interface? This > should maintain runtime compatibility? > True. It does have the following disadvantages: - No longer immutable. Immutability would have to be enforced by encapsulation. - Increases memory consumption. Note this would compound the original issue with representing Complex in a List<Complex> with inefficient memory consumption. So any application that does not update to the new implementation would suffer. > > I was thinking this would allow efficient reuse of functions processing > lists also to be used on single numbers (Complex) which is also a list of > size 1 > But we have also discussed other ways to share code between a single number and a list of them that are more safe, i.e. those that represent each entry of the list as a type to pass to the computation method which stores the result in the provided computation result. > > Jtransform has support for large arrays (size greater than integer.max with > array index of type long. > > Do we need to support that now or add that support later if needed? > No. You have to have a very good reason to use the undocumented sun.misc.Unsafe in code. I do not think we currently have that. Note that ~2^31 is a lot of numbers and to exceed this would be a specialist application for example using JTransforms 3D FFT on very large 3D data represented as a 1D array.
