Fixed BCD code.

[August Derleth]

Cause I made such a hash of my first attempt, and in an effort to provide
PORTABLE code to solve the problem, I submit this solution to convert to
and from BCD values stored in longs. This should work just as well for
ints and (in theory) chars and, indeed, any integral type. If it doesn't,
suggest ways to improve it, even at a significant speed/code size penalty.

#include <math.h>

long bcd(long decimal)
{
int i;
long result = 0;

for(i = 0; decimal; ++i) {
result += (decimal % 10) * (int) pow(16,i);
decimal /= 10;
}

return(result);
}

long dec(long bcd)
{
long result = 0;
int i;

for(i = 0; bcd; ++i) {
result += (bcd % 16) * (int) pow(10,i);
bcd /= 16;
}

return(result);
}

/* Code tested on all of one machine, but C is portable in theory. */

[Brett Frankenberger]

In article <Xn************ *************** *******@63.223. 5.101>,
August Derleth <li************ *****@onewest.n et> wrote:

Cause I made such a hash of my first attempt, and in an effort to provide
PORTABLE code to solve the problem, I submit this solution to convert to
and from BCD values stored in longs. This should work just as well for
ints and (in theory) chars and, indeed, any integral type. If it doesn't,
suggest ways to improve it, even at a significant speed/code size penalty.

#include <math.h>

long bcd(long decimal)
{
int i;
long result = 0;

for(i = 0; decimal; ++i) {
result += (decimal % 10) * (int) pow(16,i);
pow(16, i) returns a double, which you then cast to an int. There is
no guarantee that either has as much precision as a long. Instead:
result += (decimal %10) << (4 * i);
(Also offers the performance benefit of not converting back and forth
between floating point and integer.)

For similar reasons:

long dec (long bcd)
{
long result = 0, i = 1;

while (bcd) {
result += bcd % 16 * i;
i *= 10;
bcd /= 16;
};
}
/* Code tested on all of one machine, but C is portable in theory. */

Only when you don't make assumptions about implementation-defined
portions of the standard.

-- Brett

[August Derleth]

rb*@panix.com (Brett Frankenberger) wrote in
news:bj******** **@reader2.pani x.com on Fri 05 Sep 2003 09:04:00p:

In article <Xn************ *************** *******@63.223. 5.101>,
August Derleth <li************ *****@onewest.n et> wrote:

for(i = 0; decimal; ++i) { result += (decimal % 10) * (int)
pow(16,i);

pow(16, i) returns a double, which you then cast to an int. There is
no guarantee that either has as much precision as a long. Instead:
result += (decimal %10) << (4 * i);

Ah, but will the shifts be portable to machines that use, say, multiples
of three for their word-size? Will my multiplies?

I can't think of how BCD would work in an octal system (where you'd only
have three bits to encode each digit*), or on a hypothetical ternary
system (which /good/ C code is supposed to be portable to).

Is the problem itself limited to certain kinds of systems?

*Three bits only gives you eight numbers. Nine bits is 8+1, giving you the
possibility of encoding one `traditional' BCD digit with the option of a
sign bit. You can do the math from there.

/* Code tested on all of one machine, but C is portable in theory. */

Only when you don't make assumptions about implementation-defined
portions of the standard.

Touche'.