

Hi.
How about renaming the component to "Commons Numbers" (or another name
if preferred) that would contain the following modules:
* commonsnumberscore (with classes such as "Precision").
* commonsnumberscomplex
* commonsnumbersquaternion
* commonsnumbersfraction
* commonsnumberscontinuedfraction
* commonsnumbersfft (Fast Fourier Transform)
* commonsnumbersfct (Fast Cosine Transform)
* ...
?
Gilles

To unsubscribe, email: [hidden email]
For additional commands, email: [hidden email]


It is overall a fine plan by me. A precision class makes more sense than
duplicating equals methods.
From a practical standpoint I think it would be better to see Quaternion in
its own subpackage than with Complex. Simply because I don't use them and
packages are better maintained by those who use them.
It is hard to see how the transforms fit in. If anything they belong with
the new sigproc libraries.
Eric
On 8 Jan 2017 10:17, "Gilles" < [hidden email]> wrote:
> Hi.
>
> How about renaming the component to "Commons Numbers" (or another name
> if preferred) that would contain the following modules:
> * commonsnumberscore (with classes such as "Precision").
> * commonsnumberscomplex
> * commonsnumbersquaternion
> * commonsnumbersfraction
> * commonsnumberscontinuedfraction
> * commonsnumbersfft (Fast Fourier Transform)
> * commonsnumbersfct (Fast Cosine Transform)
> * ...
> ?
>
> Gilles
>
>
> 
> To unsubscribe, email: [hidden email]
> For additional commands, email: [hidden email]
>
>


On Mon, 9 Jan 2017 09:08:18 +0100, Eric Barnhill wrote:
> It is overall a fine plan by me. A precision class makes more sense
> than
> duplicating equals methods.
>
> From a practical standpoint I think it would be better to see
> Quaternion in
> its own subpackage than with Complex. Simply because I don't use them
> and
> packages are better maintained by those who use them.
>
> It is hard to see how the transforms fit in. If anything they belong
> with
> the new sigproc libraries.
Fine.
Is there any objection on the name "Commons Numbers"?
Are there better matches for the intended scope? [Or do we want that
the scope grows to also contain the "o.a.c.math4.prime" package" and
possibly more of numbertheoretic functionality (as was proposed some
time ago to be added to Commons Math)?]
Shall I wait a couple of days before filing the request with INFRA?
[I.e. to change the "git" repository, JIRA project and github mirror.]
Gilles
>
> Eric
> On 8 Jan 2017 10:17, "Gilles" < [hidden email]> wrote:
>
>> Hi.
>>
>> How about renaming the component to "Commons Numbers" (or another
>> name
>> if preferred) that would contain the following modules:
>> * commonsnumberscore (with classes such as "Precision").
>> * commonsnumberscomplex
>> * commonsnumbersquaternion
>> * commonsnumbersfraction
>> * commonsnumberscontinuedfraction
>> * commonsnumbersfft (Fast Fourier Transform)
>> * commonsnumbersfct (Fast Cosine Transform)
>> * ...
>> ?
>>
>> Gilles
>>
>>

To unsubscribe, email: [hidden email]
For additional commands, email: [hidden email]


On 9 January 2017 at 11:46, Gilles < [hidden email]> wrote:
> On Mon, 9 Jan 2017 09:08:18 +0100, Eric Barnhill wrote:
>>
>> It is overall a fine plan by me. A precision class makes more sense than
>> duplicating equals methods.
>>
>> From a practical standpoint I think it would be better to see Quaternion
>> in
>> its own subpackage than with Complex. Simply because I don't use them and
>> packages are better maintained by those who use them.
>>
>> It is hard to see how the transforms fit in. If anything they belong with
>> the new sigproc libraries.
>
>
> Fine.
>
> Is there any objection on the name "Commons Numbers"?
Since the namespace belongs to the whole of Commons, this question
should be posed to all of Commons, i.e. using the [ALL] prefix.
> Are there better matches for the intended scope? [Or do we want that
> the scope grows to also contain the "o.a.c.math4.prime" package" and
> possibly more of numbertheoretic functionality (as was proposed some
> time ago to be added to Commons Math)?]
>
> Shall I wait a couple of days before filing the request with INFRA?
> [I.e. to change the "git" repository, JIRA project and github mirror.]
>
>
> Gilles
>
>
>>
>> Eric
>> On 8 Jan 2017 10:17, "Gilles" < [hidden email]> wrote:
>>
>>> Hi.
>>>
>>> How about renaming the component to "Commons Numbers" (or another name
>>> if preferred) that would contain the following modules:
>>> * commonsnumberscore (with classes such as "Precision").
>>> * commonsnumberscomplex
>>> * commonsnumbersquaternion
>>> * commonsnumbersfraction
>>> * commonsnumberscontinuedfraction
>>> * commonsnumbersfft (Fast Fourier Transform)
>>> * commonsnumbersfct (Fast Cosine Transform)
>>> * ...
>>> ?
>>>
>>> Gilles
>>>
>>>
>
>
> 
> To unsubscribe, email: [hidden email]
> For additional commands, email: [hidden email]
>

To unsubscribe, email: [hidden email]
For additional commands, email: [hidden email]


See discussion thread, copied below.
[ ] Yes
[ ] Yes but I prefer this name: ...
[ ] No, because ...
I'll assume that this is a lazy consensus vote, to be closed in 72
hours
from now (i.e. on January 12, at 18:00:00 UTC).
Thanks,
Gilles
On Mon, 9 Jan 2017 15:57:51 +0000, sebb wrote:
> On 9 January 2017 at 11:46, Gilles < [hidden email]>
> wrote:
>> On Mon, 9 Jan 2017 09:08:18 +0100, Eric Barnhill wrote:
>>>
>>> It is overall a fine plan by me. A precision class makes more sense
>>> than
>>> duplicating equals methods.
>>>
>>> From a practical standpoint I think it would be better to see
>>> Quaternion
>>> in
>>> its own subpackage than with Complex. Simply because I don't use
>>> them and
>>> packages are better maintained by those who use them.
>>>
>>> It is hard to see how the transforms fit in. If anything they
>>> belong with
>>> the new sigproc libraries.
>>
>>
>> Fine.
>>
>> Is there any objection on the name "Commons Numbers"?
>
> Since the namespace belongs to the whole of Commons, this question
> should be posed to all of Commons, i.e. using the [ALL] prefix.
>
>> Are there better matches for the intended scope? [Or do we want that
>> the scope grows to also contain the "o.a.c.math4.prime" package" and
>> possibly more of numbertheoretic functionality (as was proposed
>> some
>> time ago to be added to Commons Math)?]
>>
>> Shall I wait a couple of days before filing the request with INFRA?
>> [I.e. to change the "git" repository, JIRA project and github
>> mirror.]
>>
>>
>> Gilles
>>
>>
>>>
>>> Eric
>>> On 8 Jan 2017 10:17, "Gilles" < [hidden email]> wrote:
>>>
>>>> Hi.
>>>>
>>>> How about renaming the component to "Commons Numbers" (or another
>>>> name
>>>> if preferred) that would contain the following modules:
>>>> * commonsnumberscore (with classes such as "Precision").
>>>> * commonsnumberscomplex
>>>> * commonsnumbersquaternion
>>>> * commonsnumbersfraction
>>>> * commonsnumberscontinuedfraction
>>>> * commonsnumbersfft (Fast Fourier Transform)
>>>> * commonsnumbersfct (Fast Cosine Transform)
>>>> * ...
>>>> ?
>>>>
>>>> Gilles
>>>>
>>>>
>>
>>

To unsubscribe, email: [hidden email]
For additional commands, email: [hidden email]


Are the originally mentioned transforms in or out of scope of
commonsnumbers?
Brent
On Mon, Jan 9, 2017 at 12:02 PM, Gilles < [hidden email]>
wrote:
> See discussion thread, copied below.
>
> [ ] Yes
> [ ] Yes but I prefer this name: ...
> [ ] No, because ...
>
> I'll assume that this is a lazy consensus vote, to be closed in 72 hours
> from now (i.e. on January 12, at 18:00:00 UTC).
>
> Thanks,
> Gilles
>
>
> On Mon, 9 Jan 2017 15:57:51 +0000, sebb wrote:
>
>> On 9 January 2017 at 11:46, Gilles < [hidden email]> wrote:
>>
>>> On Mon, 9 Jan 2017 09:08:18 +0100, Eric Barnhill wrote:
>>>
>>>>
>>>> It is overall a fine plan by me. A precision class makes more sense than
>>>> duplicating equals methods.
>>>>
>>>> From a practical standpoint I think it would be better to see Quaternion
>>>> in
>>>> its own subpackage than with Complex. Simply because I don't use them
>>>> and
>>>> packages are better maintained by those who use them.
>>>>
>>>> It is hard to see how the transforms fit in. If anything they belong
>>>> with
>>>> the new sigproc libraries.
>>>>
>>>
>>>
>>> Fine.
>>>
>>> Is there any objection on the name "Commons Numbers"?
>>>
>>
>> Since the namespace belongs to the whole of Commons, this question
>> should be posed to all of Commons, i.e. using the [ALL] prefix.
>>
>> Are there better matches for the intended scope? [Or do we want that
>>> the scope grows to also contain the "o.a.c.math4.prime" package" and
>>> possibly more of numbertheoretic functionality (as was proposed some
>>> time ago to be added to Commons Math)?]
>>>
>>> Shall I wait a couple of days before filing the request with INFRA?
>>> [I.e. to change the "git" repository, JIRA project and github mirror.]
>>>
>>>
>>> Gilles
>>>
>>>
>>>
>>>> Eric
>>>> On 8 Jan 2017 10:17, "Gilles" < [hidden email]> wrote:
>>>>
>>>> Hi.
>>>>>
>>>>> How about renaming the component to "Commons Numbers" (or another name
>>>>> if preferred) that would contain the following modules:
>>>>> * commonsnumberscore (with classes such as "Precision").
>>>>> * commonsnumberscomplex
>>>>> * commonsnumbersquaternion
>>>>> * commonsnumbersfraction
>>>>> * commonsnumberscontinuedfraction
>>>>> * commonsnumbersfft (Fast Fourier Transform)
>>>>> * commonsnumbersfct (Fast Cosine Transform)
>>>>> * ...
>>>>> ?
>>>>>
>>>>> Gilles
>>>>>
>>>>>
>>>>>
>>>
>>>
>
> 
> To unsubscribe, email: [hidden email]
> For additional commands, email: [hidden email]
>
>


On Mon, 9 Jan 2017 17:56:32 0600, Brent Worden wrote:
> Are the originally mentioned transforms in or out of scope of
> commonsnumbers?
It depends on the scope.
Hence my asking about the name.
There could be a rationale that the transforms are "applications"
of the concept of complex numbers, similarly to the claim that
anything that had the word "random" in its description (such as
for the "sampling" functionality) had to be part of "Commons RNG".
Even though my opinion is still that such a relationship is not
the best criterion for defining scope, including the transforms
was a compromise (to reach consensus about getting things to move
without bumping again the count of "Commons" components).
But I actually prefer to have a "Commons FFT" component that would
depend on the "commonscomplex" module of "Commons Numbers".
Then, "Commons SigProc" would define its own FFT interface(s) and
users would be free to bridge them to whatever implementations
they choose.
Alternatively, it is up to the "SigProc" developers to assess whether
they would be happy to include the implementation from "Commons Math",
or directly depend on another (perhaps more performant) library.
Gilles
>
> Brent
>
> On Mon, Jan 9, 2017 at 12:02 PM, Gilles
> < [hidden email]>
> wrote:
>
>> See discussion thread, copied below.
>>
>> [ ] Yes
>> [ ] Yes but I prefer this name: ...
>> [ ] No, because ...
>>
>> I'll assume that this is a lazy consensus vote, to be closed in 72
>> hours
>> from now (i.e. on January 12, at 18:00:00 UTC).
>>
>> Thanks,
>> Gilles
>>
>>
>> On Mon, 9 Jan 2017 15:57:51 +0000, sebb wrote:
>>
>>> On 9 January 2017 at 11:46, Gilles < [hidden email]>
>>> wrote:
>>>
>>>> On Mon, 9 Jan 2017 09:08:18 +0100, Eric Barnhill wrote:
>>>>
>>>>>
>>>>> It is overall a fine plan by me. A precision class makes more
>>>>> sense than
>>>>> duplicating equals methods.
>>>>>
>>>>> From a practical standpoint I think it would be better to see
>>>>> Quaternion
>>>>> in
>>>>> its own subpackage than with Complex. Simply because I don't use
>>>>> them
>>>>> and
>>>>> packages are better maintained by those who use them.
>>>>>
>>>>> It is hard to see how the transforms fit in. If anything they
>>>>> belong
>>>>> with
>>>>> the new sigproc libraries.
>>>>>
>>>>
>>>>
>>>> Fine.
>>>>
>>>> Is there any objection on the name "Commons Numbers"?
>>>>
>>>
>>> Since the namespace belongs to the whole of Commons, this question
>>> should be posed to all of Commons, i.e. using the [ALL] prefix.
>>>
>>> Are there better matches for the intended scope? [Or do we want
>>> that
>>>> the scope grows to also contain the "o.a.c.math4.prime" package"
>>>> and
>>>> possibly more of numbertheoretic functionality (as was proposed
>>>> some
>>>> time ago to be added to Commons Math)?]
>>>>
>>>> Shall I wait a couple of days before filing the request with
>>>> INFRA?
>>>> [I.e. to change the "git" repository, JIRA project and github
>>>> mirror.]
>>>>
>>>>
>>>> Gilles
>>>>
>>>>
>>>>
>>>>> Eric
>>>>> On 8 Jan 2017 10:17, "Gilles" < [hidden email]>
>>>>> wrote:
>>>>>
>>>>> Hi.
>>>>>>
>>>>>> How about renaming the component to "Commons Numbers" (or
>>>>>> another name
>>>>>> if preferred) that would contain the following modules:
>>>>>> * commonsnumberscore (with classes such as "Precision").
>>>>>> * commonsnumberscomplex
>>>>>> * commonsnumbersquaternion
>>>>>> * commonsnumbersfraction
>>>>>> * commonsnumberscontinuedfraction
>>>>>> * commonsnumbersfft (Fast Fourier Transform)
>>>>>> * commonsnumbersfct (Fast Cosine Transform)
>>>>>> * ...
>>>>>> ?
>>>>>>
>>>>>> Gilles
>>>>>>

To unsubscribe, email: [hidden email]
For additional commands, email: [hidden email]


Hi Gilles,
Gilles wrote:
> Hi.
>
> How about renaming the component to "Commons Numbers" (or another name
> if preferred) that would contain the following modules:
> * commonsnumberscore (with classes such as "Precision").
> * commonsnumberscomplex
> * commonsnumbersquaternion
> * commonsnumbersfraction
> * commonsnumberscontinuedfraction
> * commonsnumbersfft (Fast Fourier Transform)
> * commonsnumbersfct (Fast Cosine Transform)
> * ...
> ?
>
> Gilles
As long as it does not mean, we have individual release cycles for these
modules...
Cheers,
Jörg

To unsubscribe, email: [hidden email]
For additional commands, email: [hidden email]


On Tue, 10 Jan 2017 20:23:26 +0100, Jörg Schaible wrote:
> Hi Gilles,
>
> Gilles wrote:
>
>> Hi.
>>
>> How about renaming the component to "Commons Numbers" (or another
>> name
>> if preferred) that would contain the following modules:
>> * commonsnumberscore (with classes such as "Precision").
>> * commonsnumberscomplex
>> * commonsnumbersquaternion
>> * commonsnumbersfraction
>> * commonsnumberscontinuedfraction
>> * commonsnumbersfft (Fast Fourier Transform)
>> * commonsnumbersfct (Fast Cosine Transform)
>> * ...
>> ?
>>
>> Gilles
>
> As long as it does not mean, we have individual release cycles for
> these
> modules...
Got it... last time, already. ;)
Seriously, that limitation alone should favour the "one concept, one
component" solution. No? Oh I already said that too, I think...
I really don't grok why a subpar (by much) solution is preferred
just because of the assumption that there will be more review work.
That won't be so, if review is performed on a regular basis and work
is distributed among all developers (active and passive). The smaller
the codebase, the easier it is to spot something "strange".
Big components are intimidating and I won't be surprised that people
tend to skip them entirely, or stay focused on selected parts, without
considering the bigger picture).
Gilles
> Cheers,
> Jörg
>
>

To unsubscribe, email: [hidden email]
For additional commands, email: [hidden email]


+1
On Tue, Jan 10, 2017 at 12:56 AM, Brent Worden < [hidden email]>
wrote:
> Are the originally mentioned transforms in or out of scope of
> commonsnumbers?
>
> Brent
>
> On Mon, Jan 9, 2017 at 12:02 PM, Gilles < [hidden email]>
> wrote:
>
> > See discussion thread, copied below.
> >
> > [ ] Yes
> > [ ] Yes but I prefer this name: ...
> > [ ] No, because ...
> >
> > I'll assume that this is a lazy consensus vote, to be closed in 72 hours
> > from now (i.e. on January 12, at 18:00:00 UTC).
> >
> > Thanks,
> > Gilles
> >
> >
> > On Mon, 9 Jan 2017 15:57:51 +0000, sebb wrote:
> >
> >> On 9 January 2017 at 11:46, Gilles < [hidden email]>
> wrote:
> >>
> >>> On Mon, 9 Jan 2017 09:08:18 +0100, Eric Barnhill wrote:
> >>>
> >>>>
> >>>> It is overall a fine plan by me. A precision class makes more sense
> than
> >>>> duplicating equals methods.
> >>>>
> >>>> From a practical standpoint I think it would be better to see
> Quaternion
> >>>> in
> >>>> its own subpackage than with Complex. Simply because I don't use them
> >>>> and
> >>>> packages are better maintained by those who use them.
> >>>>
> >>>> It is hard to see how the transforms fit in. If anything they belong
> >>>> with
> >>>> the new sigproc libraries.
> >>>>
> >>>
> >>>
> >>> Fine.
> >>>
> >>> Is there any objection on the name "Commons Numbers"?
> >>>
> >>
> >> Since the namespace belongs to the whole of Commons, this question
> >> should be posed to all of Commons, i.e. using the [ALL] prefix.
> >>
> >> Are there better matches for the intended scope? [Or do we want that
> >>> the scope grows to also contain the "o.a.c.math4.prime" package" and
> >>> possibly more of numbertheoretic functionality (as was proposed some
> >>> time ago to be added to Commons Math)?]
> >>>
> >>> Shall I wait a couple of days before filing the request with INFRA?
> >>> [I.e. to change the "git" repository, JIRA project and github mirror.]
> >>>
> >>>
> >>> Gilles
> >>>
> >>>
> >>>
> >>>> Eric
> >>>> On 8 Jan 2017 10:17, "Gilles" < [hidden email]> wrote:
> >>>>
> >>>> Hi.
> >>>>>
> >>>>> How about renaming the component to "Commons Numbers" (or another
> name
> >>>>> if preferred) that would contain the following modules:
> >>>>> * commonsnumberscore (with classes such as "Precision").
> >>>>> * commonsnumberscomplex
> >>>>> * commonsnumbersquaternion
> >>>>> * commonsnumbersfraction
> >>>>> * commonsnumberscontinuedfraction
> >>>>> * commonsnumbersfft (Fast Fourier Transform)
> >>>>> * commonsnumbersfct (Fast Cosine Transform)
> >>>>> * ...
> >>>>> ?
> >>>>>
> >>>>> Gilles
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >
> > 
> > To unsubscribe, email: [hidden email]
> > For additional commands, email: [hidden email]
> >
> >
>


+1
> On Jan 11, 2017, at 8:39 AM, Eric Barnhill < [hidden email]> wrote:
>
> +1
>
> On Tue, Jan 10, 2017 at 12:56 AM, Brent Worden < [hidden email]>
> wrote:
>
>> Are the originally mentioned transforms in or out of scope of
>> commonsnumbers?
>>
>> Brent
>>
>> On Mon, Jan 9, 2017 at 12:02 PM, Gilles < [hidden email]>
>> wrote:
>>
>>> See discussion thread, copied below.
>>>
>>> [ ] Yes
>>> [ ] Yes but I prefer this name: ...
>>> [ ] No, because ...
>>>
>>> I'll assume that this is a lazy consensus vote, to be closed in 72 hours
>>> from now (i.e. on January 12, at 18:00:00 UTC).
>>>
>>> Thanks,
>>> Gilles
>>>
>>>
>>> On Mon, 9 Jan 2017 15:57:51 +0000, sebb wrote:
>>>
>>>> On 9 January 2017 at 11:46, Gilles < [hidden email]>
>> wrote:
>>>>
>>>>> On Mon, 9 Jan 2017 09:08:18 +0100, Eric Barnhill wrote:
>>>>>
>>>>>>
>>>>>> It is overall a fine plan by me. A precision class makes more sense
>> than
>>>>>> duplicating equals methods.
>>>>>>
>>>>>> From a practical standpoint I think it would be better to see
>> Quaternion
>>>>>> in
>>>>>> its own subpackage than with Complex. Simply because I don't use them
>>>>>> and
>>>>>> packages are better maintained by those who use them.
>>>>>>
>>>>>> It is hard to see how the transforms fit in. If anything they belong
>>>>>> with
>>>>>> the new sigproc libraries.
>>>>>>
>>>>>
>>>>>
>>>>> Fine.
>>>>>
>>>>> Is there any objection on the name "Commons Numbers"?
>>>>>
>>>>
>>>> Since the namespace belongs to the whole of Commons, this question
>>>> should be posed to all of Commons, i.e. using the [ALL] prefix.
>>>>
>>>> Are there better matches for the intended scope? [Or do we want that
>>>>> the scope grows to also contain the "o.a.c.math4.prime" package" and
>>>>> possibly more of numbertheoretic functionality (as was proposed some
>>>>> time ago to be added to Commons Math)?]
>>>>>
>>>>> Shall I wait a couple of days before filing the request with INFRA?
>>>>> [I.e. to change the "git" repository, JIRA project and github mirror.]
>>>>>
>>>>>
>>>>> Gilles
>>>>>
>>>>>
>>>>>
>>>>>> Eric
>>>>>> On 8 Jan 2017 10:17, "Gilles" < [hidden email]> wrote:
>>>>>>
>>>>>> Hi.
>>>>>>>
>>>>>>> How about renaming the component to "Commons Numbers" (or another
>> name
>>>>>>> if preferred) that would contain the following modules:
>>>>>>> * commonsnumberscore (with classes such as "Precision").
>>>>>>> * commonsnumberscomplex
>>>>>>> * commonsnumbersquaternion
>>>>>>> * commonsnumbersfraction
>>>>>>> * commonsnumberscontinuedfraction
>>>>>>> * commonsnumbersfft (Fast Fourier Transform)
>>>>>>> * commonsnumbersfct (Fast Cosine Transform)
>>>>>>> * ...
>>>>>>> ?
>>>>>>>
>>>>>>> Gilles
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>> 
>>> To unsubscribe, email: [hidden email]
>>> For additional commands, email: [hidden email]
>>>
>>>
>>

To unsubscribe, email: [hidden email]
For additional commands, email: [hidden email]


+1
Gilles wrote:
> See discussion thread, copied below.
>
> [ ] Yes
> [ ] Yes but I prefer this name: ...
> [ ] No, because ...
>
> I'll assume that this is a lazy consensus vote, to be closed in 72
> hours
> from now (i.e. on January 12, at 18:00:00 UTC).
>
> Thanks,
> Gilles

To unsubscribe, email: [hidden email]
For additional commands, email: [hidden email]


+1, but without the transforms.
Emmanuel Bourg
Le 9/01/2017 à 19:02, Gilles a écrit :
> See discussion thread, copied below.
>
> [ ] Yes
> [ ] Yes but I prefer this name: ...
> [ ] No, because ...
>
> I'll assume that this is a lazy consensus vote, to be closed in 72 hours
> from now (i.e. on January 12, at 18:00:00 UTC).
>
> Thanks,
> Gilles
>
>
> On Mon, 9 Jan 2017 15:57:51 +0000, sebb wrote:
>
>
> 
> To unsubscribe, email: [hidden email]
> For additional commands, email: [hidden email]
>

To unsubscribe, email: [hidden email]
For additional commands, email: [hidden email]


> On Jan 11, 2017, at 7:23 PM, Emmanuel Bourg < [hidden email]> wrote:
>
> +1, but without the transforms.
>
Yes. The transforms do seem a tad out of place.
> Emmanuel Bourg
>
>
>> Le 9/01/2017 à 19:02, Gilles a écrit :
>> See discussion thread, copied below.
>>
>> [ ] Yes
>> [ ] Yes but I prefer this name: ...
>> [ ] No, because ...
>>
>> I'll assume that this is a lazy consensus vote, to be closed in 72 hours
>> from now (i.e. on January 12, at 18:00:00 UTC).
>>
>> Thanks,
>> Gilles
>>
>>
>> On Mon, 9 Jan 2017 15:57:51 +0000, sebb wrote:
>>
>>
>> 
>> To unsubscribe, email: [hidden email]
>> For additional commands, email: [hidden email]
>>
>
>
> 
> To unsubscribe, email: [hidden email]
> For additional commands, email: [hidden email]
>

To unsubscribe, email: [hidden email]
For additional commands, email: [hidden email]


The following people
Eric Barnhill
Rob Tompkins
Jörg Schaible
Emmanuel Bourg
voted +1
Vote passes.
Gilles
On Mon, 09 Jan 2017 19:02:04 +0100, Gilles wrote:
> See discussion thread, copied below.
>
> [ ] Yes
> [ ] Yes but I prefer this name: ...
> [ ] No, because ...
>
> I'll assume that this is a lazy consensus vote, to be closed in 72
> hours
> from now (i.e. on January 12, at 18:00:00 UTC).
>
> Thanks,
> Gilles
>
>
> On Mon, 9 Jan 2017 15:57:51 +0000, sebb wrote:
>> On 9 January 2017 at 11:46, Gilles < [hidden email]>
>> wrote:
>>> On Mon, 9 Jan 2017 09:08:18 +0100, Eric Barnhill wrote:
>>>>
>>>> It is overall a fine plan by me. A precision class makes more
>>>> sense than
>>>> duplicating equals methods.
>>>>
>>>> From a practical standpoint I think it would be better to see
>>>> Quaternion
>>>> in
>>>> its own subpackage than with Complex. Simply because I don't use
>>>> them and
>>>> packages are better maintained by those who use them.
>>>>
>>>> It is hard to see how the transforms fit in. If anything they
>>>> belong with
>>>> the new sigproc libraries.
>>>
>>>
>>> Fine.
>>>
>>> Is there any objection on the name "Commons Numbers"?
>>
>> Since the namespace belongs to the whole of Commons, this question
>> should be posed to all of Commons, i.e. using the [ALL] prefix.
>>
>>> Are there better matches for the intended scope? [Or do we want
>>> that
>>> the scope grows to also contain the "o.a.c.math4.prime" package"
>>> and
>>> possibly more of numbertheoretic functionality (as was proposed
>>> some
>>> time ago to be added to Commons Math)?]
>>>
>>> Shall I wait a couple of days before filing the request with INFRA?
>>> [I.e. to change the "git" repository, JIRA project and github
>>> mirror.]
>>>
>>>
>>> Gilles
>>>
>>>
>>>>
>>>> Eric
>>>> On 8 Jan 2017 10:17, "Gilles" < [hidden email]>
>>>> wrote:
>>>>
>>>>> Hi.
>>>>>
>>>>> How about renaming the component to "Commons Numbers" (or another
>>>>> name
>>>>> if preferred) that would contain the following modules:
>>>>> * commonsnumberscore (with classes such as "Precision").
>>>>> * commonsnumberscomplex
>>>>> * commonsnumbersquaternion
>>>>> * commonsnumbersfraction
>>>>> * commonsnumberscontinuedfraction
>>>>> * commonsnumbersfft (Fast Fourier Transform)
>>>>> * commonsnumbersfct (Fast Cosine Transform)
>>>>> * ...
>>>>> ?
>>>>>
>>>>> Gilles
>>>>>
>>>>>
>>>

To unsubscribe, email: [hidden email]
For additional commands, email: [hidden email]


Let me know if there is anything I can do to help out with the transition.
On Thu, Jan 12, 2017 at 8:23 PM, Gilles < [hidden email]>
wrote:
> The following people
> Eric Barnhill
> Rob Tompkins
> Jörg Schaible
> Emmanuel Bourg
> voted +1
>
> Vote passes.
>
> Gilles
>
>
> On Mon, 09 Jan 2017 19:02:04 +0100, Gilles wrote:
>
>> See discussion thread, copied below.
>>
>> [ ] Yes
>> [ ] Yes but I prefer this name: ...
>> [ ] No, because ...
>>
>> I'll assume that this is a lazy consensus vote, to be closed in 72 hours
>> from now (i.e. on January 12, at 18:00:00 UTC).
>>
>> Thanks,
>> Gilles
>>
>>
>> On Mon, 9 Jan 2017 15:57:51 +0000, sebb wrote:
>>
>>> On 9 January 2017 at 11:46, Gilles < [hidden email]> wrote:
>>>
>>>> On Mon, 9 Jan 2017 09:08:18 +0100, Eric Barnhill wrote:
>>>>
>>>>>
>>>>> It is overall a fine plan by me. A precision class makes more sense
>>>>> than
>>>>> duplicating equals methods.
>>>>>
>>>>> From a practical standpoint I think it would be better to see
>>>>> Quaternion
>>>>> in
>>>>> its own subpackage than with Complex. Simply because I don't use them
>>>>> and
>>>>> packages are better maintained by those who use them.
>>>>>
>>>>> It is hard to see how the transforms fit in. If anything they belong
>>>>> with
>>>>> the new sigproc libraries.
>>>>>
>>>>
>>>>
>>>> Fine.
>>>>
>>>> Is there any objection on the name "Commons Numbers"?
>>>>
>>>
>>> Since the namespace belongs to the whole of Commons, this question
>>> should be posed to all of Commons, i.e. using the [ALL] prefix.
>>>
>>> Are there better matches for the intended scope? [Or do we want that
>>>> the scope grows to also contain the "o.a.c.math4.prime" package" and
>>>> possibly more of numbertheoretic functionality (as was proposed some
>>>> time ago to be added to Commons Math)?]
>>>>
>>>> Shall I wait a couple of days before filing the request with INFRA?
>>>> [I.e. to change the "git" repository, JIRA project and github mirror.]
>>>>
>>>>
>>>> Gilles
>>>>
>>>>
>>>>
>>>>> Eric
>>>>> On 8 Jan 2017 10:17, "Gilles" < [hidden email]> wrote:
>>>>>
>>>>> Hi.
>>>>>>
>>>>>> How about renaming the component to "Commons Numbers" (or another name
>>>>>> if preferred) that would contain the following modules:
>>>>>> * commonsnumberscore (with classes such as "Precision").
>>>>>> * commonsnumberscomplex
>>>>>> * commonsnumbersquaternion
>>>>>> * commonsnumbersfraction
>>>>>> * commonsnumberscontinuedfraction
>>>>>> * commonsnumbersfft (Fast Fourier Transform)
>>>>>> * commonsnumbersfct (Fast Cosine Transform)
>>>>>> * ...
>>>>>> ?
>>>>>>
>>>>>> Gilles
>>>>>>
>>>>>>
>>>>>>
>>>>
>
> 
> To unsubscribe, email: [hidden email]
> For additional commands, email: [hidden email]
>
>


On Tue, 17 Jan 2017 08:20:54 0500, Raymond DeCampo wrote:
> Let me know if there is anything I can do to help out with the
> transition.
Thanks for the offer! Very much appreciated.
I'm about to create a branch for making the project "multimodule"
(and do some cleanup on the way).
Sure you could help; but we are currently a bit stuck, since you do
not have commit privilege: if I'm the only committer reviewing your
pull requests, it will take me about the same time to do the initial
copying myself (mainly reproducing the layout of "Commons RNG"). :/
So, in the meantime, I'll move the respective codes to the "core",
"complex" and "quaternion" modules.
Then when the layout is set up, it should be straightforward to copy
other codes from "Commons Math" (into the respective "fraction" and
"continuedfraction" modules).
Then it will be time to decide which other functionality should move
to the new "Commons Numbers" component. Candidates are:
* o.a.c.math4.special
* (parts of) o.a.c.math4.analysis (e.g. the "solvers" package)
* o.a.c.math4.util.FastMath (and support classes)
* o.a.c.math4.util.MathUtils
* (part of) o.a.c.math4.util.MathArrays
* ...
Thanks for your patience,
Gilles
>
> On Thu, Jan 12, 2017 at 8:23 PM, Gilles
> < [hidden email]>
> wrote:
>
>> The following people
>> Eric Barnhill
>> Rob Tompkins
>> Jörg Schaible
>> Emmanuel Bourg
>> voted +1
>>
>> Vote passes.
>>
>> Gilles
>>
>>
>> [...]

To unsubscribe, email: [hidden email]
For additional commands, email: [hidden email]


Hi.
On Wed, 18 Jan 2017 02:46:19 +0100, Gilles wrote:
> On Tue, 17 Jan 2017 08:20:54 0500, Raymond DeCampo wrote:
>> Let me know if there is anything I can do to help out with the
>> transition.
>
> Thanks for the offer! Very much appreciated.
> I'm about to create a branch for making the project "multimodule"
> (and do some cleanup on the way).
>
> Sure you could help; but we are currently a bit stuck, since you do
> not have commit privilege: if I'm the only committer reviewing your
> pull requests, it will take me about the same time to do the initial
> copying myself (mainly reproducing the layout of "Commons RNG"). :/
>
> So, in the meantime, I'll move the respective codes to the "core",
> "complex" and "quaternion" modules.
Done.
>
> Then when the layout is set up, it should be straightforward to copy
> other codes from "Commons Math" (into the respective "fraction" and
> "continuedfraction" modules).
Feel free to tackle those.
Maybe the "ContinuedFraction" class should be included in
the "fraction" module (rather then have one of its own).
> Then it will be time to decide which other functionality should move
> to the new "Commons Numbers" component. Candidates are:
> * o.a.c.math4.special
> * (parts of) o.a.c.math4.analysis (e.g. the "solvers" package)
There are several in Commons Math. Shall we port only the more
robust and efficient ones (e.g. drop "RegulaFalsi")?
> * o.a.c.math4.util.FastMath (and support classes)
In "core" or in a module of its own?
> * o.a.c.math4.util.MathUtils
> * (part of) o.a.c.math4.util.MathArrays
Some array utilities are definitely needed (i.e. scalar and cross
products, linear combination). [Some unit tests of "QuaternionTest"
use "Vector3D", which is out of scope.].
Is module "core" the right place for "MathArrays"?
Is the name OK?
Gilles

To unsubscribe, email: [hidden email]
For additional commands, email: [hidden email]


Thanks Gilles, I think I have all the necessary git manipulations worked
out, I will see if I can create a "fraction" module.
On Wed, Jan 18, 2017 at 9:17 AM, Gilles < [hidden email]>
wrote:
> Hi.
>
> On Wed, 18 Jan 2017 02:46:19 +0100, Gilles wrote:
>
>> On Tue, 17 Jan 2017 08:20:54 0500, Raymond DeCampo wrote:
>>
>>> Let me know if there is anything I can do to help out with the
>>> transition.
>>>
>>
>> Thanks for the offer! Very much appreciated.
>> I'm about to create a branch for making the project "multimodule"
>> (and do some cleanup on the way).
>>
>> Sure you could help; but we are currently a bit stuck, since you do
>> not have commit privilege: if I'm the only committer reviewing your
>> pull requests, it will take me about the same time to do the initial
>> copying myself (mainly reproducing the layout of "Commons RNG"). :/
>>
>> So, in the meantime, I'll move the respective codes to the "core",
>> "complex" and "quaternion" modules.
>>
>
> Done.
>
>
>> Then when the layout is set up, it should be straightforward to copy
>> other codes from "Commons Math" (into the respective "fraction" and
>> "continuedfraction" modules).
>>
>
> Feel free to tackle those.
> Maybe the "ContinuedFraction" class should be included in
> the "fraction" module (rather then have one of its own).
>
> Then it will be time to decide which other functionality should move
>> to the new "Commons Numbers" component. Candidates are:
>> * o.a.c.math4.special
>> * (parts of) o.a.c.math4.analysis (e.g. the "solvers" package)
>>
>
> There are several in Commons Math. Shall we port only the more
> robust and efficient ones (e.g. drop "RegulaFalsi")?
>
> * o.a.c.math4.util.FastMath (and support classes)
>>
>
> In "core" or in a module of its own?
>
> * o.a.c.math4.util.MathUtils
>> * (part of) o.a.c.math4.util.MathArrays
>>
>
> Some array utilities are definitely needed (i.e. scalar and cross
> products, linear combination). [Some unit tests of "QuaternionTest"
> use "Vector3D", which is out of scope.].
>
> Is module "core" the right place for "MathArrays"?
> Is the name OK?
>
>
> Gilles
>
>
> 
> To unsubscribe, email: [hidden email]
> For additional commands, email: [hidden email]
>
>

