BCD List to HEX List

[John Machin]

bryanjugglercryptographer at yahoo.com wrote:
> John Machin wrote:
> > bryanjugglercryptographer at yahoo.com wrote:
> >
> > >My version assumes three subroutines: extracting
> > > nibbles, shifting, and adding, Those are pretty simple, so I asked
> > > if he needed them rather than presenting them.
> > > Assuming we have
> > > them, the algorithm is three lines long.
> >
> > Perhaps you could enlighten us by publishing (a) the spec for each of
> > the get_nibble(s), shift, and add subroutines (b) the three-line
> > algorithm (c) what the algorithm is intended to achieve ...
>
> "For each nibble n of x" means to take each 4 bit piece of the BCD
> integer as a value from zero to sixteen (though only 0 through 9
> will appear), from most significant to least significant.

The OP's input, unvaryingly through the whole thread, even surviving to
his Javacard implementation of add() etc, is a list/array of decimal
digits (0 <= value <= 9). Extracting a nibble is so simple that
mentioning a "subroutine" might make the gentle reader wonder whether
there was something deeper that they had missed.

> "Adding"
> integers and "shifting" binary integers is well-defined
> terminology.

Yes, but it's the *representation* of those integers that's been the
problem throughout.

> I already posted the three-line algorithm. It
> appeared immediately under the phrase "To turn BCD x to binary
> integer y," and that is what it is intended to achieve.

Oh, that "algorithm". The good ol' num = num * base + digit is an
"algorithm"???

The problem with that is that the OP has always maintained that he has
no facility for handling a binary integer ("num") longer than 16 bits
-- no 32-bit long, no bignum package that didn't need "long", ...

>
> > > He took a while to state the problem, but was clear from the start
> > > that he had lists of digits rather than an integer datatype.
> >
> > Yes, input was a list [prototyping a byte array] of decimal digits. The
> > OUTPUT was also a list of something. A few messages later, it became
> > clear that the output desired was a list of hexadecimal digits. Until
> > he revealed that the input was up to 24 decimal digits,  I was pursuing
> > the notion that a solution involving converting decimal to binary (in a
> > 32-bit long) then to hexadecimal was the way to go.
> >
> > What is apparently needed is an algorithm for converting a "large"
> > number from a representation of one base-10 digit per storage unit to
> > one of a base-16  digit per storage unit,  when the size of the number
> > exceeds the size (8, 16, 32, etc bits) of the "registers" available.
>
> I read his "Yes I realized that after writing it." response to
> Dennis Lee Bieber to mean Bieber was correct and what he wanted
> was to go from BCD to a normal binary integer, which is base 256.

Where I come from, a "normal binary integer" is base 2. It can be
broken up into chunks of any size greater than 1 bit, but practically
according to the wordsize of the CPU: 8, 16, 32, 64, ... bits. Since
when is base 256 "normal" and in what sense of normal?

The OP maintained the line that he has no facility for handling a
base-256 number longer than 2 base-256 digits.

The dialogue between Dennis and the OP wasn't the epitome of clarity:

[OP]
 My apologies, I clearly made a mistake with my calculator, yes the
resulting array I would need is [0xb,0xc,0x6,0x1,0x4,0xe]
[Dennis]
Take note that this[**1**] is NOT a BCD form for "12345678". BCD
(typically
packed) uses four bits per decimal digit. That would make "12345678" =>
 0x12, 0x34, 0x56, 0x78 (ignoring matters of big/little end).

The binary representation of 12345678, in bytes, is 0xBC, 0x61, 0x4E

0xb, 0xc... is really 0x0B, 0x0C... 8-bits per byte, with MSB set to
0000.

Compare:
BCD   00010010 00110100 01010110 01111000
binary        10111100 01100001 01001110
your  00001011 00001100 00000110 00000001 00000100 00001110

[OP]
Yes I realized that [**2**] after writing it.

... [**1**] Dennis's "this" refers to the OP's *output* which is
patently not what the OP was calling BCD.

[**2**] The referent of the OP's  "that" can't be determined
unambiguously, IMHO.


> The point of posting the simple high-level version of the
> algorithm was to show a general form that works regardless of
> particular languages, register sizes and storage considerations.
> Those matters can effect the details of how one shifts a binary
> integer left one bit, but shifting is not complicated in any
> plausible case.
>
> > Is that what you have?
>
> I'm sorry my post so confused, and possibly offended you.

It didn't confuse me. I was merely wondering whether you did in fact
have a method of converting from base b1 (e.g. 10) to base b2 (e.g. 16)
without assembling the number in some much larger base  b3 (e.g. 256).

Offended? Experts have tried repeatedly, and not succeeded :-)

Cheers,
John