Hi,
I have made a preliminary complex list implementation class which is backed
by a single double array in interleaved format.
I made some test cases for the forEach methods as well.
This can be viewed here [1]. Please let me know what you think and if I'm
on the right track.
Thanks,
Sumanth
Thanks Alex for the feedback,
I'll work on a ComplexList class that implements the List interface and is
backed by a single double array in interleaved format.
I'll have something ready to look at by tomorrow.
Thanks,
Sumanth
On Tue, 2 Aug 2022 at 03:52, Alex Herbert wrote:
> On Mon, 1 Aug
On Mon, 1 Aug 2022 at 17:38, Sumanth Rajkumar
wrote:
> Hi,
>
> > I think that Alex's suggestion still holds: Better focus on one
> > task at a time. Are the "list" and "matrix" features related?
>
> OK, Will focus on list features first and focus on extending all existing
> methods on the
Hi,
> I think that Alex's suggestion still holds: Better focus on one
> task at a time. Are the "list" and "matrix" features related?
OK, Will focus on list features first and focus on extending all existing
methods on the Complex class to Lists.
UnaryOperators will apply the operation (using
Hello.
Le jeu. 28 juil. 2022 à 22:28, Sumanth Rajkumar
a écrit :
>
> Hi,
>
> I've completed the task of refactoring all complex operations to static
> functions and it has been merged to the complex-gsoc-2022 branch. Thank you
> for all the help to make this happen.
>
> I wanted to talk about
Hi,
I've completed the task of refactoring all complex operations to static
functions and it has been merged to the complex-gsoc-2022 branch. Thank you
for all the help to make this happen.
I wanted to talk about the next task and get some inputs from all of you on
how to start.
Now, I'm going
Hi,
I committed my changes to the test classes into the opened PR and I think
it ran the checks by itself without needing your approval.
Please let me know if there's anything else I need to change.
Thanks,
Sumanth
On Mon, Jul 11, 2022, 7:45 PM Alex Herbert wrote:
> On Mon, 11 Jul 2022 at
On Mon, 11 Jul 2022 at 22:56, Gilles Sadowski wrote:
> Le lun. 11 juil. 2022 à 20:03, Sumanth Rajkumar
> a écrit :
> >
> > Hi,
> >
> > I have finished updating the test classes, but I am encountering a
> problem
> > in the ComplexEdgeCaseTest class.
> >
> > private static void
Le lun. 11 juil. 2022 à 20:03, Sumanth Rajkumar
a écrit :
>
> Hi,
>
> I have finished updating the test classes, but I am encountering a problem
> in the ComplexEdgeCaseTest class.
>
> private static void assertComplex(double a, double b,
> String name,
Hi,
I have finished updating the test classes, but I am encountering a problem
in the ComplexEdgeCaseTest class.
private static void assertComplex(double a, double b,
String name, UnaryOperator
operation,
Thanks for the feedback Alex,
> Not a problem. Just write a dedicated method for Complex and a generic
> method in ComplexFunctions. This small level of code duplication is
> acceptable where the efficiency of the method is greatly improved by
> rewriting it, as has been done for the scalar
On Mon, 4 Jul 2022 at 23:00, Sumanth Rajkumar
wrote:
> Thanks Alex for PR feedback.
> I have incorporated the majority of the requested changes to the PR.
>
> I would like to discuss the remaining points here.
>
> > In
>
>
Thanks Alex for PR feedback.
I have incorporated the majority of the requested changes to the PR.
I would like to discuss the remaining points here.
> In
commons-numbers-complex/src/main/java/org/apache/commons/numbers/complex/ComplexUnaryOperator.java:
> Note that by making this a default that
Hello.
> > [...]
> > I have raised PR #113 after rebasing to the master branch with Alex's
> > checkstyle changes
> >
> > As per feedback, I have made the following changes
> > a) Added javadoc comments
> > b) Ensured test coverage
> > c) Renamed accessors on the interface
> >
>
> [...]
>
> >
> >
On Sun, 26 Jun 2022 at 20:52, Sumanth Rajkumar
wrote:
> Hi,
> I have raised PR #113 after rebasing to the master branch with Alex's
> checkstyle changes
>
> As per feedback, I have made the following changes
> a) Added javadoc comments
> b) Ensured test coverage
> c) Renamed accessors on the
Hi,
I have raised PR #113 after rebasing to the master branch with Alex's
checkstyle changes
As per feedback, I have made the following changes
a) Added javadoc comments
b) Ensured test coverage
c) Renamed accessors on the interface
> Gilles Sadowski wrote:
> In "DComplex", I propose that the
On Sat, 25 Jun 2022 at 10:07, Alex Herbert wrote:
>
>
> Checkstyle:
> Checkstyle plugin is configured to failOnViolation. So it is not
> complaining about lack of comments. We are using the following rules:
>
> InvalidJavadocPosition,JavadocMethod,JavadocType,JavadocVariable,JavadocStyle
>
> So
On Sat, 25 Jun 2022 at 00:43, Gilles Sadowski wrote:
>
> [1] I'm a bit surprised that the build succeeds despite the missing
> comments.
>
So am I. There are a lot of warnings:
Compilation has 2 warnings each about unchecked casts and unchecked method
invocation.
PMD: 115 warnings.
This
Hello.
Le ven. 24 juin 2022 à 16:59, Sumanth Rajkumar
a écrit :
>
> Hi Alex, Gilles, and Matt,
>
> I have raised a PR to the complex-gsoc-22 branch and it has been linked to
> the NUMBERS-188 jira.
One tenet of a project such as "Commons" is that everything must be
documented.[1]
For the
OK. I have approved the CI build to run on the PR.
I will review when I have some more time.
Alex
On Fri, 24 Jun 2022 at 15:59, Sumanth Rajkumar
wrote:
> Hi Alex, Gilles, and Matt,
>
> I have raised a PR to the complex-gsoc-22 branch and it has been linked to
> the NUMBERS-188 jira.
>
>
Hi Alex, Gilles, and Matt,
I have raised a PR to the complex-gsoc-22 branch and it has been linked to
the NUMBERS-188 jira.
While the PR is being reviewed, I will start working on NUMBERS-186 (adding
support for list and matrix of Complex numbers).
Thanks,
Sumanth
On Mon, 20 Jun 2022 at 09:43,
Hello Gilles,
Thanks! I will start a new thread for float support.
Thanks
Sumanth
On Mon, Jun 20, 2022, 18:41 Gilles Sadowski wrote
>
> > Also, should we add support for float data type for complex numbers?
>
> In the "dev" ML, we customarily aim at focussing each discussion,
> Thus could
Hello Sumanth.
Le lun. 20 juin 2022 à 07:05, Sumanth Rajkumar
a écrit :
>
> [...]
>
> Also, should we add support for float data type for complex numbers?
In the "dev" ML, we customarily aim at focussing each discussion, so
that people can easily decide (ideally, from the "Subject:" line) if
Hi Alex, Matt, and Gilles,
As discussed on the other thread, I have made NUMBERS-186 (for complex
lists work) the child of a parent ticket (NUMBERS-187)
I have created NUMBERS-188 for the functional interfaces and static method
refactoring of the existing instance methods of Complex class.
I
> EjML functional interface looks like this
>
> void apply(ComplexDouble in, MutableComplexDouble out)
>
Similar to the mutable cursor idea we have been discussing. The Mutable
object could be an interface?
Ok
We may need to have more than one implementation of the underlying storage.
Using
On Wed, 15 Jun 2022 at 17:38, Sumanth Rajkumar
wrote:
> Hi Alex,
>
> What do you intend to support as a "Matrix"? Is it for 2D or ND? What
> functionality already exists for complex matrix operations such as add and
> multiply in for example EJML?
>
> This may require some expansion.
>
> a) I
Hi Alex,
What do you intend to support as a "Matrix"? Is it for 2D or ND? What
functionality already exists for complex matrix operations such as add and
multiply in for example EJML?
This may require some expansion.
a) I reviewed EJML data naming conventions, this is what they follow:
On Mon, 13 Jun 2022 at 07:47, Sumanth Rajkumar
wrote:
>
>
> For Phase 1, I propose to do the following
>
>
> 1) Introduce ComplexDouble, ComplexDoubleVector and ComplexDoubleMatrix
> interfaces
>
What do you intend to support as a "Matrix"? Is it for 2D or ND? What
functionality already exists
Thanks Alex for the detailed feedback.
As GSOC Phase 1 has started, for the existing C99 complex functions in
Complex class, I will refactor using the item based functional interface
approach.
I can look at a Range based approach later if I have time.
As you mentioned the C99 functions cannot
On Sun, 12 Jun 2022 at 16:55, Sumanth Rajkumar
wrote:
>
>
> I have provided both approaches. Functional interfaces that operate on
> single complex and on Arrays
>
Thanks for the examples.
> <-- SNIP -->
>
> Here the implementation including iteration/cursors has moved to the
> array based
>
>
> Some thoughts:
>
> - an array should be mutable by default. It would be made immutable using a
> Collections.immutableX(...) type wrapper.
> - an array should have get and set methods for complex, real and imaginary
> using an index within the array size.
>
Ok
The last two requirements
On Sun, 12 Jun 2022 at 04:37, Sumanth Rajkumar
wrote:
> On Sat, Jun 11, 2022, 18:02 Gilles Sadowski wrote:
>
> > I have a hard time figuring out whether these bits of code are
> > intended to become the application developer API...
> > What data-structure(s) will be visible (from the
On Sat, Jun 11, 2022, 18:02 Gilles Sadowski wrote:
> I have a hard time figuring out whether these bits of code are
> intended to become the application developer API...
> What data-structure(s) will be visible (from the application)?
> What will be hidden ("implementation details")?
>
Hello,
Good discussion here! This is great!
I lost track of what the overall goal here is while reading through
the conversation. The goal of NUMBERS-186 is to "allow operations to
be performed on lists of complex numbers". My first thought when
looking at this is "how are we going to represent
Hello.
> [...]
>
> interface ComplexDoubleArray {
> Stream stream(int start, int length);
> }
>
> ComplexDoubleArray a;
> // Will use the Java 8 ForkJoinPool.commonPool() for parallel execution
> a.stream(start, length).parallel().forEach(x -> ComplexFunctions.conj(x,
> x));
>
> class
On Sat, 11 Jun 2022 at 07:09, Sumanth Rajkumar
wrote:
> 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 Sat, 11 Jun 2022 at 06:30, Sumanth Rajkumar
wrote:
> 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
> >
On Sat, 11 Jun 2022 at 06:08, Sumanth Rajkumar
wrote:
>
> 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?
>
Yes.
>
> So yes, we cannot change Complex type to interface to
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
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
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
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,
>
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,
>
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,
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
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
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
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
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[]
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
On Thu, 26 May 2022 at 15:04, Gilles Sadowski wrote:
>
> > Next, I wanted to mention how I plan to start this project and was hoping
> > to get some feedback.
> >
> > As per my proposal, the first thing I wanted to start with was the API
> > design which would have interfaces to represent
Hello.
Le jeu. 26 mai 2022 à 07:04, Sumanth Rajkumar
a écrit :
>
> Hi,
>
> My proposal was accepted into GSoC 2022 to work on the Numbers-186 [1] Jira
> of the Commons Numbers project.
>
> I first want to ask if I can be assigned to this Jira
Done.
> since my GSoC
> proposal was accepted.
>
>
Hi,
My proposal was accepted into GSoC 2022 to work on the Numbers-186 [1] Jira
of the Commons Numbers project.
I first want to ask if I can be assigned to this Jira since my GSoC
proposal was accepted.
Next, I wanted to mention how I plan to start this project and was hoping
to get some
Hello.
Le lun. 28 mars 2022 à 00:32, Sumanth Rajkumar
a écrit :
>
> 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
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
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
On Sun, 20 Mar 2022 at 16:49, Sumanth Rajkumar
wrote:
> Thanks for the feedback Alex!
>
> As suggested, I reviewed the JTransforms and ComplexUtils class in the
> complex streams package.
>
> The existing complex utils class has methods to convert to and from Array
> data structures (the forms
Le lun. 21 mars 2022 à 23:12, Alex Herbert a écrit :
>
> Hi,
>
> This lost the dev@commons in the to address. I am forwarding to the list to
> include the history.
>From a quick read of the quoted messages below, I believe I must
point out that there is an FFT implementation in Commons Math.[1]
Hi,
This lost the dev@commons in the to address. I am forwarding to the list to
include the history.
On Sun, 20 Mar 2022 at 16:49, Sumanth Rajkumar
wrote:
> Thanks for the feedback Alex!
>
> As suggested, I reviewed the JTransforms and ComplexUtils class in the
> complex streams package.
>
>
Hi,
Thanks for your interest in Commons Numbers.
On Mon, 14 Mar 2022 at 00:09, Gilles Sadowski wrote:
> >
> > My partial implementation (with TODOs for many operations) is available
> > here.
> >
>
60 matches
Mail list logo
