For 1) I ran mvn verify and found the following errors
org.apache.commons.numbers.complex.Complex.getImaginary():METHOD_NOW_ABSTRACT,
org.apache.commons.numbers.complex.Complex.getReal():METHOD_NOW_ABSTRACT,
org.apache.commons.numbers.complex.Complex:CLASS_NOW_ABSTRACT,
org.apache.commons.numbers.complex.Complex:CLASS_TYPE_CHANGED,
org.apache.commons.numbers.complex.ComplexCartesianImpl:METHOD_ABSTRACT_ADDED_IN_IMPLEMENTED_INTERFACE,
org.apache.commons.numbers.complex.ComplexList:METHOD_ABSTRACT_ADDED_IN_IMPLEMENTED_INTERFACE,
org.apache.commons.numbers.complex.ImmutableComplexList:METHOD_ABSTRACT_ADDED_IN_IMPLEMENTED_INTERFACE
These are expected changes... Is there a compatibility issue here?
2) Regarding usage of arrays in functional interfaces
@FunctionalInterface
public interface ComplexFunction3 {
void apply(Complex input, int offset, double[] result);
}
The underlying implementations of Complex and ComplexList all use arrays
and there would be no additional array instantiation /RAM allocation just
to apply the functional interface functions
A) ComplexCartesianImpl data structure will change to double[]
realAndImgPair
B) ComplexList can use single double[] for realAndImg parts (similar to all
external implementations such as jtransform)
Thanks
Sumanth
On Fri, 10 Jun 2022 at 08:58, Gilles Sadowski <gillese...@gmail.com> wrote:
> Hello.
>
> Le ven. 10 juin 2022 à 14:43, Sumanth Rajkumar
> <rajkumar.suma...@gmail.com> a écrit :
> >
> > Thanks for the quick response
> >
> > 1) I will run the mvn checks as suggested and get back to you
> >
> > 2) Yes, I realized the inefficiency and would not work.. I was following
> up
> > on another alternative but the email got sent prematurely
> >
> > Please ignore my previous email and consider this approach or some
> > variation of it?
> >
> > @FunctionalInterface
> > public interface ComplexFunction {
> > void apply(Complex input, int offset, double[] result);
> > }
> >
> > Example Conjugate implementation
> >
> > public static void conj(Complex in, int offset, double[] result) {
> > result[offset] = in.getReal();
> > result[offset+1] = in.getImaginary();
> > }
>
> My first feeling would be to steer away from (ab)using array as a pair.
> We may have to use arrays for interfacing with external tools (or perhaps
> internally too, e.g. to minimize RAM usage when processing a large list
> of complex numbers) but from a OO point of view, we should come up
> with an encapsulation that ensures robustness (e.g. featuring
> immutability).
> Also the type(s) should be easily usable in functional programming style.
>
> Gilles
>
> >
> > [...]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
