Hi Alex and Gilles,
For the complex functional interfaces, we have so far been working on
different options but all operate on single complex numbers one at a time...
Instead can we design around Functional Interfaces that work on List/Arrays
instead?
Interface ComplexDoubleArray{
/* Methods fo
On Fri, Jun 10, 2022, 19:30 Gilles Sadowski 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-dimensiona
Thanks for the detailed explanation with example. Now I understand the
difference between binary vs source backward compatibility.
The type change would have been source compatible where existing
applications would have to recompile (without any code changes) to run
with the new version?
So yes,
On 10/06/2022 22:16, Rob Spoor wrote:
Since reflection is used to create the instances, isn't it possible to
support both?
+1, we should support both
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.or
Since reflection is used to create the instances, isn't it possible to
support both? There are plenty of containers like JBoss EAP that still
use javax instead of jakarta.
The code changes would be quite small in PropertyConverter:
1) Use two class name constants instead of one. Let's use
INT
Hi,
I have this List/Deque data structure:
https://github.com/coderodde/IndexedLinkedList
In a versatile benchmark, it outperforms the O(log n) TreeList easily by
the factor of 2. (Also, it requires less memory than TreeList.)
What do you think? Does it deserve to be included in collections?
B
Seems reasonable to me given the use case.
—
Matt Sicker
> On Jun 9, 2022, at 20:23, Matt Juntunen wrote:
>
> Hello,
>
> We are slowly getting closer to a 2.8.0 release for
> commons-configuration. One remaining item on the list is a PR [1] for
> bumping the com.sun.mail:mailapi optional depe
On Fri, 10 Jun 2022 at 14:10, Sumanth Rajkumar
wrote:
> 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.numb
Hello.
Le ven. 10 juin 2022 à 15:10, Sumanth Rajkumar
a écrit :
>
> 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.co
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.
Hello.
Le ven. 10 juin 2022 à 14:43, Sumanth Rajkumar
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 prema
Hello.
> [...]
>
> >
> > We could split complex unary operators into two primitive functions (
> > ToDoubleFunction) one returning the real part of result and other
> > for imaginary part
> >
> > interface ComplexFunction {
> > ToDoubleFunction getReal() ;
> > ToDoubleFunction getImagin
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
var
Hi,
Thanks for the design update. I will review and get back to you with more
detailed feedback. Here are some quick thoughts:
On Fri, 10 Jun 2022 at 12:55, Sumanth Rajkumar
wrote:
> Hi Alex and Giles,
>
> Thanks for the feedback.
>
> 1) Backward Compatibility and Complex Interface
> Yes. I und
2) ComplexFunction and ComplexResult functional interfaces
Following up on my previous email, another alternative for ComplexFunction
without using generic ComplexResult is as follows
@FunctionalInterface
public interface ComplexFunction3 {
void apply(Complex input, int offset, double[] result);
Hi Alex and Giles,
Thanks for the feedback.
1) Backward Compatibility and Complex Interface
Yes. I understand the backward compatibility requirement and my goal is to
be fully backward compatible.
Fortunately, the existing Complex class has private constructors and so it
is possible to refactor
16 matches
Mail list logo
