Hi.
How about renaming the component to "Commons Numbers" (or another name if preferred) that would contain the following modules: * commons-numbers-core (with classes such as "Precision"). * commons-numbers-complex * commons-numbers-quaternion * commons-numbers-fraction * commons-numbers-continued-fraction * commons-numbers-fft (Fast Fourier Transform) * commons-numbers-fct (Fast Cosine Transform) * ... ? Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [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: > * commons-numbers-core (with classes such as "Precision"). > * commons-numbers-complex > * commons-numbers-quaternion > * commons-numbers-fraction > * commons-numbers-continued-fraction > * commons-numbers-fft (Fast Fourier Transform) > * commons-numbers-fct (Fast Cosine Transform) > * ... > ? > > Gilles > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [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 number-theoretic 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: >> * commons-numbers-core (with classes such as "Precision"). >> * commons-numbers-complex >> * commons-numbers-quaternion >> * commons-numbers-fraction >> * commons-numbers-continued-fraction >> * commons-numbers-fft (Fast Fourier Transform) >> * commons-numbers-fct (Fast Cosine Transform) >> * ... >> ? >> >> Gilles >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [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 number-theoretic 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: >>> * commons-numbers-core (with classes such as "Precision"). >>> * commons-numbers-complex >>> * commons-numbers-quaternion >>> * commons-numbers-fraction >>> * commons-numbers-continued-fraction >>> * commons-numbers-fft (Fast Fourier Transform) >>> * commons-numbers-fct (Fast Cosine Transform) >>> * ... >>> ? >>> >>> Gilles >>> >>> > > > --------------------------------------------------------------------- > 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] |
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 number-theoretic 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: >>>> * commons-numbers-core (with classes such as "Precision"). >>>> * commons-numbers-complex >>>> * commons-numbers-quaternion >>>> * commons-numbers-fraction >>>> * commons-numbers-continued-fraction >>>> * commons-numbers-fft (Fast Fourier Transform) >>>> * commons-numbers-fct (Fast Cosine Transform) >>>> * ... >>>> ? >>>> >>>> Gilles >>>> >>>> >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
Are the originally mentioned transforms in or out of scope of
commons-numbers? 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 number-theoretic 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: >>>>> * commons-numbers-core (with classes such as "Precision"). >>>>> * commons-numbers-complex >>>>> * commons-numbers-quaternion >>>>> * commons-numbers-fraction >>>>> * commons-numbers-continued-fraction >>>>> * commons-numbers-fft (Fast Fourier Transform) >>>>> * commons-numbers-fct (Fast Cosine Transform) >>>>> * ... >>>>> ? >>>>> >>>>> Gilles >>>>> >>>>> >>>>> >>> >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [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 > commons-numbers? 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 "commons-complex" 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 number-theoretic 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: >>>>>> * commons-numbers-core (with classes such as "Precision"). >>>>>> * commons-numbers-complex >>>>>> * commons-numbers-quaternion >>>>>> * commons-numbers-fraction >>>>>> * commons-numbers-continued-fraction >>>>>> * commons-numbers-fft (Fast Fourier Transform) >>>>>> * commons-numbers-fct (Fast Cosine Transform) >>>>>> * ... >>>>>> ? >>>>>> >>>>>> Gilles >>>>>> --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
In reply to this post by Gilles Sadowski
Hi Gilles,
Gilles wrote: > Hi. > > How about renaming the component to "Commons Numbers" (or another name > if preferred) that would contain the following modules: > * commons-numbers-core (with classes such as "Precision"). > * commons-numbers-complex > * commons-numbers-quaternion > * commons-numbers-fraction > * commons-numbers-continued-fraction > * commons-numbers-fft (Fast Fourier Transform) > * commons-numbers-fct (Fast Cosine Transform) > * ... > ? > > Gilles As long as it does not mean, we have individual release cycles for these modules... Cheers, Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [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: >> * commons-numbers-core (with classes such as "Precision"). >> * commons-numbers-complex >> * commons-numbers-quaternion >> * commons-numbers-fraction >> * commons-numbers-continued-fraction >> * commons-numbers-fft (Fast Fourier Transform) >> * commons-numbers-fct (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 sub-par (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, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
In reply to this post by Brent Worden-2
+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 > commons-numbers? > > 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 number-theoretic 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: > >>>>> * commons-numbers-core (with classes such as "Precision"). > >>>>> * commons-numbers-complex > >>>>> * commons-numbers-quaternion > >>>>> * commons-numbers-fraction > >>>>> * commons-numbers-continued-fraction > >>>>> * commons-numbers-fft (Fast Fourier Transform) > >>>>> * commons-numbers-fct (Fast Cosine Transform) > >>>>> * ... > >>>>> ? > >>>>> > >>>>> Gilles > >>>>> > >>>>> > >>>>> > >>> > >>> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [hidden email] > > For additional commands, e-mail: [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 >> commons-numbers? >> >> 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 number-theoretic 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: >>>>>>> * commons-numbers-core (with classes such as "Precision"). >>>>>>> * commons-numbers-complex >>>>>>> * commons-numbers-quaternion >>>>>>> * commons-numbers-fraction >>>>>>> * commons-numbers-continued-fraction >>>>>>> * commons-numbers-fft (Fast Fourier Transform) >>>>>>> * commons-numbers-fct (Fast Cosine Transform) >>>>>>> * ... >>>>>>> ? >>>>>>> >>>>>>> Gilles >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>> >>> --------------------------------------------------------------------- >>> 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] |
In reply to this post by Gilles Sadowski
+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, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
In reply to this post by Gilles Sadowski
+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, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] > --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [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, e-mail: [hidden email] >> For additional commands, e-mail: [hidden email] >> > > > --------------------------------------------------------------------- > 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] |
In reply to this post by Gilles Sadowski
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 number-theoretic 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: >>>>> * commons-numbers-core (with classes such as "Precision"). >>>>> * commons-numbers-complex >>>>> * commons-numbers-quaternion >>>>> * commons-numbers-fraction >>>>> * commons-numbers-continued-fraction >>>>> * commons-numbers-fft (Fast Fourier Transform) >>>>> * commons-numbers-fct (Fast Cosine Transform) >>>>> * ... >>>>> ? >>>>> >>>>> Gilles >>>>> >>>>> >>> --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [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 number-theoretic 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: >>>>>> * commons-numbers-core (with classes such as "Precision"). >>>>>> * commons-numbers-complex >>>>>> * commons-numbers-quaternion >>>>>> * commons-numbers-fraction >>>>>> * commons-numbers-continued-fraction >>>>>> * commons-numbers-fft (Fast Fourier Transform) >>>>>> * commons-numbers-fct (Fast Cosine Transform) >>>>>> * ... >>>>>> ? >>>>>> >>>>>> Gilles >>>>>> >>>>>> >>>>>> >>>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [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, e-mail: [hidden email] For additional commands, e-mail: [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, e-mail: [hidden email] For additional commands, e-mail: [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, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] > > |
Free forum by Nabble | Edit this page |