[Numbers] Where do we stand?

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

[Numbers] Where do we stand?

Gilles Sadowski
Hello.

JIRA lists 12 unresolved issues for the v1.0 target.

After quite a lot of nice work, nearly zero activity in
the last 6 months...

Regards,
Gilles


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

Reply | Threaded
Open this post in threaded view
|

Re: [Numbers] Where do we stand?

Eric Barnhill
First of all, AFAICT, none of the issues I worked on have ever been marked
"resolved". I don't believe I have the power to mark them this way myself.

Eric

On Fri, Jan 26, 2018 at 1:49 AM, Gilles <[hidden email]>
wrote:

> Hello.
>
> JIRA lists 12 unresolved issues for the v1.0 target.
>
> After quite a lot of nice work, nearly zero activity in
> the last 6 months...
>
> Regards,
> Gilles
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [Numbers] Where do we stand?

Gilles Sadowski
Hi Eric.

On Fri, 26 Jan 2018 11:29:50 +0100, Eric Barnhill wrote:
> First of all, AFAICT, none of the issues I worked on have ever been
> marked
> "resolved".

As a matter of principle, no issue can be "resolved" if it would
imply a code change and said change was not merged into the "master"
branch.

My understanding was that you had been working on a separate branch
for the porting work, and I was assuming that you were going to
merge it into "master" whenever you deemed it right.
We discussed a few things and I don't recall that we disagreed on
anything for "Complex"; IIRC, I only had some reservation about the
performance of the numerous methods in "ComplexUtils".  When nobody
objects within say 2 weeks, then no need to wait forever before
merging since you have committer access!

> I don't believe I have the power to mark them this way myself.

If further progress is blocked by something beyond your reach, you
should not hesitate to ping this list as many times as necessary. ;-)
I remember that there was a problem with changing the state of JIRA
issues; I also seem to recall that I relayed it here since I didn't
have the privilege for fixing it.  If the problem persisted, would
you please post again here a message that describes it?

Best regards,
Gilles

>
> Eric
>
> On Fri, Jan 26, 2018 at 1:49 AM, Gilles
> <[hidden email]>
> wrote:
>
>> Hello.
>>
>> JIRA lists 12 unresolved issues for the v1.0 target.
>>
>> After quite a lot of nice work, nearly zero activity in
>> the last 6 months...
>>
>> Regards,
>> Gilles


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

Reply | Threaded
Open this post in threaded view
|

Re: [Numbers] Where do we stand?

Gilles Sadowski
Hi Eric.

It would be great if we could either resolve the following issues
or have a path forward for them that would not block the release
of "Commons Numbers":
   https://issues.apache.org/jira/browse/MATH-1445
   https://issues.apache.org/jira/browse/NUMBERS-54
   https://issues.apache.org/jira/browse/NUMBERS-2
   https://issues.apache.org/jira/browse/NUMBERS-17

Thanks,
Gilles


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

Reply | Threaded
Open this post in threaded view
|

Re: [Numbers] Where do we stand?

Eric Barnhill
On Wed, Jan 31, 2018 at 2:25 PM, Gilles <[hidden email]>
wrote:

> Hi Eric.
>
> It would be great if we could either resolve the following issues
> or have a path forward for them that would not block the release
> of "Commons Numbers":
>   https://issues.apache.org/jira/browse/MATH-1445


So, to resolve this I should remove some of the Complex libraries from
math-4 or math-3.x and replace them with a dependency on Numbers? Just want
to check if I understand. Not all of the old numbers functionality was
brought over (e.g. ComplexField). Also how does this impede release of
Numbers.


>
>   https://issues.apache.org/jira/browse/NUMBERS-54
>   https://issues.apache.org/jira/browse/NUMBERS-2


So ComplexUtils should be converted Java 8 syntax too. Well, might as well
do it at the same time. I'll be a proper streaming expert by the end of all
of it.


>
>   https://issues.apache.org/jira/browse/NUMBERS-17


Comment added to JIRA, this can be closed.

Eric
Reply | Threaded
Open this post in threaded view
|

Re: [Numbers] Where do we stand?

Gilles Sadowski
On Wed, 31 Jan 2018 15:04:50 +0100, Eric Barnhill wrote:

> On Wed, Jan 31, 2018 at 2:25 PM, Gilles
> <[hidden email]>
> wrote:
>
>> Hi Eric.
>>
>> It would be great if we could either resolve the following issues
>> or have a path forward for them that would not block the release
>> of "Commons Numbers":
>>   https://issues.apache.org/jira/browse/MATH-1445
>
>
> So, to resolve this I should remove some of the Complex libraries
> from
> math-4

Yes.

> or math-3.x

No. [Branch "MATH_3_X" is way too old.]

> and replace them with a dependency on Numbers?

Right.

> Just want
> to check if I understand.

CM is a testing ground: CM algorithms that use concepts that were
re-implemented in in "Numbers" should work as they did when those
concepts were implemented in CM.
When the unit tests still pass, it increases the confidence that
the ported code works as expected.

> Not all of the old numbers functionality was
> brought over (e.g. ComplexField).

Indeed.
There's work about "Field" in a separate branch: see issue
NUMBERS-51.  I'll write another post about it.

However, a lot of code does not need "Field".
In particular, "ComplexField" is never used.

> Also how does this impede release of
> Numbers.

It doesn't.
But we don't want to leave a bug that could have been
spotted by usage, as mentioned above.

>>   https://issues.apache.org/jira/browse/NUMBERS-54
>>   https://issues.apache.org/jira/browse/NUMBERS-2
>
>
> So ComplexUtils should be converted Java 8 syntax too. Well, might as
> well
> do it at the same time. I'll be a proper streaming expert by the end
> of all
> of it.

It's a suggestion.  What do you think?
IMHO, we should avoid bloating the API, especially if a
better alternative can be proposed (possibly in v1.1).
I'd thus propose to not ship the first release with
"ComplexUtils". Also, it's a higher-level code that might
deserve to be put in its own package/module (to depend on
"commons-numbers-complex".

Regards,
Gilles

>
>
>>
>>   https://issues.apache.org/jira/browse/NUMBERS-17
>
>
> Comment added to JIRA, this can be closed.
>
> Eric


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

Reply | Threaded
Open this post in threaded view
|

Re: [Numbers] Where do we stand?

Rob Tompkins


> On Jan 31, 2018, at 5:55 PM, Gilles <[hidden email]> wrote:
>
>> On Wed, 31 Jan 2018 15:04:50 +0100, Eric Barnhill wrote:
>> On Wed, Jan 31, 2018 at 2:25 PM, Gilles <[hidden email]>
>> wrote:
>>
>>> Hi Eric.
>>>
>>> It would be great if we could either resolve the following issues
>>> or have a path forward for them that would not block the release
>>> of "Commons Numbers":
>>>  https://issues.apache.org/jira/browse/MATH-1445
>>
>>
>> So, to resolve this I should remove some of the Complex libraries from
>> math-4
>
> Yes.
>
>> or math-3.x
>
> No. [Branch "MATH_3_X" is way too old.]

It feels a bit heavy handed to call the branch containing the latest release “old.” Sure we have substantive work that’s diverged from that branch, but it still remains the latest publicly available consumable artifact and thus warrants minimally security fixes if not considerably value.

>
>> and replace them with a dependency on Numbers?
>
> Right.
>
>> Just want
>> to check if I understand.
>
> CM is a testing ground: CM algorithms that use concepts that were
> re-implemented in in "Numbers" should work as they did when those
> concepts were implemented in CM.
> When the unit tests still pass, it increases the confidence that
> the ported code works as expected.
>
>> Not all of the old numbers functionality was
>> brought over (e.g. ComplexField).
>
> Indeed.
> There's work about "Field" in a separate branch: see issue
> NUMBERS-51.  I'll write another post about it.
>
> However, a lot of code does not need "Field".
> In particular, "ComplexField" is never used.
>
>> Also how does this impede release of
>> Numbers.
>
> It doesn't.
> But we don't want to leave a bug that could have been
> spotted by usage, as mentioned above.
>
>>>  https://issues.apache.org/jira/browse/NUMBERS-54
>>>  https://issues.apache.org/jira/browse/NUMBERS-2
>>
>>
>> So ComplexUtils should be converted Java 8 syntax too. Well, might as well
>> do it at the same time. I'll be a proper streaming expert by the end of all
>> of it.
>
> It's a suggestion.  What do you think?
> IMHO, we should avoid bloating the API, especially if a
> better alternative can be proposed (possibly in v1.1).
> I'd thus propose to not ship the first release with
> "ComplexUtils". Also, it's a higher-level code that might
> deserve to be put in its own package/module (to depend on
> "commons-numbers-complex".
>
> Regards,
> Gilles
>
>>
>>
>>>
>>>  https://issues.apache.org/jira/browse/NUMBERS-17
>>
>>
>> Comment added to JIRA, this can be closed.
>>
>> Eric
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [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] Where do we stand?

Rob Tompkins


> On Jan 31, 2018, at 6:46 PM, Rob Tompkins <[hidden email]> wrote:
>
>
>
>>> On Jan 31, 2018, at 5:55 PM, Gilles <[hidden email]> wrote:
>>>
>>> On Wed, 31 Jan 2018 15:04:50 +0100, Eric Barnhill wrote:
>>> On Wed, Jan 31, 2018 at 2:25 PM, Gilles <[hidden email]>
>>> wrote:
>>>
>>>> Hi Eric.
>>>>
>>>> It would be great if we could either resolve the following issues
>>>> or have a path forward for them that would not block the release
>>>> of "Commons Numbers":
>>>> https://issues.apache.org/jira/browse/MATH-1445
>>>
>>>
>>> So, to resolve this I should remove some of the Complex libraries from
>>> math-4
>>
>> Yes.
>>
>>> or math-3.x
>>
>> No. [Branch "MATH_3_X" is way too old.]
>
> It feels a bit heavy handed to call the branch containing the latest release “old.” Sure we have substantive work that’s diverged from that branch, but it still remains the latest publicly available consumable artifact and thus warrants minimally security fixes if not considerably value.

Pardon I missed the bit about where we lift code from. Makes sense then.

>
>>
>>> and replace them with a dependency on Numbers?
>>
>> Right.
>>
>>> Just want
>>> to check if I understand.
>>
>> CM is a testing ground: CM algorithms that use concepts that were
>> re-implemented in in "Numbers" should work as they did when those
>> concepts were implemented in CM.
>> When the unit tests still pass, it increases the confidence that
>> the ported code works as expected.
>>
>>> Not all of the old numbers functionality was
>>> brought over (e.g. ComplexField).
>>
>> Indeed.
>> There's work about "Field" in a separate branch: see issue
>> NUMBERS-51.  I'll write another post about it.
>>
>> However, a lot of code does not need "Field".
>> In particular, "ComplexField" is never used.
>>
>>> Also how does this impede release of
>>> Numbers.
>>
>> It doesn't.
>> But we don't want to leave a bug that could have been
>> spotted by usage, as mentioned above.
>>
>>>> https://issues.apache.org/jira/browse/NUMBERS-54
>>>> https://issues.apache.org/jira/browse/NUMBERS-2
>>>
>>>
>>> So ComplexUtils should be converted Java 8 syntax too. Well, might as well
>>> do it at the same time. I'll be a proper streaming expert by the end of all
>>> of it.
>>
>> It's a suggestion.  What do you think?
>> IMHO, we should avoid bloating the API, especially if a
>> better alternative can be proposed (possibly in v1.1).
>> I'd thus propose to not ship the first release with
>> "ComplexUtils". Also, it's a higher-level code that might
>> deserve to be put in its own package/module (to depend on
>> "commons-numbers-complex".
>>
>> Regards,
>> Gilles
>>
>>>
>>>
>>>>
>>>> https://issues.apache.org/jira/browse/NUMBERS-17
>>>
>>>
>>> Comment added to JIRA, this can be closed.
>>>
>>> Eric
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>

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