[numbers] Release?

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

[numbers] Release?

Matt Juntunen
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
Reply | Threaded
Open this post in threaded view
|

Re: [numbers] Release?

Gilles Sadowski-2
Hi.

Le jeu. 23 janv. 2020 à 15:04, Matt Juntunen
<[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [numbers] Release?

Matt Juntunen
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 <[hidden email]>
Sent: Thursday, January 23, 2020 11:11 AM
To: Commons Developers List <[hidden email]>
Subject: Re: [numbers] Release?

Hi.

Le jeu. 23 janv. 2020 à 15:04, Matt Juntunen
<[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [numbers] Release?

Gilles Sadowski-2
Hi.

2020-01-23 21:50 UTC+01:00, Matt Juntunen <[hidden email]>:
> 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 <[hidden email]>
> Sent: Thursday, January 23, 2020 11:11 AM
> To: Commons Developers List <[hidden email]>
> Subject: Re: [numbers] Release?
>
> Hi.
>
> Le jeu. 23 janv. 2020 à 15:04, Matt Juntunen
> <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [numbers] Release?

Matt Juntunen
Hello,

NUMBERS-40 is now resolved. Are we ready for a beta release of commons-numbers?

-Matt
________________________________
From: Gilles Sadowski <[hidden email]>
Sent: Thursday, January 23, 2020 6:50 PM
To: Commons Developers List <[hidden email]>
Subject: Re: [numbers] Release?

Hi.

2020-01-23 21:50 UTC+01:00, Matt Juntunen <[hidden email]>:
> 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 <[hidden email]>
> Sent: Thursday, January 23, 2020 11:11 AM
> To: Commons Developers List <[hidden email]>
> Subject: Re: [numbers] Release?
>
> Hi.
>
> Le jeu. 23 janv. 2020 à 15:04, Matt Juntunen
> <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [numbers] Release?

Gilles Sadowski-2
In reply to this post by Matt Juntunen
Hi.

Le jeu. 23 janv. 2020 à 15:04, Matt Juntunen
<[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [numbers] Release?

Matt Juntunen
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 <[hidden email]>
Sent: Thursday, February 13, 2020 10:27 AM
To: Commons Developers List <[hidden email]>
Subject: Re: [numbers] Release?

Hi.

Le jeu. 23 janv. 2020 à 15:04, Matt Juntunen
<[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [numbers] Release?

Matt Juntunen
Are we waiting on anything for a numbers release?

-Matt
________________________________
From: Matt Juntunen <[hidden email]>
Sent: Monday, February 17, 2020 10:36 PM
To: Commons Developers List <[hidden email]>
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 <[hidden email]>
Sent: Thursday, February 13, 2020 10:27 AM
To: Commons Developers List <[hidden email]>
Subject: Re: [numbers] Release?

Hi.

Le jeu. 23 janv. 2020 à 15:04, Matt Juntunen
<[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [numbers] Release?

Gilles Sadowski-2
Hi.

Le ven. 21 févr. 2020 à 23:15, Matt Juntunen
<[hidden email]> a écrit :
>
> Are we waiting on anything for a numbers release?

I don't think so.

Best,
Gilles

>
> > [...]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [numbers] Release?

Alex Herbert


> On 22 Feb 2020, at 00:29, Gilles Sadowski <[hidden email]> wrote:
>
> Hi.
>
> Le ven. 21 févr. 2020 à 23:15, Matt Juntunen
> <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

Reply | Threaded
Open this post in threaded view
|

Re: [numbers] Release?

Gilles Sadowski-2
Le sam. 22 févr. 2020 à 01:30, Alex Herbert <[hidden email]> a écrit :

>
>
>
> > On 22 Feb 2020, at 00:29, Gilles Sadowski <[hidden email]> wrote:
> >
> > Hi.
> >
> > Le ven. 21 févr. 2020 à 23:15, Matt Juntunen
> > <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [numbers] Release?

Alex Herbert


> On 22 Feb 2020, at 01:15, Gilles Sadowski <[hidden email]> wrote:
>
> Le sam. 22 févr. 2020 à 01:30, Alex Herbert <[hidden email] <mailto:[hidden email]>> a écrit :
>>
>>
>>
>>> On 22 Feb 2020, at 00:29, Gilles Sadowski <[hidden email]> wrote:
>>>
>>> Hi.
>>>
>>> Le ven. 21 févr. 2020 à 23:15, Matt Juntunen
>>> <[hidden email]> 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: [hidden email] <mailto:[hidden email]>
> For additional commands, e-mail: [hidden email] <mailto:[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: [numbers] Release?

Matt Juntunen
Hello,

Any progress here?

Regards,
Matt
________________________________
From: Alex Herbert <[hidden email]>
Sent: Friday, February 21, 2020 8:20 PM
To: Commons Developers List <[hidden email]>
Subject: Re: [numbers] Release?



> On 22 Feb 2020, at 01:15, Gilles Sadowski <[hidden email]> wrote:
>
> Le sam. 22 févr. 2020 à 01:30, Alex Herbert <[hidden email] <mailto:[hidden email]>> a écrit :
>>
>>
>>
>>> On 22 Feb 2020, at 00:29, Gilles Sadowski <[hidden email]> wrote:
>>>
>>> Hi.
>>>
>>> Le ven. 21 févr. 2020 à 23:15, Matt Juntunen
>>> <[hidden email]> 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: [hidden email] <mailto:[hidden email]>
> For additional commands, e-mail: [hidden email] <mailto:[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: [numbers] Release?

Matt Juntunen
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 <[hidden email]>
Sent: Saturday, March 7, 2020 7:37 AM
To: Alex Herbert <[hidden email]>; Commons Developers List <[hidden email]>
Subject: Re: [numbers] Release?

Hello,

Any progress here?

Regards,
Matt
________________________________
From: Alex Herbert <[hidden email]>
Sent: Friday, February 21, 2020 8:20 PM
To: Commons Developers List <[hidden email]>
Subject: Re: [numbers] Release?



> On 22 Feb 2020, at 01:15, Gilles Sadowski <[hidden email]> wrote:
>
> Le sam. 22 févr. 2020 à 01:30, Alex Herbert <[hidden email] <mailto:[hidden email]>> a écrit :
>>
>>
>>
>>> On 22 Feb 2020, at 00:29, Gilles Sadowski <[hidden email]> wrote:
>>>
>>> Hi.
>>>
>>> Le ven. 21 févr. 2020 à 23:15, Matt Juntunen
>>> <[hidden email]> 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: [hidden email] <mailto:[hidden email]>
> For additional commands, e-mail: [hidden email] <mailto:[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: [numbers] Release?

Rob Tompkins
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 <[hidden email]> 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 <[hidden email]>
> Sent: Saturday, March 7, 2020 7:37 AM
> To: Alex Herbert <[hidden email]>; Commons Developers List <[hidden email]>
> Subject: Re: [numbers] Release?
>
> Hello,
>
> Any progress here?
>
> Regards,
> Matt
> ________________________________
> From: Alex Herbert <[hidden email]>
> Sent: Friday, February 21, 2020 8:20 PM
> To: Commons Developers List <[hidden email]>
> Subject: Re: [numbers] Release?
>
>
>
>> On 22 Feb 2020, at 01:15, Gilles Sadowski <[hidden email]> wrote:
>>
>> Le sam. 22 févr. 2020 à 01:30, Alex Herbert <[hidden email] <mailto:[hidden email]>> a écrit :
>>>
>>>
>>>
>>>> On 22 Feb 2020, at 00:29, Gilles Sadowski <[hidden email]> wrote:
>>>>
>>>> Hi.
>>>>
>>>> Le ven. 21 févr. 2020 à 23:15, Matt Juntunen
>>>> <[hidden email]> 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: [hidden email] <mailto:[hidden email]>
>> For additional commands, e-mail: [hidden email] <mailto:[hidden email]>

Reply | Threaded
Open this post in threaded view
|

Re: [numbers] Release?

Alex Herbert

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 <[hidden email]> 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 <[hidden email]>
>> Sent: Saturday, March 7, 2020 7:37 AM
>> To: Alex Herbert <[hidden email]>; Commons Developers List <[hidden email]>
>> Subject: Re: [numbers] Release?
>>
>> Hello,
>>
>> Any progress here?
>>
>> Regards,
>> Matt
>> ________________________________
>> From: Alex Herbert <[hidden email]>
>> Sent: Friday, February 21, 2020 8:20 PM
>> To: Commons Developers List <[hidden email]>
>> Subject: Re: [numbers] Release?
>>
>>
>>
>>> On 22 Feb 2020, at 01:15, Gilles Sadowski <[hidden email]> wrote:
>>>
>>> Le sam. 22 févr. 2020 à 01:30, Alex Herbert <[hidden email] <mailto:[hidden email]>> a écrit :
>>>>
>>>>
>>>>> On 22 Feb 2020, at 00:29, Gilles Sadowski <[hidden email]> wrote:
>>>>>
>>>>> Hi.
>>>>>
>>>>> Le ven. 21 févr. 2020 à 23:15, Matt Juntunen
>>>>> <[hidden email]> 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: [hidden email] <mailto:[hidden email]>
>>> For additional commands, e-mail: [hidden email] <mailto:[hidden email]>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [numbers] Release?

Gilles Sadowski-2
Hello.

Le mar. 24 mars 2020 à 16:19, Alex Herbert <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [numbers] Release?

Matt Juntunen
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 <[hidden email]>
Sent: Tuesday, March 24, 2020 1:46 PM
To: Commons Developers List <[hidden email]>
Subject: Re: [numbers] Release?

Hello.

Le mar. 24 mars 2020 à 16:19, Alex Herbert <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [numbers] Release?

Gilles Sadowski-2
Hello.

Le mer. 25 mars 2020 à 20:28, Matt Juntunen
<[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]