You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Matt Juntunen <ma...@hotmail.com> on 2020/01/23 14:03:49 UTC
[numbers] Release?
Hello,
Any chance we can get a release (beta or full) for commons-numbers? As I mentioned in another thread, commons-geometry is ready for a beta release but we need commons-numbers to be released before we can do that.
Regards,
Matt J
Re: [numbers] Release?
Posted by Matt Juntunen <ma...@hotmail.com>.
Hello,
NUMBERS-40 is now resolved. Are we ready for a beta release of commons-numbers?
-Matt
________________________________
From: Gilles Sadowski <gi...@gmail.com>
Sent: Thursday, January 23, 2020 6:50 PM
To: Commons Developers List <de...@commons.apache.org>
Subject: Re: [numbers] Release?
Hi.
2020-01-23 21:50 UTC+01:00, Matt Juntunen <ma...@hotmail.com>:
> Hello,
>
>> Currently, only one unresolved issue tagged for the first release.
>
> I had a look at it (NUMBERS-40) and it looks like all of the changes listed
> in the PR for the issue [1] are in place,
The report asked for reviewing a potential inconsistency in the
usage of exceptions; but PR #6 just changed the type thrown;
see my comment at the time:
https://issues.apache.org/jira/browse/NUMBERS-40?focusedCommentId=16041712&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16041712
> even though the PR was closed over
> 2 years ago. Is this issue still valid?
Yes.
IOW, the question, and report, is about whether usage is consistent
across all of "Commons Numbers".
Regards,
Gilles
>
> Regards,
> Matt
>
> [1] https://github.com/apache/commons-numbers/pull/6
> ________________________________
> From: Gilles Sadowski <gi...@gmail.com>
> Sent: Thursday, January 23, 2020 11:11 AM
> To: Commons Developers List <de...@commons.apache.org>
> Subject: Re: [numbers] Release?
>
> Hi.
>
> Le jeu. 23 janv. 2020 à 15:04, Matt Juntunen
> <ma...@hotmail.com> a écrit :
>>
>> Hello,
>>
>> Any chance we can get a release (beta or full) for commons-numbers?
>
> Currently, only one unresolved issue tagged for the first release.[1]
>
> Regards,
> Gilles
>
> [1]
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20NUMBERS%20AND%20fixVersion%20%3D%201.0%20AND%20statusCategory%20%3D%20new
>
>> As I mentioned in another thread, commons-geometry is ready for a beta
>> release but we need commons-numbers to be released before we can do that.
>>
>> Regards,
>> Matt J
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [numbers] Release?
Posted by Gilles Sadowski <gi...@gmail.com>.
Hi.
2020-01-23 21:50 UTC+01:00, Matt Juntunen <ma...@hotmail.com>:
> Hello,
>
>> Currently, only one unresolved issue tagged for the first release.
>
> I had a look at it (NUMBERS-40) and it looks like all of the changes listed
> in the PR for the issue [1] are in place,
The report asked for reviewing a potential inconsistency in the
usage of exceptions; but PR #6 just changed the type thrown;
see my comment at the time:
https://issues.apache.org/jira/browse/NUMBERS-40?focusedCommentId=16041712&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16041712
> even though the PR was closed over
> 2 years ago. Is this issue still valid?
Yes.
IOW, the question, and report, is about whether usage is consistent
across all of "Commons Numbers".
Regards,
Gilles
>
> Regards,
> Matt
>
> [1] https://github.com/apache/commons-numbers/pull/6
> ________________________________
> From: Gilles Sadowski <gi...@gmail.com>
> Sent: Thursday, January 23, 2020 11:11 AM
> To: Commons Developers List <de...@commons.apache.org>
> Subject: Re: [numbers] Release?
>
> Hi.
>
> Le jeu. 23 janv. 2020 à 15:04, Matt Juntunen
> <ma...@hotmail.com> a écrit :
>>
>> Hello,
>>
>> Any chance we can get a release (beta or full) for commons-numbers?
>
> Currently, only one unresolved issue tagged for the first release.[1]
>
> Regards,
> Gilles
>
> [1]
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20NUMBERS%20AND%20fixVersion%20%3D%201.0%20AND%20statusCategory%20%3D%20new
>
>> As I mentioned in another thread, commons-geometry is ready for a beta
>> release but we need commons-numbers to be released before we can do that.
>>
>> Regards,
>> Matt J
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [numbers] Release?
Posted by Matt Juntunen <ma...@hotmail.com>.
Hello,
> Currently, only one unresolved issue tagged for the first release.
I had a look at it (NUMBERS-40) and it looks like all of the changes listed in the PR for the issue [1] are in place, even though the PR was closed over 2 years ago. Is this issue still valid?
Regards,
Matt
[1] https://github.com/apache/commons-numbers/pull/6
________________________________
From: Gilles Sadowski <gi...@gmail.com>
Sent: Thursday, January 23, 2020 11:11 AM
To: Commons Developers List <de...@commons.apache.org>
Subject: Re: [numbers] Release?
Hi.
Le jeu. 23 janv. 2020 à 15:04, Matt Juntunen
<ma...@hotmail.com> a écrit :
>
> Hello,
>
> Any chance we can get a release (beta or full) for commons-numbers?
Currently, only one unresolved issue tagged for the first release.[1]
Regards,
Gilles
[1] https://issues.apache.org/jira/issues/?jql=project%20%3D%20NUMBERS%20AND%20fixVersion%20%3D%201.0%20AND%20statusCategory%20%3D%20new
> As I mentioned in another thread, commons-geometry is ready for a beta release but we need commons-numbers to be released before we can do that.
>
> Regards,
> Matt J
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [numbers] Release?
Posted by Gilles Sadowski <gi...@gmail.com>.
Hi.
Le jeu. 23 janv. 2020 à 15:04, Matt Juntunen
<ma...@hotmail.com> a écrit :
>
> Hello,
>
> Any chance we can get a release (beta or full) for commons-numbers?
Currently, only one unresolved issue tagged for the first release.[1]
Regards,
Gilles
[1] https://issues.apache.org/jira/issues/?jql=project%20%3D%20NUMBERS%20AND%20fixVersion%20%3D%201.0%20AND%20statusCategory%20%3D%20new
> As I mentioned in another thread, commons-geometry is ready for a beta release but we need commons-numbers to be released before we can do that.
>
> Regards,
> Matt J
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [numbers] Release?
Posted by Gilles Sadowski <gi...@gmail.com>.
Hello.
Le mer. 25 mars 2020 à 20:28, Matt Juntunen
<ma...@hotmail.com> a écrit :
>
> Thanks everyone for the information. I'll start working toward this and send out an email when I'm ready to start cutting the release.
>
> One thing I notice is that there isn't a commons-numbers user guide to speak of.
There is a JIRA issue
https://issues.apache.org/jira/projects/NUMBERS/issues/NUMBERS-70
but concrete attempts did not go very far...
> Is this something that needs to be added before the beta release?
It can always be added later.
Also, most codes are fairly self-documenting.
Best,
Gilles
> [...]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [numbers] Release?
Posted by Matt Juntunen <ma...@hotmail.com>.
Thanks everyone for the information. I'll start working toward this and send out an email when I'm ready to start cutting the release.
One thing I notice is that there isn't a commons-numbers user guide to speak of. Is this something that needs to be added before the beta release?
-Matt
________________________________
From: Gilles Sadowski <gi...@gmail.com>
Sent: Tuesday, March 24, 2020 1:46 PM
To: Commons Developers List <de...@commons.apache.org>
Subject: Re: [numbers] Release?
Hello.
Le mar. 24 mars 2020 à 16:19, Alex Herbert <al...@gmail.com> a écrit :
>
>
> On 24/03/2020 13:30, Rob Tompkins wrote:
> > Yes you’re totally welcome to, and the directions are here: http://commons.apache.org/releases/index.html <http://commons.apache.org/releases/index.html>
> >
> > Feel free to ask questions and I would suggest using the release plugin portion of the release preparation page. If there’s confusion (I would expect some obsolescence) on the page do make note of it, and I would be happy to update it as we see fit.
> >
> > All the best,
> > -Rob
> The [rng] project has a useful release guide for a multi-module project
> (I think partly written by Rob):
>
> doc/release/release.howto.txt
I started it for "Commons Math" when I attempted my first release of it,
and everything available was flawed in one way or another.
It was later modified for git-based development, then copied (mutatis
mutandis) into [RNG].
Part of the release process is nevertheless based on tools initiated
by Rob. But, last time I tried, there were issues because (AFAICT)
modularity was not fully taken into account. I don't whether it has
improved (I seem to recall of lingering JIRA reports).
It would certainly be great to consolidate the docs.
At least, components
* RNG
* Statistics
* Numbers
* Geometry
should behave the same wrt the release process.
>
>
> Q. Is this to be released as a beta?
>
> The commons release page linked indicates the artefacts would be named
>
> commons-numbers-XXX-1.0-B1.jar
>
>
> It does not state anything about changing the package coordinates.
I asked several times for confirmation on this ML: IIRC, conclusion is
that, while in "beta", it is OK
* to break compatibility, and
* to cause JAR hell.
[The advantage is that users can drop replacement JARs and see the
effect of changes without touchin their code.]
> Releasing under beta does allow changes as there are "no guarantees of
> stability or maintenance". So this could be released and we can still
> change the API. For instance there is the Complex streams modules that
> is due in part to be dropped and replaced by a ComplexList
> representation of many complex numbers. I hope to get back to working on
> this soon.
Since we know that ComplexUtils will not make to the official release
(because Alex's proposal is convincingly better), I'd remove that module
from the release branch.
Thank ou for stepping up,
Gilles
>>> [...]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [numbers] Release?
Posted by Gilles Sadowski <gi...@gmail.com>.
Hello.
Le mar. 24 mars 2020 à 16:19, Alex Herbert <al...@gmail.com> a écrit :
>
>
> On 24/03/2020 13:30, Rob Tompkins wrote:
> > Yes you’re totally welcome to, and the directions are here: http://commons.apache.org/releases/index.html <http://commons.apache.org/releases/index.html>
> >
> > Feel free to ask questions and I would suggest using the release plugin portion of the release preparation page. If there’s confusion (I would expect some obsolescence) on the page do make note of it, and I would be happy to update it as we see fit.
> >
> > All the best,
> > -Rob
> The [rng] project has a useful release guide for a multi-module project
> (I think partly written by Rob):
>
> doc/release/release.howto.txt
I started it for "Commons Math" when I attempted my first release of it,
and everything available was flawed in one way or another.
It was later modified for git-based development, then copied (mutatis
mutandis) into [RNG].
Part of the release process is nevertheless based on tools initiated
by Rob. But, last time I tried, there were issues because (AFAICT)
modularity was not fully taken into account. I don't whether it has
improved (I seem to recall of lingering JIRA reports).
It would certainly be great to consolidate the docs.
At least, components
* RNG
* Statistics
* Numbers
* Geometry
should behave the same wrt the release process.
>
>
> Q. Is this to be released as a beta?
>
> The commons release page linked indicates the artefacts would be named
>
> commons-numbers-XXX-1.0-B1.jar
>
>
> It does not state anything about changing the package coordinates.
I asked several times for confirmation on this ML: IIRC, conclusion is
that, while in "beta", it is OK
* to break compatibility, and
* to cause JAR hell.
[The advantage is that users can drop replacement JARs and see the
effect of changes without touchin their code.]
> Releasing under beta does allow changes as there are "no guarantees of
> stability or maintenance". So this could be released and we can still
> change the API. For instance there is the Complex streams modules that
> is due in part to be dropped and replaced by a ComplexList
> representation of many complex numbers. I hope to get back to working on
> this soon.
Since we know that ComplexUtils will not make to the official release
(because Alex's proposal is convincingly better), I'd remove that module
from the release branch.
Thank ou for stepping up,
Gilles
>>> [...]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [numbers] Release?
Posted by Alex Herbert <al...@gmail.com>.
On 24/03/2020 13:30, Rob Tompkins wrote:
> Yes you’re totally welcome to, and the directions are here: http://commons.apache.org/releases/index.html <http://commons.apache.org/releases/index.html>
>
> Feel free to ask questions and I would suggest using the release plugin portion of the release preparation page. If there’s confusion (I would expect some obsolescence) on the page do make note of it, and I would be happy to update it as we see fit.
>
> All the best,
> -Rob
The [rng] project has a useful release guide for a multi-module project
(I think partly written by Rob):
doc/release/release.howto.txt
Q. Is this to be released as a beta?
The commons release page linked indicates the artefacts would be named
commons-numbers-XXX-1.0-B1.jar
It does not state anything about changing the package coordinates.
Releasing under beta does allow changes as there are "no guarantees of
stability or maintenance". So this could be released and we can still
change the API. For instance there is the Complex streams modules that
is due in part to be dropped and replaced by a ComplexList
representation of many complex numbers. I hope to get back to working on
this soon.
Alex
>
>> On Mar 24, 2020, at 9:26 AM, Matt Juntunen <ma...@hotmail.com> wrote:
>>
>> Hello,
>>
>> Am I able to perform this beta release of numbers now that I am a committer? If so, how would I go about it?
>>
>> Thanks,
>> Matt
>> ________________________________
>> From: Matt Juntunen <ma...@hotmail.com>
>> Sent: Saturday, March 7, 2020 7:37 AM
>> To: Alex Herbert <al...@gmail.com>; Commons Developers List <de...@commons.apache.org>
>> Subject: Re: [numbers] Release?
>>
>> Hello,
>>
>> Any progress here?
>>
>> Regards,
>> Matt
>> ________________________________
>> From: Alex Herbert <al...@gmail.com>
>> Sent: Friday, February 21, 2020 8:20 PM
>> To: Commons Developers List <de...@commons.apache.org>
>> Subject: Re: [numbers] Release?
>>
>>
>>
>>> On 22 Feb 2020, at 01:15, Gilles Sadowski <gi...@gmail.com> wrote:
>>>
>>> Le sam. 22 févr. 2020 à 01:30, Alex Herbert <alex.d.herbert@gmail.com <ma...@gmail.com>> a écrit :
>>>>
>>>>
>>>>> On 22 Feb 2020, at 00:29, Gilles Sadowski <gi...@gmail.com> wrote:
>>>>>
>>>>> Hi.
>>>>>
>>>>> Le ven. 21 févr. 2020 à 23:15, Matt Juntunen
>>>>> <ma...@hotmail.com> a écrit :
>>>>>> Are we waiting on anything for a numbers release?
>>>>> I don't think so.
>>>> Are you talking about a beta release where the API is not yet frozen?
>>> Yes.
>>>
>>>> I’m still testing versions of LinearCombination. But from the discussion on NUMBERS-142 [1] it seems the choice may be to just change the current class to use a more precise method. It will be slower than the current method but will have an ensured accuracy of 1 ULP. It will be much faster than BigDecimal. All the testing implementations can go into the examples module for reference.
>>>>
>>>> I have 1 PR for Complex to add an internal version of Math.hypot (NUMBERS-143). I’ll go over this soon and bring it in. The method is faster and more accurate than Math.hypot.
>>>>
>>>> I think Complex is ISO C99 compliant and quite robust to edge cases. The javadoc needs a second pass and then an internal rearrangement of the code layout. I’ve left this until last so that the git change history is clear. But the methods and API are done.
>>>>
>>>> Then there is the implementation of ComplexList for storing and working with many complex numbers. This would be a replacement for part of numbers.complex.stream.ComplexUtils. The question is should this part of the API be established before any release? If a beta then we can remove redundant methods from ComplexUtils later.
>>> I would not include the "commons-numbers-complex-streams" module
>>> (IIRC you mentioned that for performance, "ComplexList" should be in
>>> the same module as "Complex”).
>> Yes. I think a lot of the private methods in Complex would have to be promoted to package private for reuse so many of the functions could operate without having to actually create an instance of Complex.
>>
>> That would be my suggestion. Since the beta release would be on a fork we can delete the module from the fork. Then it can be sanitised in master when appropriate.
>>
>>> Regards,
>>> Gilles
>>>
>>>> Alex
>>>>
>>>> [1] https://issues.apache.org/jira/browse/NUMBERS-142# <https://issues.apache.org/jira/browse/NUMBERS-142#> <https://issues.apache.org/jira/browse/NUMBERS-142# <https://issues.apache.org/jira/browse/NUMBERS-142#>>
>>>>
>>>>
>>>>> Best,
>>>>> Gilles
>>>>>
>>>>>>> [...]
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org <ma...@commons.apache.org>
>>> For additional commands, e-mail: dev-help@commons.apache.org <ma...@commons.apache.org>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [numbers] Release?
Posted by Rob Tompkins <ch...@gmail.com>.
Yes you’re totally welcome to, and the directions are here: http://commons.apache.org/releases/index.html <http://commons.apache.org/releases/index.html>
Feel free to ask questions and I would suggest using the release plugin portion of the release preparation page. If there’s confusion (I would expect some obsolescence) on the page do make note of it, and I would be happy to update it as we see fit.
All the best,
-Rob
> On Mar 24, 2020, at 9:26 AM, Matt Juntunen <ma...@hotmail.com> wrote:
>
> Hello,
>
> Am I able to perform this beta release of numbers now that I am a committer? If so, how would I go about it?
>
> Thanks,
> Matt
> ________________________________
> From: Matt Juntunen <ma...@hotmail.com>
> Sent: Saturday, March 7, 2020 7:37 AM
> To: Alex Herbert <al...@gmail.com>; Commons Developers List <de...@commons.apache.org>
> Subject: Re: [numbers] Release?
>
> Hello,
>
> Any progress here?
>
> Regards,
> Matt
> ________________________________
> From: Alex Herbert <al...@gmail.com>
> Sent: Friday, February 21, 2020 8:20 PM
> To: Commons Developers List <de...@commons.apache.org>
> Subject: Re: [numbers] Release?
>
>
>
>> On 22 Feb 2020, at 01:15, Gilles Sadowski <gi...@gmail.com> wrote:
>>
>> Le sam. 22 févr. 2020 à 01:30, Alex Herbert <alex.d.herbert@gmail.com <ma...@gmail.com>> a écrit :
>>>
>>>
>>>
>>>> On 22 Feb 2020, at 00:29, Gilles Sadowski <gi...@gmail.com> wrote:
>>>>
>>>> Hi.
>>>>
>>>> Le ven. 21 févr. 2020 à 23:15, Matt Juntunen
>>>> <ma...@hotmail.com> a écrit :
>>>>>
>>>>> Are we waiting on anything for a numbers release?
>>>>
>>>> I don't think so.
>>>
>>> Are you talking about a beta release where the API is not yet frozen?
>>
>> Yes.
>>
>>> I’m still testing versions of LinearCombination. But from the discussion on NUMBERS-142 [1] it seems the choice may be to just change the current class to use a more precise method. It will be slower than the current method but will have an ensured accuracy of 1 ULP. It will be much faster than BigDecimal. All the testing implementations can go into the examples module for reference.
>>>
>>> I have 1 PR for Complex to add an internal version of Math.hypot (NUMBERS-143). I’ll go over this soon and bring it in. The method is faster and more accurate than Math.hypot.
>>>
>>> I think Complex is ISO C99 compliant and quite robust to edge cases. The javadoc needs a second pass and then an internal rearrangement of the code layout. I’ve left this until last so that the git change history is clear. But the methods and API are done.
>>>
>>> Then there is the implementation of ComplexList for storing and working with many complex numbers. This would be a replacement for part of numbers.complex.stream.ComplexUtils. The question is should this part of the API be established before any release? If a beta then we can remove redundant methods from ComplexUtils later.
>>
>> I would not include the "commons-numbers-complex-streams" module
>> (IIRC you mentioned that for performance, "ComplexList" should be in
>> the same module as "Complex”).
>
> Yes. I think a lot of the private methods in Complex would have to be promoted to package private for reuse so many of the functions could operate without having to actually create an instance of Complex.
>
> That would be my suggestion. Since the beta release would be on a fork we can delete the module from the fork. Then it can be sanitised in master when appropriate.
>
>>
>> Regards,
>> Gilles
>>
>>>
>>> Alex
>>>
>>> [1] https://issues.apache.org/jira/browse/NUMBERS-142# <https://issues.apache.org/jira/browse/NUMBERS-142#> <https://issues.apache.org/jira/browse/NUMBERS-142# <https://issues.apache.org/jira/browse/NUMBERS-142#>>
>>>
>>>
>>>>
>>>> Best,
>>>> Gilles
>>>>
>>>>>
>>>>>> [...]
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org <ma...@commons.apache.org>
>> For additional commands, e-mail: dev-help@commons.apache.org <ma...@commons.apache.org>
Re: [numbers] Release?
Posted by Matt Juntunen <ma...@hotmail.com>.
Hello,
Am I able to perform this beta release of numbers now that I am a committer? If so, how would I go about it?
Thanks,
Matt
________________________________
From: Matt Juntunen <ma...@hotmail.com>
Sent: Saturday, March 7, 2020 7:37 AM
To: Alex Herbert <al...@gmail.com>; Commons Developers List <de...@commons.apache.org>
Subject: Re: [numbers] Release?
Hello,
Any progress here?
Regards,
Matt
________________________________
From: Alex Herbert <al...@gmail.com>
Sent: Friday, February 21, 2020 8:20 PM
To: Commons Developers List <de...@commons.apache.org>
Subject: Re: [numbers] Release?
> On 22 Feb 2020, at 01:15, Gilles Sadowski <gi...@gmail.com> wrote:
>
> Le sam. 22 févr. 2020 à 01:30, Alex Herbert <alex.d.herbert@gmail.com <ma...@gmail.com>> a écrit :
>>
>>
>>
>>> On 22 Feb 2020, at 00:29, Gilles Sadowski <gi...@gmail.com> wrote:
>>>
>>> Hi.
>>>
>>> Le ven. 21 févr. 2020 à 23:15, Matt Juntunen
>>> <ma...@hotmail.com> a écrit :
>>>>
>>>> Are we waiting on anything for a numbers release?
>>>
>>> I don't think so.
>>
>> Are you talking about a beta release where the API is not yet frozen?
>
> Yes.
>
>> I’m still testing versions of LinearCombination. But from the discussion on NUMBERS-142 [1] it seems the choice may be to just change the current class to use a more precise method. It will be slower than the current method but will have an ensured accuracy of 1 ULP. It will be much faster than BigDecimal. All the testing implementations can go into the examples module for reference.
>>
>> I have 1 PR for Complex to add an internal version of Math.hypot (NUMBERS-143). I’ll go over this soon and bring it in. The method is faster and more accurate than Math.hypot.
>>
>> I think Complex is ISO C99 compliant and quite robust to edge cases. The javadoc needs a second pass and then an internal rearrangement of the code layout. I’ve left this until last so that the git change history is clear. But the methods and API are done.
>>
>> Then there is the implementation of ComplexList for storing and working with many complex numbers. This would be a replacement for part of numbers.complex.stream.ComplexUtils. The question is should this part of the API be established before any release? If a beta then we can remove redundant methods from ComplexUtils later.
>
> I would not include the "commons-numbers-complex-streams" module
> (IIRC you mentioned that for performance, "ComplexList" should be in
> the same module as "Complex”).
Yes. I think a lot of the private methods in Complex would have to be promoted to package private for reuse so many of the functions could operate without having to actually create an instance of Complex.
That would be my suggestion. Since the beta release would be on a fork we can delete the module from the fork. Then it can be sanitised in master when appropriate.
>
> Regards,
> Gilles
>
>>
>> Alex
>>
>> [1] https://issues.apache.org/jira/browse/NUMBERS-142# <https://issues.apache.org/jira/browse/NUMBERS-142#> <https://issues.apache.org/jira/browse/NUMBERS-142# <https://issues.apache.org/jira/browse/NUMBERS-142#>>
>>
>>
>>>
>>> Best,
>>> Gilles
>>>
>>>>
>>>>> [...]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org <ma...@commons.apache.org>
> For additional commands, e-mail: dev-help@commons.apache.org <ma...@commons.apache.org>
Re: [numbers] Release?
Posted by Matt Juntunen <ma...@hotmail.com>.
Hello,
Any progress here?
Regards,
Matt
________________________________
From: Alex Herbert <al...@gmail.com>
Sent: Friday, February 21, 2020 8:20 PM
To: Commons Developers List <de...@commons.apache.org>
Subject: Re: [numbers] Release?
> On 22 Feb 2020, at 01:15, Gilles Sadowski <gi...@gmail.com> wrote:
>
> Le sam. 22 févr. 2020 à 01:30, Alex Herbert <alex.d.herbert@gmail.com <ma...@gmail.com>> a écrit :
>>
>>
>>
>>> On 22 Feb 2020, at 00:29, Gilles Sadowski <gi...@gmail.com> wrote:
>>>
>>> Hi.
>>>
>>> Le ven. 21 févr. 2020 à 23:15, Matt Juntunen
>>> <ma...@hotmail.com> a écrit :
>>>>
>>>> Are we waiting on anything for a numbers release?
>>>
>>> I don't think so.
>>
>> Are you talking about a beta release where the API is not yet frozen?
>
> Yes.
>
>> I’m still testing versions of LinearCombination. But from the discussion on NUMBERS-142 [1] it seems the choice may be to just change the current class to use a more precise method. It will be slower than the current method but will have an ensured accuracy of 1 ULP. It will be much faster than BigDecimal. All the testing implementations can go into the examples module for reference.
>>
>> I have 1 PR for Complex to add an internal version of Math.hypot (NUMBERS-143). I’ll go over this soon and bring it in. The method is faster and more accurate than Math.hypot.
>>
>> I think Complex is ISO C99 compliant and quite robust to edge cases. The javadoc needs a second pass and then an internal rearrangement of the code layout. I’ve left this until last so that the git change history is clear. But the methods and API are done.
>>
>> Then there is the implementation of ComplexList for storing and working with many complex numbers. This would be a replacement for part of numbers.complex.stream.ComplexUtils. The question is should this part of the API be established before any release? If a beta then we can remove redundant methods from ComplexUtils later.
>
> I would not include the "commons-numbers-complex-streams" module
> (IIRC you mentioned that for performance, "ComplexList" should be in
> the same module as "Complex”).
Yes. I think a lot of the private methods in Complex would have to be promoted to package private for reuse so many of the functions could operate without having to actually create an instance of Complex.
That would be my suggestion. Since the beta release would be on a fork we can delete the module from the fork. Then it can be sanitised in master when appropriate.
>
> Regards,
> Gilles
>
>>
>> Alex
>>
>> [1] https://issues.apache.org/jira/browse/NUMBERS-142# <https://issues.apache.org/jira/browse/NUMBERS-142#> <https://issues.apache.org/jira/browse/NUMBERS-142# <https://issues.apache.org/jira/browse/NUMBERS-142#>>
>>
>>
>>>
>>> Best,
>>> Gilles
>>>
>>>>
>>>>> [...]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org <ma...@commons.apache.org>
> For additional commands, e-mail: dev-help@commons.apache.org <ma...@commons.apache.org>
Re: [numbers] Release?
Posted by Alex Herbert <al...@gmail.com>.
> On 22 Feb 2020, at 01:15, Gilles Sadowski <gi...@gmail.com> wrote:
>
> Le sam. 22 févr. 2020 à 01:30, Alex Herbert <alex.d.herbert@gmail.com <ma...@gmail.com>> a écrit :
>>
>>
>>
>>> On 22 Feb 2020, at 00:29, Gilles Sadowski <gi...@gmail.com> wrote:
>>>
>>> Hi.
>>>
>>> Le ven. 21 févr. 2020 à 23:15, Matt Juntunen
>>> <ma...@hotmail.com> a écrit :
>>>>
>>>> Are we waiting on anything for a numbers release?
>>>
>>> I don't think so.
>>
>> Are you talking about a beta release where the API is not yet frozen?
>
> Yes.
>
>> I’m still testing versions of LinearCombination. But from the discussion on NUMBERS-142 [1] it seems the choice may be to just change the current class to use a more precise method. It will be slower than the current method but will have an ensured accuracy of 1 ULP. It will be much faster than BigDecimal. All the testing implementations can go into the examples module for reference.
>>
>> I have 1 PR for Complex to add an internal version of Math.hypot (NUMBERS-143). I’ll go over this soon and bring it in. The method is faster and more accurate than Math.hypot.
>>
>> I think Complex is ISO C99 compliant and quite robust to edge cases. The javadoc needs a second pass and then an internal rearrangement of the code layout. I’ve left this until last so that the git change history is clear. But the methods and API are done.
>>
>> Then there is the implementation of ComplexList for storing and working with many complex numbers. This would be a replacement for part of numbers.complex.stream.ComplexUtils. The question is should this part of the API be established before any release? If a beta then we can remove redundant methods from ComplexUtils later.
>
> I would not include the "commons-numbers-complex-streams" module
> (IIRC you mentioned that for performance, "ComplexList" should be in
> the same module as "Complex”).
Yes. I think a lot of the private methods in Complex would have to be promoted to package private for reuse so many of the functions could operate without having to actually create an instance of Complex.
That would be my suggestion. Since the beta release would be on a fork we can delete the module from the fork. Then it can be sanitised in master when appropriate.
>
> Regards,
> Gilles
>
>>
>> Alex
>>
>> [1] https://issues.apache.org/jira/browse/NUMBERS-142# <https://issues.apache.org/jira/browse/NUMBERS-142#> <https://issues.apache.org/jira/browse/NUMBERS-142# <https://issues.apache.org/jira/browse/NUMBERS-142#>>
>>
>>
>>>
>>> Best,
>>> Gilles
>>>
>>>>
>>>>> [...]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org <ma...@commons.apache.org>
> For additional commands, e-mail: dev-help@commons.apache.org <ma...@commons.apache.org>
Re: [numbers] Release?
Posted by Gilles Sadowski <gi...@gmail.com>.
Le sam. 22 févr. 2020 à 01:30, Alex Herbert <al...@gmail.com> a écrit :
>
>
>
> > On 22 Feb 2020, at 00:29, Gilles Sadowski <gi...@gmail.com> wrote:
> >
> > Hi.
> >
> > Le ven. 21 févr. 2020 à 23:15, Matt Juntunen
> > <ma...@hotmail.com> a écrit :
> >>
> >> Are we waiting on anything for a numbers release?
> >
> > I don't think so.
>
> Are you talking about a beta release where the API is not yet frozen?
Yes.
> I’m still testing versions of LinearCombination. But from the discussion on NUMBERS-142 [1] it seems the choice may be to just change the current class to use a more precise method. It will be slower than the current method but will have an ensured accuracy of 1 ULP. It will be much faster than BigDecimal. All the testing implementations can go into the examples module for reference.
>
> I have 1 PR for Complex to add an internal version of Math.hypot (NUMBERS-143). I’ll go over this soon and bring it in. The method is faster and more accurate than Math.hypot.
>
> I think Complex is ISO C99 compliant and quite robust to edge cases. The javadoc needs a second pass and then an internal rearrangement of the code layout. I’ve left this until last so that the git change history is clear. But the methods and API are done.
>
> Then there is the implementation of ComplexList for storing and working with many complex numbers. This would be a replacement for part of numbers.complex.stream.ComplexUtils. The question is should this part of the API be established before any release? If a beta then we can remove redundant methods from ComplexUtils later.
I would not include the "commons-numbers-complex-streams" module
(IIRC you mentioned that for performance, "ComplexList" should be in
the same module as "Complex").
Regards,
Gilles
>
> Alex
>
> [1] https://issues.apache.org/jira/browse/NUMBERS-142# <https://issues.apache.org/jira/browse/NUMBERS-142#>
>
>
> >
> > Best,
> > Gilles
> >
> >>
> >>> [...]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [numbers] Release?
Posted by Alex Herbert <al...@gmail.com>.
> On 22 Feb 2020, at 00:29, Gilles Sadowski <gi...@gmail.com> wrote:
>
> Hi.
>
> Le ven. 21 févr. 2020 à 23:15, Matt Juntunen
> <ma...@hotmail.com> a écrit :
>>
>> Are we waiting on anything for a numbers release?
>
> I don't think so.
Are you talking about a beta release where the API is not yet frozen?
I’m still testing versions of LinearCombination. But from the discussion on NUMBERS-142 [1] it seems the choice may be to just change the current class to use a more precise method. It will be slower than the current method but will have an ensured accuracy of 1 ULP. It will be much faster than BigDecimal. All the testing implementations can go into the examples module for reference.
I have 1 PR for Complex to add an internal version of Math.hypot (NUMBERS-143). I’ll go over this soon and bring it in. The method is faster and more accurate than Math.hypot.
I think Complex is ISO C99 compliant and quite robust to edge cases. The javadoc needs a second pass and then an internal rearrangement of the code layout. I’ve left this until last so that the git change history is clear. But the methods and API are done.
Then there is the implementation of ComplexList for storing and working with many complex numbers. This would be a replacement for part of numbers.complex.stream.ComplexUtils. The question is should this part of the API be established before any release? If a beta then we can remove redundant methods from ComplexUtils later.
Alex
[1] https://issues.apache.org/jira/browse/NUMBERS-142# <https://issues.apache.org/jira/browse/NUMBERS-142#>
>
> Best,
> Gilles
>
>>
>>> [...]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
Re: [numbers] Release?
Posted by Gilles Sadowski <gi...@gmail.com>.
Hi.
Le ven. 21 févr. 2020 à 23:15, Matt Juntunen
<ma...@hotmail.com> a écrit :
>
> Are we waiting on anything for a numbers release?
I don't think so.
Best,
Gilles
>
> > [...]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [numbers] Release?
Posted by Matt Juntunen <ma...@hotmail.com>.
Are we waiting on anything for a numbers release?
-Matt
________________________________
From: Matt Juntunen <ma...@hotmail.com>
Sent: Monday, February 17, 2020 10:36 PM
To: Commons Developers List <de...@commons.apache.org>
Subject: Re: [numbers] Release?
Gilles,
> Anyways, +1 to making beta releases, even while still working
> on features that we want in version 1.0 "non-beta".
What are the next steps for this?
-Matt
________________________________
From: Gilles Sadowski <gi...@gmail.com>
Sent: Thursday, February 13, 2020 10:27 AM
To: Commons Developers List <de...@commons.apache.org>
Subject: Re: [numbers] Release?
Hi.
Le jeu. 23 janv. 2020 à 15:04, Matt Juntunen
<ma...@hotmail.com> a écrit :
>
> Hello,
>
> Any chance we can get a release (beta or full) for commons-numbers?
Non-exhaustive check-list is here:
https://issues.apache.org/jira/browse/NUMBERS-25
All "crosses" to be changed to "checks"?
Anyways, +1 to making beta releases, even while still working
on features that we want in version 1.0 "non-beta".
> As I mentioned in another thread, commons-geometry is ready for a
> beta release
+1
And while doing so, it would be nice to prepare comparison
benchmarks with CM (v3.6.1).
> but we need commons-numbers to be released before we can do that.
Indeed.
Gilles
>
> Regards,
> Matt J
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [numbers] Release?
Posted by Matt Juntunen <ma...@hotmail.com>.
Gilles,
> Anyways, +1 to making beta releases, even while still working
> on features that we want in version 1.0 "non-beta".
What are the next steps for this?
-Matt
________________________________
From: Gilles Sadowski <gi...@gmail.com>
Sent: Thursday, February 13, 2020 10:27 AM
To: Commons Developers List <de...@commons.apache.org>
Subject: Re: [numbers] Release?
Hi.
Le jeu. 23 janv. 2020 à 15:04, Matt Juntunen
<ma...@hotmail.com> a écrit :
>
> Hello,
>
> Any chance we can get a release (beta or full) for commons-numbers?
Non-exhaustive check-list is here:
https://issues.apache.org/jira/browse/NUMBERS-25
All "crosses" to be changed to "checks"?
Anyways, +1 to making beta releases, even while still working
on features that we want in version 1.0 "non-beta".
> As I mentioned in another thread, commons-geometry is ready for a
> beta release
+1
And while doing so, it would be nice to prepare comparison
benchmarks with CM (v3.6.1).
> but we need commons-numbers to be released before we can do that.
Indeed.
Gilles
>
> Regards,
> Matt J
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [numbers] Release?
Posted by Gilles Sadowski <gi...@gmail.com>.
Hi.
Le jeu. 23 janv. 2020 à 15:04, Matt Juntunen
<ma...@hotmail.com> a écrit :
>
> Hello,
>
> Any chance we can get a release (beta or full) for commons-numbers?
Non-exhaustive check-list is here:
https://issues.apache.org/jira/browse/NUMBERS-25
All "crosses" to be changed to "checks"?
Anyways, +1 to making beta releases, even while still working
on features that we want in version 1.0 "non-beta".
> As I mentioned in another thread, commons-geometry is ready for a
> beta release
+1
And while doing so, it would be nice to prepare comparison
benchmarks with CM (v3.6.1).
> but we need commons-numbers to be released before we can do that.
Indeed.
Gilles
>
> Regards,
> Matt J
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org