Re: 5x6-bit values into/out of a 32-bit word

[Thelonius]

in reply to 5x6-bit values into/out of a 32-bit word

How about these:

#!perl -w
use strict;
my $fmt = "0b" . ("%06b" x 5);

sub b5ToInt { oct sprintf "0b%06b%06b%06b%06b%06b", @_ }

sub intToB5 {
 map { oct "0b$_" } unpack "(a6)5", sprintf "%030b", $_[0]
}

my $word = b5ToInt(1,2,3,4,5);
printf "word = %d = 0x%08x = 0b%030b\n", $word, $word, $word;

my @out = intToB5($word);
print "out = ", join(", ", @out), "\n";

Output:

word = 17314053 = 0x01083105 = 0b000001000010000011000100000101
out = 1, 2, 3, 4, 5

[Thelonius]

Okay, the C programmer in me rebelled against the inefficiency of my earlier reply. How about:

sub b5ToInt {
  use integer;
  return     ($_[4]||0)
          + (($_[3]||0)<<6)
          + (($_[2]||0)<<12)
          + (($_[1]||0)<<18)
          + (($_[0]||0)<<24);
}
sub intToB5 {
  use integer;
  my $in = int(shift);
  return map { $_ & 0b111111 } 
   (($in >> 24),
    ($in >> 18),
    ($in >> 12),
    ($in >>  6),
    $in);
}

[grinder]

The C programmer in you may rail against the inefficiency of your first solution, but this solution has you doing a pile of work that would be more efficiently handled by the computer. Get it to calculate those multiples of 6, it's better at that than you are. Factor that out, and your code will shrink.

And should the requirements ever change, you'll have much less code of your own to change. That's a much better form of effciency worth seeking.

[BrowserUk]

Get [the computer] to calculate those multiples of 6, it's better at that than you are.

What utter rubbish! If you cannot recite the first five terms of the 6 times table from memory, and more quickly than you can power up your computer...

[Thelonius]

This is a very interesting point, one very much worth considering. In Perl, of course, the difference would not be worth mentioning, but in C, my unrolled-loop version is much faster than a version with a loop. I was guessing that it would be twice as fast, but when I actually measured it, it was actually five times as fast.

Now, of course, it was microseconds v. microseconds, but why are we packing 5 numbers into one 32-bit word? Presumably we care about the space usage, which would only matter if we are using a lot of them, probably millions, so all those microseconds can add up.

The maintenance concerns are, in this specific case, probably not valid. You can't pack 6x6-bit values in a 32-bit word, nor 5x7-bit values. We would have to change the algorithm if anything changed. And, if you actually write out the loop version, you've probably only saved one line of code.

I'm not disagreeing with your principles, but I think that in this case I would probably go with my version.

There's a very good essay, The Fallacy of Premature Optimization. One snippet:

Note, however, that Hoare did not say, "Forget about small efficiencies all of the time." Instead, he said "about 97% of the time." This means that about 3% of the time we really should worry about small efficiencies. That may not sound like much, but consider that this is 1 line of source code out of every 33. How many programmers worry about the small efficiencies even this often? Premature optimization is always bad, but the truth is that some concern about small efficiencies during program development is not premature.