Hex dumps and baby weights

The successive weights of my littlest are, in ounces, `7_{16}12, 7_{16}8, 8_{16}0, 8_{16}8.`  These have been written in the wiggle version of base `16`, so that they can be read easily as pounds and ounces.

Computer hardware uses lots of binary---but binary is written out with long strings of ones and zeroes, and that can be a little painful to read.

 In a previous post, we saw that taking two decimal digits at a time gives us base `100`, and taking three at a time is base 1000.  Taking two binary digits (bits) at a time is base `4`, or quaternary.  It is hardly used. Taking three bits at a time is base `8`, or octal.  Octal used to be common enough, but is now only occasionally seen: the only current example I can think of is how file permissions are handled in Linux.

Taking four bits at a time is base `16`, called hexadecimal, or hex to its friends.
 
Those (relatively few) programmers who work "close to the metal" sometimes have cause to examine binary data.  They almost never look at actual binary, however.  What they read is the binary converted to hexadecimal.  Such a listing is called a hex dump.

The usual notation for base `n` arithmetic differs is two ways from the wiggle notation we have been using.

First, there is only a common base, and it is written just once at the end of the string of digits.  In the usual notation, bases are always written in decimal.  (In wiggle, interbases and superdigits are always written in decimal.)  So the usual way to write the bit sequence, or bitstring `10101001010`, explicitly indicating that it is in base 2, is `10101001010_{2}`.  If the base is obvious in context, we don't always bother with the subscript.  In wiggle, this would be the much longer

`\qquad\qquad\qquad 1_{2}0_{2}1_{2}0_{2}1_{2}0_{2}0_{2}1_{2}0_{2}1_{2}0.`

To convert binary to octal, one groups the binary digits three at a time from the right,

`\qquad\qquad\qquad 10,101,001,010,`

and then converts each three bit binary group to a corresponding octal digit,

`\qquad\qquad\qquad 2512_{8}.`

Second, since the usual notation puts digits next to each other, it has to employ a single character per digit.  The usual digits work for bases up to ten.  After that, once must have new symbols.  Consider, now the hexadecimal number `7_{16}12`, as written in wiggle.  We cannot simply write this as `712_{16}`, because we cannot tell whether that means `7_{16}12` or `7_{16}1_{16}2`.  Instead, the usual thing to do is to let A mean 10, B mean 11, C mean 12, and so forth, up to one less than the base. 

So, instead of `7_{16}12`, one writes `7"C"_{16}`.

To convert binary to hexadecimal, one groups the binary digits four at a time, from the right,

`\qquad\qquad\qquad 101,0100,1010,`

and then converts each four bit binary group into a hexadecimal digit,

`\qquad\qquad\qquad 54"C"_{16}.`

In hexadecimal, my littlest's birthweight was `7"C"` ounces, or, moving the unit point one place, `7."C"` pounds.

At one week

Littlest weighed in at 8 lb., 8 oz., during the midwife's followup visit yesterday evening---another weight that is a whole number of quarter pounds.  So that makes two weighings by the midwife, and two at the doctor's office---probably with different shifts of nurses each time---and every one of those weights is a multiple of four ounces.  (Again, I'm not faking these weights.  If I were inventing, I would make them look less suspicious.)

In ounces, the weighings go `7_{16}12, 7_{16}8, 8_{16}0, 8_{16}8,` or `124, 120, 128, 136`.

agraph
width=300; height=200;
xmin=(-0.05); xmax=3.05;
ymin=(-2); ymax=150; yscl=16;
axes();
marker = "none";
//plot(118 + 2*x + 6*abs(x-1));
marker = "dot";
stroke = "green";
markerfill = "green";
a=[];
a[0]=[0,124];
a[1]=[1,120];
a[2]=[2,128];
a[3]=[3,136];
path(a);
endagraph

The preceding graph is a bit shonky, though, because the horizontal coordinate indicates which weighing, rather than time---and the times of the weighings are not so evenly spread---Thurs, Friday, Tuesday, Thursday.  So let's revise it, to reflect the days of the respective weighings.  The result is still imperfect, because birth early Thursday, the first doctor's office visit was late Friday afternoon, the second doctor's office visit was Tuesday morning, and the Thursday midwife's visit was in the evening.  I've also dropped the pretty connecting lines, because they don't correspond to anything measured.  Nonetheless, we get an improved sense of what has been measured and what we might reasonably guess from it :

agraph
width=300; height=200;
xmin=(-0.1); xmax=7.1;
ymin=(71); ymax=150; yscl=16;
axes();
marker = "none";
//plot(118 + 2*x + 6*abs(x-1));
marker = "dot";
stroke = "none";
a=[];
a[0]=[0,124];
a[1]=[1,120];
a[2]=[5,128];
a[3]=[7,136];
path(a);
endagraph