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