Re: [numbers] Release 1.0-beta1 Follow-Up

[Gilles Sadowski]

Hello.

Le mer. 8 avr. 2020 à 03:35, Matt Juntunen  a écrit :
>
> Hi all,
>
> I just completed the commons-numbers 1.0-beta1 release

Thanks!

> and I have a couple of follow-up notes:
>
>   *   I was unable to add the release using the form at 
> https://reporter.apache.org/addrelease.html?commons.

Done.

> I received an error message saying that I was not part of the PMC or an ASF 
> member.
>   *   I did not make any changes in JIRA for the release. Should we create a 
> 1.0-beta1 release in JIRA

Done.

> and close all resolved issues

Done.

> or wait until the full 1.0 release?

I figure out that it would be confusing if there are subsequent beta
releases:  All resolved issues up to now will appear in every one of
them, thus hiding (or making it more difficult to follow) progress.

Best,
Gilles

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [numbers] Release?

[Gilles Sadowski]

Hello.

Le mer. 25 mars 2020 à 20:28, Matt Juntunen
 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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

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

Hello.

Le mar. 24 mars 2020 à 16:19, Alex Herbert  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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [numbers] Release?

[Gilles Sadowski]

Hello.

Le mar. 24 mars 2020 à 16:19, Alex Herbert  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 
> > 
> >
> > 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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

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  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 
Sent: Saturday, March 7, 2020 7:37 AM
To: Alex Herbert ; Commons Developers List 

Subject: Re: [numbers] Release?

Hello,

Any progress here?

Regards,
Matt

From: Alex Herbert 
Sent: Friday, February 21, 2020 8:20 PM
To: Commons Developers List 
Subject: Re: [numbers] Release?




On 22 Feb 2020, at 01:15, Gilles Sadowski  wrote:

Le sam. 22 févr. 2020 à 01:30, Alex Herbert mailto:alex.d.herb...@gmail.com>> a écrit :




On 22 Feb 2020, at 00:29, Gilles Sadowski  wrote:

Hi.

Le ven. 21 févr. 2020 à 23:15, Matt Juntunen
 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-unsubscr...@commons.apache.org 
<mailto:dev-unsubscr...@commons.apache.org>
For additional commands, e-mail: dev-h...@commons.apache.org 
<mailto:dev-h...@commons.apache.org>




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

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

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 
Sent: Saturday, March 7, 2020 7:37 AM
To: Alex Herbert ; Commons Developers List 

Subject: Re: [numbers] Release?

Hello,

Any progress here?

Regards,
Matt

From: Alex Herbert 
Sent: Friday, February 21, 2020 8:20 PM
To: Commons Developers List 
Subject: Re: [numbers] Release?



> On 22 Feb 2020, at 01:15, Gilles Sadowski  wrote:
>
> Le sam. 22 févr. 2020 à 01:30, Alex Herbert  <mailto:alex.d.herb...@gmail.com>> a écrit :
>>
>>
>>
>>> On 22 Feb 2020, at 00:29, Gilles Sadowski  wrote:
>>>
>>> Hi.
>>>
>>> Le ven. 21 févr. 2020 à 23:15, Matt Juntunen
>>>  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-unsubscr...@commons.apache.org 
> <mailto:dev-unsubscr...@commons.apache.org>
> For additional commands, e-mail: dev-h...@commons.apache.org 
> <mailto:dev-h...@commons.apache.org>

Re: [numbers] Release?

[Matt Juntunen]

Hello,

Any progress here?

Regards,
Matt

From: Alex Herbert 
Sent: Friday, February 21, 2020 8:20 PM
To: Commons Developers List 
Subject: Re: [numbers] Release?



> On 22 Feb 2020, at 01:15, Gilles Sadowski  wrote:
>
> Le sam. 22 févr. 2020 à 01:30, Alex Herbert  <mailto:alex.d.herb...@gmail.com>> a écrit :
>>
>>
>>
>>> On 22 Feb 2020, at 00:29, Gilles Sadowski  wrote:
>>>
>>> Hi.
>>>
>>> Le ven. 21 févr. 2020 à 23:15, Matt Juntunen
>>>  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-unsubscr...@commons.apache.org 
> <mailto:dev-unsubscr...@commons.apache.org>
> For additional commands, e-mail: dev-h...@commons.apache.org 
> <mailto:dev-h...@commons.apache.org>

Re: [numbers] Release?

[Alex Herbert]

> On 22 Feb 2020, at 01:15, Gilles Sadowski  wrote:
> 
> Le sam. 22 févr. 2020 à 01:30, Alex Herbert  > a écrit :
>> 
>> 
>> 
>>> On 22 Feb 2020, at 00:29, Gilles Sadowski  wrote:
>>> 
>>> Hi.
>>> 
>>> Le ven. 21 févr. 2020 à 23:15, Matt Juntunen
>>>  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# 
>>  
>> > >
>> 
>> 
>>> 
>>> Best,
>>> Gilles
>>> 
 
> [...]
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org 
> 
> For additional commands, e-mail: dev-h...@commons.apache.org 
> 

Re: [numbers] Release?

[Gilles Sadowski]

Le sam. 22 févr. 2020 à 01:30, Alex Herbert  a écrit :
>
>
>
> > On 22 Feb 2020, at 00:29, Gilles Sadowski  wrote:
> >
> > Hi.
> >
> > Le ven. 21 févr. 2020 à 23:15, Matt Juntunen
> >  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# 
> 
>
>
> >
> > Best,
> > Gilles
> >
> >>
> >>> [...]

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [numbers] Release?

[Alex Herbert]

> On 22 Feb 2020, at 00:29, Gilles Sadowski  wrote:
> 
> Hi.
> 
> Le ven. 21 févr. 2020 à 23:15, Matt Juntunen
>  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# 



> 
> Best,
> Gilles
> 
>> 
>>> [...]
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 

Re: [numbers] Release?

[Gilles Sadowski]

Hi.

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

I don't think so.

Best,
Gilles

>
> > [...]

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [numbers] Release?

[Matt Juntunen]

Are we waiting on anything for a numbers release?

-Matt

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

Hi.

Le jeu. 23 janv. 2020 à 15:04, Matt Juntunen
 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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

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

Hi.

Le jeu. 23 janv. 2020 à 15:04, Matt Juntunen
 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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [numbers] Release?

[Gilles Sadowski]

Hi.

Le jeu. 23 janv. 2020 à 15:04, Matt Juntunen
 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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

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 
Sent: Thursday, January 23, 2020 6:50 PM
To: Commons Developers List 
Subject: Re: [numbers] Release?

Hi.

2020-01-23 21:50 UTC+01:00, 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,

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=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 
> Sent: Thursday, January 23, 2020 11:11 AM
> To: Commons Developers List 
> Subject: Re: [numbers] Release?
>
> Hi.
>
> Le jeu. 23 janv. 2020 à 15:04, Matt Juntunen
>  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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [numbers] Release?

[Gilles Sadowski]

Hi.

2020-01-23 21:50 UTC+01:00, 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,

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=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 
> Sent: Thursday, January 23, 2020 11:11 AM
> To: Commons Developers List 
> Subject: Re: [numbers] Release?
>
> Hi.
>
> Le jeu. 23 janv. 2020 à 15:04, Matt Juntunen
>  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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

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

Hi.

Le jeu. 23 janv. 2020 à 15:04, Matt Juntunen
 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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [numbers] Release?

[Gilles Sadowski]

Hi.

Le jeu. 23 janv. 2020 à 15:04, Matt Juntunen
 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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org