Re: Floating Point Approximations.
Date: Thu, 29 Mar 2007 20:46:42 GMT
>>Two points on BCD math:
> I find BCD rather interesting.
> Some years ago, a colleague and I spent some time thinking about
> BCD formats. In general, I think the term BCD connotes putting
> one decimal digit into four bits, but I think that usage is not
I think the term "binary coded decimal" is rather self-describing as base 10 encoded in binary.
> 1 base 10 digit into 4 base 2 digits is wasteful. We can consider
> putting different numbers of digits into a different number of bytes
> to minimize the waste. In particular, 3 decimal digits fits nicely
> into 10 binary digits, and three sets of 10 binary digits fits nicely
> into a 32 bit word. Thus we can fit 9 digits into 32 bits whereas
> we could only do 8 digits with standard BCD.
> 2^10 = 1024
> 10^3 = 1000
> Pretty close.
I am not sure what the name for base 1000 is. Millimal, maybe? Wouldn't the above be BCM?
> Another big advantage to BCD is the ease of converting to and
> from string formats. With 10 bit BCD, the lookup table is
> 1000 bytes instead of 10 bytes. Although the factor is larger,
> the total number of bytes is trivial so it doesn't matter. (Total
> cost of 1000 bytes of RAM = approximately epsilon cents.)
> (Quick back-of-the-envelope shows it cost more than I thought:
> approx .00013 dollars.)
> Using a larger number of decimal digits at once means that
> operations are more efficient because they can do more at
> once. For example, you can convert 3 digits to/from ascii
> at once instead of 1. You can multiply three digits instead of
> one. Etc.
> An amusing diversion.
I frequently encode things using weird bases--especially if I think a human will ever have to type in a large meaningless number. I try to use a set of familiar characters that users will not mistake. For example, I would not use both 5 and S or 0 and O--a trick I learned on a project at a company that deals with a lot of money. Received on Thu Mar 29 2007 - 22:46:42 CEST