11:07 a.m.
Folks,
I just realised that two functions that we added in February 2022
(namely bin2dec and dec2bin) were never documented, although they'd been
available since 2022b.
I wrote some documentation (comments are welcome). My question is: these
functions are nowhere mentioned in the Changelog. Should ve add them to
the 2022b entry, or to the entry for the current git version?
-------------------------------------------------------
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
-------------------------------------------------------
12:02 p.m.
On Wed, Sep 13, 2023 at 7:07 AM Riccardo (Jack) Lucchetti
<p002264(a)staff.univpm.it> wrote:
Folks,
I just realised that two functions that we added in February 2022
(namely bin2dec and dec2bin) were never documented, although they'd been
available since 2022b.
I wrote some documentation (comments are welcome). My question is: these
functions are nowhere mentioned in the Changelog. Should ve add them to
the 2022b entry, or to the entry for the current git version?
Good point. The way I recall this is that we never got collectively
clear on whether those functions were actually wanted. If so, then
certainly they should be documented (and what you've written looks
clear to me), and added to the Changelog.
Allin
12:11 p.m.
On 13/09/2023 14:02, Cottrell, Allin wrote:
On Wed, Sep 13, 2023 at 7:07 AM Riccardo (Jack) Lucchetti
<p002264(a)staff.univpm.it> wrote:
>
> Folks,
>
> I just realised that two functions that we added in February 2022
> (namely bin2dec and dec2bin) were never documented, although they'd been
> available since 2022b.
>
> I wrote some documentation (comments are welcome). My question is: these
> functions are nowhere mentioned in the Changelog. Should ve add them to
> the 2022b entry, or to the entry for the current git version?
Good point. The way I recall this is that we never got collectively
clear on whether those functions were actually wanted. If so, then
certainly they should be documented (and what you've written looks
clear to me), and added to the Changelog.
Well, Luca and I were thinking of using them in the upcoming new version
of the ParMA package, and I believe Marcin was in favour too.
-------------------------------------------------------
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:31 p.m.
New subject: [EXTERNAL] Re: doc for bin2dec and dec2bin
Well, Luca and I were thinking of using them in the upcoming new
version of the ParMA package, and I believe Marcin was in favour too.
FWIW, I've used Matlab's dec2bin for running Markov-switching models, so I like
this new functionality too.
PS
-----Original Message-----
From: Riccardo (Jack) Lucchetti <p002264(a)staff.univpm.it>
Sent: Wednesday, September 13, 2023 8:11 AM
To: Gretl development <gretl-devel(a)gretlml.univpm.it>
Subject: [EXTERNAL] [Gretl-devel] Re: doc for bin2dec and dec2bin
***This email is from an external source. Only open links and attachments from a Trusted
Sender.***
On 13/09/2023 14:02, Cottrell, Allin wrote:
On Wed, Sep 13, 2023 at 7:07 AM Riccardo (Jack) Lucchetti
<p002264(a)staff.univpm.it> wrote:
>
> Folks,
>
> I just realised that two functions that we added in February 2022
> (namely bin2dec and dec2bin) were never documented, although they'd
> been available since 2022b.
>
> I wrote some documentation (comments are welcome). My question is:
> these functions are nowhere mentioned in the Changelog. Should ve add
> them to the 2022b entry, or to the entry for the current git version?
Good point. The way I recall this is that we never got collectively
clear on whether those functions were actually wanted. If so, then
certainly they should be documented (and what you've written looks
clear to me), and added to the Changelog.
Well, Luca and I were thinking of using them in the upcoming new version of the ParMA
package, and I believe Marcin was in favour too.
-------------------------------------------------------
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/
12:16 p.m.
On Wed, Sep 13, 2023 at 8:11 AM Riccardo (Jack) Lucchetti
<p002264(a)staff.univpm.it> wrote:
On 13/09/2023 14:02, Cottrell, Allin wrote:
> On Wed, Sep 13, 2023 at 7:07 AM Riccardo (Jack) Lucchetti
> <p002264(a)staff.univpm.it> wrote:
>>
>> I just realised that two functions that we added in February 2022
>> (namely bin2dec and dec2bin) were never documented, although they'd been
>> available since 2022b.
>>
>> I wrote some documentation (comments are welcome). My question is: these
>> functions are nowhere mentioned in the Changelog. Should ve add them to
>> the 2022b entry, or to the entry for the current git version?
>
> Good point. The way I recall this is that we never got collectively
> clear on whether those functions were actually wanted. If so, then
> certainly they should be documented (and what you've written looks
> clear to me), and added to the Changelog.
Well, Luca and I were thinking of using them in the upcoming new version
of the ParMA package, and I believe Marcin was in favour too.
And Peter Summers added, "FWIW, I've used Matlab's dec2bin for running
Markov-switching models, so I like this new functionality too."
I notice that Matlab's dec2bin employs a string composed of '0's and
'1's to represent a binary number. Maybe we want to do that too? In
its native form an unsigned integer occupies 4 bytes = 32 bits. If
converted a la Matlab that goes up to 33 bytes = 264 bits (allowing
for the terminating NUL byte). As currently documented in git, our
representation occupies 32 * 8 = 256 bytes or 2048 bits, since a
double is used to represent each bit of the integer. This seems kinda
profligate in terms of the storage used.
Allin
2:09 p.m.
On 14/09/2023 14:16, Cottrell, Allin wrote:
On Wed, Sep 13, 2023 at 8:11 AM Riccardo (Jack) Lucchetti
<p002264(a)staff.univpm.it> wrote:
> Well, Luca and I were thinking of using them in the upcoming new version
> of the ParMA package, and I believe Marcin was in favour too.
And Peter Summers added, "FWIW, I've used Matlab's dec2bin for running
Markov-switching models, so I like this new functionality too."
I notice that Matlab's dec2bin employs a string composed of '0's and
'1's to represent a binary number. Maybe we want to do that too? In
its native form an unsigned integer occupies 4 bytes = 32 bits. If
converted a la Matlab that goes up to 33 bytes = 264 bits (allowing
for the terminating NUL byte). As currently documented in git, our
representation occupies 32 * 8 = 256 bytes or 2048 bits, since a
double is used to represent each bit of the integer. This seems kinda
profligate in terms of the storage used.
I agree. However, our current implementation makes it possible to
convert several items at once, as in, for example "dec2bin(seq(1,6)')"
or "bin2dec(I(4))".
A less contrived example could be given by considering a non-recursive
algorithm for computing all possible binary vectors of size n that sum
to k (useful, for example in conditional or fixed-effects logit models):
<hansl>
n = 5
k = 3
tmp = dec2bin(seq(2^k-1, 2^n-1)')[,1:n]
eval selifr(tmp, sumr(tmp) .= k)
</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
-------------------------------------------------------
6:31 p.m.
On Thu, Sep 14, 2023 at 10:10 AM Riccardo (Jack) Lucchetti
<p002264(a)staff.univpm.it> wrote:
On 14/09/2023 14:16, Cottrell, Allin wrote:
[...]
> I notice that Matlab's dec2bin employs a string composed of
'0's and
> '1's to represent a binary number. Maybe we want to do that too? In
> its native form an unsigned integer occupies 4 bytes = 32 bits. If
> converted a la Matlab that goes up to 33 bytes = 264 bits (allowing
> for the terminating NUL byte). As currently documented in git, our
> representation occupies 32 * 8 = 256 bytes or 2048 bits, since a
> double is used to represent each bit of the integer. This seems kinda
> profligate in terms of the storage used.
I agree. However, our current implementation makes it possible to
convert several items at once, as in, for example "dec2bin(seq(1,6)')"
or "bin2dec(I(4))".
Granted, but a string-oriented variant could return an array of
strings to allow this sort of thing.
A less contrived example could be given by considering a
non-recursive
algorithm for computing all possible binary vectors of size n that sum
to k (useful, for example in conditional or fixed-effects logit models):
<hansl>
n = 5
k = 3
tmp = dec2bin(seq(2^k-1, 2^n-1)')[,1:n]
eval selifr(tmp, sumr(tmp) .= k)
</hansl>
That would surely require more work if using strings, but I think it
would be fairly straightforward to write an efficient routine to
return the number of 1s in the binary expansion of an integer (and a
vectorized variant of same).
Allin
474
days inactive
475
days old
6 comments
3 participants
participants (3)
-
Cottrell, Allin -
Riccardo (Jack) Lucchetti -
Summers, Peter