8:57 a.m.
Folks,
while revising some old code I stumbled into a function that I'd written a
while back, and I realised this could go into the extra package. Note:
for large input vectors (n > 5) the recursion approach really is much
slower than direct calculation, so there is quite a lot of room for
optimisation.
Opinions?
<hansl>
function matrix choose(const matrix from, scalar h)
# If "from" is a vector with n elements, this function
# returns a matrix whose rows are all the possible subsets
# with h elements; a recursive algorithm is used.
#
# For example: choose({1,2,3}, 2) returns
#
# 1 2
# 1 3
# 2 3
#
# warning: the returned matrix will have n! / (h! * (n-h)!),
# rows, so handle with care.
if (rows(from) > 1 && cols(from) > 1)
s = argname(from)
printf "%s is not a vector\n", strlen(s) ? s : "argument 1"
return {NA}
endif
if h <= 0
ret = {}
elif h == 1
matrix ret = vec(from)
else
ret = {}
n = nelem(from)
loop i = 1 .. (n - h + 1) --quiet
x = from[i]
matrix c = from[i+1: ]
if rows(c) > 0
matrix ret |= x ~ choose(c, h-1)
endif
endloop
endif
return ret
end function
</hansl>
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
3:26 p.m.
Am 10.06.2021 um 10:57 schrieb Riccardo (Jack) Lucchetti:
Folks,
while revising some old code I stumbled into a function that I'd
written a while back, and I realised this could go into the extra
package. Note: for large input vectors (n > 5) the recursion approach
really is much slower than direct calculation, so there is quite a lot
of room for optimisation.
Opinions?
OK, so what's the use case?
thanks
sven
3:55 p.m.
On Thu, 10 Jun 2021, Sven Schreiber wrote:
Am 10.06.2021 um 10:57 schrieb Riccardo (Jack) Lucchetti:
> Folks,
>
> while revising some old code I stumbled into a function that I'd
> written a while back, and I realised this could go into the extra
> package. Note: for large input vectors (n > 5) the recursion approach
> really is much slower than direct calculation, so there is quite a lot
> of room for optimisation.
>
> Opinions?
OK, so what's the use case?
I had written this in the context of a loop where I was comparing models
of size k chosen from a set of n regressors. But of course this is more
general than this. By the way, Octave has a similar function (nchoosek,
IIRC).
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
4:33 p.m.
Am 10.06.2021 um 17:55 schrieb Riccardo (Jack) Lucchetti:
On Thu, 10 Jun 2021, Sven Schreiber wrote:
> Am 10.06.2021 um 10:57 schrieb Riccardo (Jack) Lucchetti:
>> package. Note: for large input vectors (n > 5) the recursion approach
>> really is much slower than direct calculation, so there is quite a lot
>> of room for optimisation.
>>
>> Opinions?
>
> OK, so what's the use case?
I had written this in the context of a loop where I was comparing
models of size k chosen from a set of n regressors. But of course this
is more general than this. By the way, Octave has a similar function
(nchoosek, IIRC).
Right, a couple of remarks:
- https://de.mathworks.com/help/matlab/ref/nchoosek.html
- in gretl we have the closely related native bincoeff() function
- The bincoeff(n,k) doc says that k>n leads to NA, but actually
bincoeff(2,3) resuls in an invalid argument error, so I guess the doc
must be adjusted. (Same for k<0.) But especially for matrix inputs
(which are treated element-per-element, although this could be made
clearer in the doc, too) this is a bit unfortunate since the whole
operation then fails if just one element is out of bounds.
- So our bincoeff function cannot be overloaded like Matlab's nchoosek
anymore, given that matrix inputs are already allowed, but handled and
interpreted differently.
- In the extra addon we also have the powerset function, but (a) that
operates on strings (arrays), and (b) it does not limit itself to
subsets of k elements only.
FWIW,
sven
12:14 a.m.
On Thu, 10 Jun 2021, Sven Schreiber wrote:
Am 10.06.2021 um 17:55 schrieb Riccardo (Jack) Lucchetti:
> On Thu, 10 Jun 2021, Sven Schreiber wrote:
>> Am 10.06.2021 um 10:57 schrieb Riccardo (Jack) Lucchetti:
>>> package. Note: for large input vectors (n > 5) the recursion approach
>>> really is much slower than direct calculation, so there is quite a lot
>>> of room for optimisation.
>>>
>>> Opinions?
>>
>> OK, so what's the use case?
> I had written this in the context of a loop where I was comparing
> models of size k chosen from a set of n regressors. But of course this
> is more general than this. By the way, Octave has a similar function
> (nchoosek, IIRC).
Right, a couple of remarks:
- https://de.mathworks.com/help/matlab/ref/nchoosek.html
- in gretl we have the closely related native bincoeff() function
- The bincoeff(n,k) doc says that k>n leads to NA, but actually
bincoeff(2,3) resuls in an invalid argument error, so I guess the doc
must be adjusted. (Same for k<0.)
I'd say so too: the doc, and not the behavior, should be adjusted.
You simply can't select n+1 or more, or a negative number, of
objects from an array of n objects so I think an error is called
for.
Am I missing some reason to the contrary?
Allin
10:48 a.m.
On Sat, 12 Jun 2021, Allin Cottrell wrote:
> - The bincoeff(n,k) doc says that k>n leads to NA, but
actually
> bincoeff(2,3) resuls in an invalid argument error, so I guess the doc
> must be adjusted. (Same for k<0.)
I'd say so too: the doc, and not the behavior, should be adjusted. You simply
can't select n+1 or more, or a negative number, of objects from an array of n
objects so I think an error is called for.
I agree. Fixed in git.
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
7:54 a.m.
Am 10.06.21 um 10:57 schrieb Riccardo (Jack) Lucchetti:
Folks,
while revising some old code I stumbled into a function that I'd written
a while back, and I realised this could go into the extra package. Note:
for large input vectors (n > 5) the recursion approach really is much
slower than direct calculation, so there is quite a lot of room for
optimisation.
Opinions?
Hi guys,
I did not really get the conclusion of this discussion: Do all agree
that your choose() function is supposed to become part of the extra package?
If so, I have the following comments on it:
1) Nice function. Actually, I just need this for another package I am
working on ;-)
2) The name: Why not call it nchoosek() or combinations()? The first
suggestion is familiar for people coming from Matlab -- which are not
too few. Simply "choose" sounds _too_ general I would say (choose what
from which source?).
3) I suggest to change the signature to
function matrix choose (matrix from "Set of all choices",
int h[1::] "Number of selected choices")
First, h must be an integer, right? Second, we have another check that
only positive integers are passed.
Here is a slightly modified version.
<>
function matrix choose (matrix from "Set of all choices",
int h[1::] "Number of selected choices")
/* If "from" is a vector with n elements, this function
returns a matrix whose rows are all the possible subsets
with h elements; a recursive algorithm is used.
# For example: choose({1,2,3}, 2) returns
#
# 1 2
# 1 3
# 2 3
return: matrix with n! / (h! * (n-h)!) rows if succesful,
otherwise 1x1 matrix with an NA value. */
if rows(from) > 1 && cols(from) > 1
s = argname(from)
printf "\nError: %s is not a vector\n", strlen(s) ? s :
"argument 1"
return {NA}
endif
if h == 1
matrix ret = vec(from)
else
matrix ret = {}
n = nelem(from)
loop i=1..(n-h+1)
x = from[i]
matrix c = from[i+1:]
if rows(c) > 0
matrix ret |= x ~ choose(c, h-1)
endif
endloop
endif
return ret
end function
eval choose({1,2,3}, 2)
matrix v = seq(1, 10)
matrix r = choose(v, 5)
eval rows(r)
</>
If we agree that this shall become part of the extra package, I add 2-3
tests to our test suit for extra.
Artur
10:45 a.m.
On Sun, 13 Jun 2021, Artur T. wrote:
If we agree that this shall become part of the extra package, I add
2-3 tests
to our test suit for extra.
Nice work, Artur. I vote for "combinations()". Anyway, let's not forget to
add in the documentation that the recursive algorithm I used is not the
fastest when arguments are large.
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
10:52 a.m.
Am 13.06.2021 um 12:45 schrieb Riccardo (Jack) Lucchetti:
On Sun, 13 Jun 2021, Artur T. wrote:
> If we agree that this shall become part of the extra package, I add
> 2-3 tests to our test suit for extra.
Nice work, Artur. I vote for "combinations()".
Glad it's not going to be "choose"...
to add in the documentation that the recursive algorithm I used is
not
the fastest when arguments are large.
Would it be very difficult to add the faster algorithm?
About the Matlab name nchoosek: Not sure whether Peter Summers is still
around, but perhaps a nchoosek function could be added to his
matlab_utilities package which would be a thin wrapper around the native
bincoeff and the new combinations (or whatever name) functions.
cheers
sven
11:43 a.m.
On Sun, 13 Jun 2021, Sven Schreiber wrote:
Am 13.06.2021 um 12:45 schrieb Riccardo (Jack) Lucchetti:
> On Sun, 13 Jun 2021, Artur T. wrote:
>
> to add in the documentation that the recursive algorithm I used is not
> the fastest when arguments are large.
Would it be very difficult to add the faster algorithm?
I suspect it would be. I see that the doc for matlab's nchoosek
says, "C = nchoosek(v,k) is only practical for situations where
length(v) is less than about 15." That suggests that they're using
recursion, in which case I guess the practical limitation may be
exhaustion of stack space.
Allin
4:45 p.m.
New subject: [EXTERNAL] Re: the choose() function
Hi Sven et al,
I’m still here, just haven’t been doing much gretl-related stuff lately :-(
Once everything’s finalized I’d be glad to update the matlab_utilities package to include
this functionality (which is very nice, btw).
Cheers,
Peter
Sent from my iPad
On Jun 13, 2021, at 6:52 AM, Sven Schreiber <svetosch(a)gmx.net>
wrote:
***This email is from an external source. Only open links and attachments from a Trusted
Sender.***
> Am 13.06.2021 um 12:45 schrieb Riccardo (Jack) Lucchetti:
>> On Sun, 13 Jun 2021, Artur T. wrote:
>>
>> If we agree that this shall become part of the extra package, I add
>> 2-3 tests to our test suit for extra.
>
> Nice work, Artur. I vote for "combinations()".
Glad it's not going to be "choose"...
> to add in the documentation that the recursive algorithm I used is not
> the fastest when arguments are large.
Would it be very difficult to add the faster algorithm?
About the Matlab name nchoosek: Not sure whether Peter Summers is still
around, but perhaps a nchoosek function could be added to his
matlab_utilities package which would be a thin wrapper around the native
bincoeff and the new combinations (or whatever name) functions.
cheers
sven
_______________________________________________
Gretl-devel mailing list -- gretl-devel(a)gretlml.univpm.it
To unsubscribe send an email to gretl-devel-leave(a)gretlml.univpm.it
Website: https://gretlml.univpm.it/postorius/lists/gretl-devel.gretlml.univpm.it/
4:55 p.m.
New subject: [EXTERNAL] Re: the choose() function
Am 13.06.2021 um 18:45 schrieb Summers, Peter:
Hi Sven et al,
I’m still here, just haven’t been doing much gretl-related stuff lately :-(
Once everything’s finalized I’d be glad to update the matlab_utilities package to include
this functionality (which is very nice, btw).
OK, excellent. We'll be glad to offer assistance if something's not
clear, for example how to add the dependency on the 'extra' addon to
your package, if indeed the new function will live there.
thanks
sven
9:34 p.m.
New subject: [EXTERNAL] Re: the choose() function
On Sun, 13 Jun 2021, Sven Schreiber wrote:
Am 13.06.2021 um 18:45 schrieb Summers, Peter:
> Hi Sven et al,
>
> I’m still here, just haven’t been doing much gretl-related stuff lately :-(
>
> Once everything’s finalized I’d be glad to update the matlab_utilities
> package to include this functionality (which is very nice, btw).
OK, excellent. We'll be glad to offer assistance if something's not
clear, for example how to add the dependency on the 'extra' addon to
your package, if indeed the new function will live there.
If matlab_utilities included a dependency on extra, we could just add
nchoosek() as a wrapper, using the new "numeric" type to tell apart the
cases when to use bincoeff() and the choose() or combinations() function
from extra.
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
10:04 p.m.
New subject: [EXTERNAL] Re: the choose() function
On 13.06.21 23:34, Riccardo (Jack) Lucchetti wrote:
On Sun, 13 Jun 2021, Sven Schreiber wrote:
> Am 13.06.2021 um 18:45 schrieb Summers, Peter:
>> Once everything’s finalized I’d be glad to update the
>> matlab_utilities package to include this functionality (which is
>> very nice, btw).
>
> OK, excellent. We'll be glad to offer assistance if something's not
> clear, for example how to add the dependency on the 'extra' addon to
> your package, if indeed the new function will live there.
If matlab_utilities included a dependency on extra, we could just add
nchoosek() as a wrapper, using the new "numeric" type to tell apart
the cases when to use bincoeff() and the choose() or combinations()
function from extra.
Good idea, although nobody here knows about the generic "numeric" type
yet, I guess. (But it's in the changelog alright) This would require
brand new gretl 2021b, however.
cheers
sven
10:13 p.m.
New subject: [EXTERNAL] Re: the choose() function
On Sun, 13 Jun 2021, Sven Schreiber wrote:
On 13.06.21 23:34, Riccardo (Jack) Lucchetti wrote:
> On Sun, 13 Jun 2021, Sven Schreiber wrote:
>
>> Am 13.06.2021 um 18:45 schrieb Summers, Peter:
>>> Once everything’s finalized I’d be glad to update the
>>> matlab_utilities package to include this functionality (which is
>>> very nice, btw).
>>
>> OK, excellent. We'll be glad to offer assistance if something's not
>> clear, for example how to add the dependency on the 'extra' addon to
>> your package, if indeed the new function will live there.
>
> If matlab_utilities included a dependency on extra, we could just add
> nchoosek() as a wrapper, using the new "numeric" type to tell apart
> the cases when to use bincoeff() and the choose() or combinations()
> function from extra.
>
Good idea, although nobody here knows about the generic "numeric" type
yet, I guess. (But it's in the changelog alright) This would require
brand new gretl 2021b, however.
Hmm, true.
Anyway: in the meantime I pushed to git (in the combinations-to-extra
branch) a slightly modified version which avoids recursion in the h=2 case
and speeds things up a little in simple cases.
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
9:18 p.m.
New subject: [EXTERNAL] Re: the choose() function
On Sun, 13 Jun 2021, Riccardo (Jack) Lucchetti wrote:
Anyway: in the meantime I pushed to git (in the combinations-to-extra
branch)
a slightly modified version which avoids recursion in the h=2 case and speeds
things up a little in simple cases.
OK, the combinations-to-extra branch is IMO ready to be merged with
master. If anyone wants to give it a go before I merge it, I'd appreciate
it!
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
5:02 a.m.
New subject: [EXTERNAL] Re: the choose() function
Hi Jack,
thanks for the uodate. Did you run the test script
https://sourceforge.net/p/gretl/git/ci/combinations-to-extra/tree/addons/...
which calls
https://sourceforge.net/p/gretl/git/ci/combinations-to-extra/tree/addons/...
?
Sorry, I can't do this right now here.
Artur
Am 14.06.2021 23:18 schrieb Riccardo (Jack) Lucchetti:
> On Sun, 13 Jun 2021, Riccardo (Jack) Lucchetti wrote:
>
>> Anyway: in the meantime I pushed to git (in the combinations-to-extra
>> branch) a slightly modified version which avoids recursion in the h=2
>> case and speeds things up a little in simple cases.
>
> OK, the combinations-to-extra branch is IMO ready to be merged with
> master. If anyone wants to give it a go before I merge it, I'd
> appreciate it!
>
> -------------------------------------------------------
> Riccardo (Jack) Lucchetti
> Dipartimento di Scienze Economiche e Sociali (DiSES)
>
> Università Politecnica delle Marche
> (formerly known as Università di Ancona)
>
> r.lucchetti(a)univpm.it
> http://www2.econ.univpm.it/servizi/hpp/lucchetti
> -------------------------------------------------------
> _______________________________________________
> Gretl-devel mailing list -- gretl-devel(a)gretlml.univpm.it
> To unsubscribe send an email to gretl-devel-leave(a)gretlml.univpm.it
> Website:
> https://gretlml.univpm.it/postorius/lists/gretl-devel.gretlml.univpm.it/
6:14 a.m.
New subject: [EXTERNAL] Re: the choose() function
On Tue, 15 Jun 2021, atecon wrote:
Hi Jack,
thanks for the uodate. Did you run the test script
https://sourceforge.net/p/gretl/git/ci/combinations-to-extra/tree/addons/...
which calls
https://sourceforge.net/p/gretl/git/ci/combinations-to-extra/tree/addons/...
?
Sorry, I can't do this right now here.
I hadn't, but I have now (and as a consequence, I fixed the code for a
couple corner cases --- thanks!).
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
6:17 a.m.
New subject: [EXTERNAL] Re: the choose() function
Am 15.06.2021 08:14 schrieb Riccardo (Jack) Lucchetti:
On Tue, 15 Jun 2021, atecon wrote:
> Hi Jack,
>
> thanks for the uodate. Did you run the test script
>
>
https://sourceforge.net/p/gretl/git/ci/combinations-to-extra/tree/addons/...
>
> which calls
>
>
https://sourceforge.net/p/gretl/git/ci/combinations-to-extra/tree/addons/...
>
> ?
>
> Sorry, I can't do this right now here.
I hadn't, but I have now (and as a consequence, I fixed the code for a
couple corner cases --- thanks!).
Cool, glad that the test has helped to identify some remaining issue.
Best,
Artur
8:36 a.m.
New subject: [EXTERNAL] Re: the choose() function
Am 15.06.2021 um 08:14 schrieb Riccardo (Jack) Lucchetti:
On Tue, 15 Jun 2021, atecon wrote:
> Hi Jack,
>
> thanks for the uodate. Did you run the test script
>
>
https://sourceforge.net/p/gretl/git/ci/combinations-to-extra/tree/addons/...
>
>
> which calls
>
>
https://sourceforge.net/p/gretl/git/ci/combinations-to-extra/tree/addons/...
>
>
> ?
>
> Sorry, I can't do this right now here.
I hadn't, but I have now (and as a consequence, I fixed the code for a
couple corner cases --- thanks!).
Jack, the --quiet option for loops can only be omitted for recent gretl
versions (>=2020c). 'extra' currently supports versions from 2016a.
We could consider increasing the requirement I guess.
Apart from that I'd suggest to delete "(in progress)" from the changelog.
thanks
sven
4:11 p.m.
New subject: [EXTERNAL] Re: the choose() function
On Tue, 15 Jun 2021, Sven Schreiber wrote:
Jack, the --quiet option for loops can only be omitted for recent
gretl
versions (>=2020c). 'extra' currently supports versions from 2016a.
We could consider increasing the requirement I guess.
Apart from that I'd suggest to delete "(in progress)" from the changelog.
Thanks, Sven, done.
Apaprt from that, I made a few touches to the code to make it marginally
more efficient and pushed nthe new version to git.
If you like it, feel free to merge back into master.
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
4:19 p.m.
New subject: [EXTERNAL] Re: the choose() function
Am 15.06.2021 um 18:11 schrieb Riccardo (Jack) Lucchetti:
On Tue, 15 Jun 2021, Sven Schreiber wrote:
> Jack, the --quiet option for loops can only be omitted for recent gretl
> versions (>=2020c). 'extra' currently supports versions from 2016a.
>
> We could consider increasing the requirement I guess.
>
> Apart from that I'd suggest to delete "(in progress)" from the
> changelog.
Thanks, Sven, done.
Apaprt from that, I made a few touches to the code to make it
marginally more efficient and pushed nthe new version to git.
If you like it, feel free to merge back into master.
I'd rather leave that to those who know how to run the relevant test
script for this case, and so forth.
thanks
sven
4:24 p.m.
New subject: [EXTERNAL] Re: the choose() function
On Tue, 15 Jun 2021, Sven Schreiber wrote:
> If you like it, feel free to merge back into master.
I'd rather leave that to those who know how to run the relevant test
script for this case, and so forth.
In short, Artur ;)
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
4:29 p.m.
New subject: [EXTERNAL] Re: the choose() function
Am 15.06.2021 um 18:24 schrieb Riccardo (Jack) Lucchetti:
On Tue, 15 Jun 2021, Sven Schreiber wrote:
>> If you like it, feel free to merge back into master.
>
> I'd rather leave that to those who know how to run the relevant test
> script for this case, and so forth.
In short, Artur ;)
Well, of course you could merge it yourself as well. I just meant that
I'm neither the code author nor am I in the position to test the code
after your changes. So I shouldn't decide on the merge, I think.
-s
4:30 p.m.
New subject: [EXTERNAL] Re: the choose() function
Am 15.06.21 um 18:29 schrieb Sven Schreiber:
Am 15.06.2021 um 18:24 schrieb Riccardo (Jack) Lucchetti:
> On Tue, 15 Jun 2021, Sven Schreiber wrote:
>
>>> If you like it, feel free to merge back into master.
>>
>> I'd rather leave that to those who know how to run the relevant test
>> script for this case, and so forth.
>
> In short, Artur ;)
Well, of course you could merge it yourself as well. I just meant that
I'm neither the code author nor am I in the position to test the code
after your changes. So I shouldn't decide on the merge, I think.
Hi,
Let me have a quick look on the latest state. I'll come back in a few
minutes.
Artur
4:37 p.m.
New subject: [EXTERNAL] Re: the choose() function
Am 15.06.21 um 18:30 schrieb Artur T.:
Am 15.06.21 um 18:29 schrieb Sven Schreiber:
> Am 15.06.2021 um 18:24 schrieb Riccardo (Jack) Lucchetti:
>> On Tue, 15 Jun 2021, Sven Schreiber wrote:
>>
>>>> If you like it, feel free to merge back into master.
>>>
>>> I'd rather leave that to those who know how to run the relevant test
>>> script for this case, and so forth.
>>
>> In short, Artur ;)
>
> Well, of course you could merge it yourself as well. I just meant that
> I'm neither the code author nor am I in the position to test the code
> after your changes. So I shouldn't decide on the merge, I think.
Looks good to me, and the test runs fine. Shall I merge to master?
Best,
Artur
4:46 p.m.
New subject: [EXTERNAL] Re: the choose() function
On Tue, 15 Jun 2021, Artur T. wrote:
Looks good to me, and the test runs fine. Shall I merge to master?
please do!
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
10:55 a.m.
Am 13.06.21 um 12:45 schrieb Riccardo (Jack) Lucchetti:
On Sun, 13 Jun 2021, Artur T. wrote:
> If we agree that this shall become part of the extra package, I add
> 2-3 tests to our test suit for extra.
Nice work, Artur. I vote for "combinations()". Anyway, let's not forget
to add in the documentation that the recursive algorithm I used is not
the fastest when arguments are large.
Glad you like it, Jack.
Let me open a new branch and add things to the extra package first. I
still have some questions on some corner cases which should be discussed
I think. I'll come back on this in a few minutes.
Artur
11:20 a.m.
Am 13.06.21 um 12:55 schrieb Artur T.:
Am 13.06.21 um 12:45 schrieb Riccardo (Jack) Lucchetti:
> On Sun, 13 Jun 2021, Artur T. wrote:
>
>> If we agree that this shall become part of the extra package, I add
>> 2-3 tests to our test suit for extra.
>
> Nice work, Artur. I vote for "combinations()". Anyway, let's not
> forget to add in the documentation that the recursive algorithm I used
> is not the fastest when arguments are large.
Glad you like it, Jack.
Let me open a new branch and add things to the extra package first. I
still have some questions on some corner cases which should be discussed
I think. I'll come back on this in a few minutes.
Artur
Ok, here is the initial implementation plus tests:
https://sourceforge.net/p/gretl/git/ci/b543dfe6e1cb9493fa22a8c5403decbea0...
Initially, I thought there is some corner case which need to be
discussed but I think I've covered all relevant cases in the test script:
https://sourceforge.net/p/gretl/git/ci/combinations-to-extra/tree/addons/...
Of course, this functions still needs to be documented.
Artur
11:27 a.m.
On Sun, 13 Jun 2021, Riccardo (Jack) Lucchetti wrote:
On Sun, 13 Jun 2021, Artur T. wrote:
> If we agree that this shall become part of the extra package, I add 2-3
> tests to our test suit for extra.
Nice work, Artur. I vote for "combinations()". Anyway, let's not forget to
add in the documentation that the recursive algorithm I used is not the
fastest when arguments are large.
At present the longest built-in function names are 10 characters and
I'd kind of prefer to keep it that way -- any chance of an
abbreviation?
Allin
12:15 p.m.
Am 13.06.21 um 13:27 schrieb Allin Cottrell:
On Sun, 13 Jun 2021, Riccardo (Jack) Lucchetti wrote:
> On Sun, 13 Jun 2021, Artur T. wrote:
>
>> If we agree that this shall become part of the extra package, I add
>> 2-3 tests to our test suit for extra.
>
> Nice work, Artur. I vote for "combinations()". Anyway, let's not
> forget to add in the documentation that the recursive algorithm I used
> is not the fastest when arguments are large.
At present the longest built-in function names are 10 characters and I'd
kind of prefer to keep it that way -- any chance of an abbreviation?
But this is not a built-in function but is supposed to become part of
the extra package for which a couple of function names already exceed 10
characters. Or do you plan to write a built-in equivalent?
Artur
12:45 p.m.
On Sun, 13 Jun 2021, Artur T. wrote:
Am 13.06.21 um 13:27 schrieb Allin Cottrell:
> On Sun, 13 Jun 2021, Riccardo (Jack) Lucchetti wrote:
>
>> On Sun, 13 Jun 2021, Artur T. wrote:
>>
>>> If we agree that this shall become part of the extra package, I add 2-3
>>> tests to our test suit for extra.
>>
>> Nice work, Artur. I vote for "combinations()". Anyway, let's not
forget to
>> add in the documentation that the recursive algorithm I used is not the
>> fastest when arguments are large.
>
> At present the longest built-in function names are 10 characters and I'd
> kind of prefer to keep it that way -- any chance of an abbreviation?
But this is not a built-in function but is supposed to become part of the
extra package for which a couple of function names already exceed 10
characters. Or do you plan to write a built-in equivalent?
Sorry, I lost track of where this function was going.
However, if efficiency is an issue, should it perhaps be a built-in
after all? Just wondering.
Allin
1039
days inactive
1044
days old
31 comments
6 participants
participants (6)
-
Allin Cottrell -
Artur T. -
atecon
-
Riccardo (Jack) Lucchetti -
Summers, Peter -
Sven Schreiber