chris@umcp-cs.UUCP (Chris Torek) (11/09/84)
I have always been surprised that business people didn't just use 64
bit integers, and keep the amounts in CENTS. No BCD required, can
take advantage of nice fast machine instructions, etc.
--
(This mind accidently left blank.)
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (301) 454-7690
UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet: chris@umcp-cs ARPA: chris@marylandhenry@utzoo.UUCP (Henry Spencer) (11/11/84)
> I have always been surprised that business people didn't just use 64 > bit integers, and keep the amounts in CENTS. No BCD required, can > take advantage of nice fast machine instructions, etc. It's not hard to figure out. I once read an excellent paper -- alas, I don't have it handy -- that pointed out a basic behavior pattern: new tools, when applied to old problems, are invariably applied in a way that mimics the old methods as closely as possible. Evolution toward new methods, better suited to the new tools, comes much later. One of the prime examples in the paper -- I think it was in one of the Joint Computer Conferences, which would make it nearly 20 years ago -- was the continuing dominance of decimal arithmetic in business computing. Of course the business people use decimal arithmetic; it never occurred to them to do anything else. And now the albatross of being "backward compatible with all previous mistakes" has locked them into it, but good. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
barmar@mit-eddie.UUCP (Barry Margolin) (11/14/84)
In article <4611@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >> I have always been surprised that business people didn't just use 64 >> bit integers, and keep the amounts in CENTS. No BCD required, can >> take advantage of nice fast machine instructions, etc. > >It's not hard to figure out. I once read an excellent paper -- alas, >I don't have it handy -- that pointed out a basic behavior pattern: >new tools, when applied to old problems, are invariably applied in a >way that mimics the old methods as closely as possible. Evolution >toward new methods, better suited to the new tools, comes much later. > >One of the prime examples in the paper -- I think it was in one of the >Joint Computer Conferences, which would make it nearly 20 years ago -- >was the continuing dominance of decimal arithmetic in business computing. >Of course the business people use decimal arithmetic; it never occurred >to them to do anything else. And now the albatross of being "backward >compatible with all previous mistakes" has locked them into it, but good. >-- > Henry Spencer @ U of Toronto Zoology > {allegra,ihnp4,linus,decvax}!utzoo!henry I think it is inertia. Two decades ago, when business computing habits were being formed, there probably was not very good hardware available on computers for doing 64-bit integer arithmetic. However, because of the reasons cited above by Henry Spencer, large-precision decimal units were invented. -- Barry Margolin ARPA: barmar@MIT-Multics UUCP: ..!genrad!mit-eddie!barmar
jfarrell@sun.uucp (Jerry Farrell) (11/15/84)
> Of course the business people use decimal arithmetic; it never occurred > to them to do anything else. Uhh, can we have a slight intrusion of reality? Back when I was writing COBOL programs to compute the faculty contact hours per square foot of classroom floor space and other inania like that, the various encodings of numeric were very familiar to us; we chose among them on several criteria: frequency of presentation vs. calculation many numbers could be used in a calculation, but were much more likely to simply be printed or displayed. For these, it was generally most efficient to take COBOL's default numeric type, DISPLAY -- i.e. digit characters. space There are a few cases where BCD actually uses less space than simple binary: on most machines, +/-99,999 requires you to go from 16 to 32 bits, but it fits in 6 bytes of BCD. debugging ease when you're looking at a disk buffer for the record that seems to have the wrong number in it, it saves a lot of time if the number is intelligible to carbon-based, as well as silicon-based forms. I can attest we used COMP-1 (binary) as well as COMP-3 (packed / bcd); what we avoided like the plague was COMP-2 (32-bit float). COMP-3 was generally chosen as a reasonable compromise between presentation & calculation, with an occasional bow toward debugging.
henry@utzoo.UUCP (Henry Spencer) (11/16/84)
> when you're looking at a disk buffer for the record that seems > to have the wrong number in it, it saves a lot of time if the > number is intelligible to carbon-based, as well as silicon-based > forms. Silicon-based entities are generally willing to translate, if asked. In fact they have to, since the relationship between their bit patterns and the symbols we see on our screens and printers is arbitrary and requires translation. I generally store my data on disk in ASCII characters too, but I'd never consider trying to do arithmetic on it that way. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
geoff@desint.UUCP (Geoff Kuenning) (11/18/84)
> I have always been surprised that business people didn't just use 64 > bit integers, and keep the amounts in CENTS. No BCD required, can > take advantage of nice fast machine instructions, etc. Primarily because there are *still* relatively few machines that have good support for 64-bit integers. The average 32-bitter has 32x32 multiply that produces 64 bits, and a corresponding 64/32 divide, but other 64-bit math has to be implemented with "add with carry" instructions. If I recall correctly, the 360 didn't even have such an instruction, so you really had to hack it. The 2-3 instruction sequences needed to perform 64-bit arithmetic are not really more efficient than single BCD instructions. Furthermore, many business programs (e.g., general ledger or accounts receivable update) have a general model of "read in two fields, add them, write it out". You can do a BCD add *much* faster than you can do two conversions and a 64-bit binary add. Remember that decimal conversion inherently involves multiplication and division. -- Geoff Kuenning First Systems Corporation ...!ihnp4!trwrb!desint!geoff
robert@gitpyr.UUCP (Robert Viduya) (11/19/84)
> > space > There are a few cases where BCD actually uses less space than > simple binary: on most machines, +/-99,999 requires you to go > from 16 to 32 bits, but it fits in 6 bytes of BCD. > Uh, 6 bytes equals 48 bits on most machines. -- Robert Viduya Office of Computing Services Georgia Institute of Technology, Atlanta GA 30332 Phone: (404) 894-4669 ...!{akgua,allegra,amd,hplabs,ihnp4,masscomp,ut-ngp}!gatech!gitpyr!robert ...!{rlgvax,sb1,uf-cgrl,unmvax,ut-sally}!gatech!gitpyr!robert
breuel@harvard.ARPA (Thomas M. Breuel) (11/20/84)
> ... have a general model of "read in two fields, add them, > write it out". You can do a BCD add *much* faster than you can do two > conversions and a 64-bit binary add. Remember that decimal conversion > inherently involves multiplication and division. As soon as I/O gets involved, it hardly matters which one is faster computationally. BTW, you can do conversions using shifts and (sorry to say that) BCD arithmetic... but you can write that in assembly language. Thomas. (breuel@harvard).
geoff@desint.UUCP (Geoff Kuenning) (11/24/84)
In article <161@harvard.ARPA> breuel@harvard.ARPA (Thomas M. Breuel) writes: >As soon as I/O gets involved, it hardly matters which one is faster >computationally. BTW, you can do conversions using shifts and (sorry >to say that) BCD arithmetic... but you can write that in assembly >language. A Fujitsu Eagle transfers data at about 1.8 megabytes per second. Many mainframe disks are even faster. If you are storing 6-byte (12-digit) BCD and are adding two streams, you are transferring 18 bytes per operation. Assuming you double-buffer but have only one controller, this is 100K operations per second. You thus have to convert to binary, add, and convert back to BCD in approximately 10 microseconds. I am perfectly aware that multiplications can be done with shifts and adds. Indeed, that's how hardware multipliers work. But I have never seen an algorithm for converting binary to decimal without doing divisions. It is pretty hard to do 12 digits' worth of binary-to-decimal conversion in 10 microseconds on most machines (though possible on a modern mainframe--right, Gordon?). But a 12-digit BCD add can be pretty easy. And it's actually worse than that, because a mainframe that powerful typically has several controllers so that the full 1.8 megabyte output data rate could be maintained if the CPU could keep up with it. -- Geoff Kuenning ...!ihnp4!trwrb!desint!geoff
guy@rlgvax.UUCP (Guy Harris) (11/27/84)
> >As soon as I/O gets involved, it hardly matters which one is faster > >computationally. BTW, you can do conversions using shifts and (sorry > >to say that) BCD arithmetic... but you can write that in assembly > >language. > > A Fujitsu Eagle transfers data at about 1.8 megabytes per second. Many > mainframe disks are even faster. If you are storing 6-byte (12-digit) BCD > and are adding two streams, you are transferring 18 bytes per operation. > Assuming you double-buffer but have only one controller, this is 100K > operations per second. You thus have to convert to binary, add, and > convert back to BCD in approximately 10 microseconds. Ummmmmmm... isn't there any seek time in there? Even with IBMish track-at- a-time reads the heads'll have to move *some*time - and if you're not doing sequential access of a batch file, but, say, a transaction processing application they'll be moving more than that. For that matter, what if the operation involves multiplication or, worse, division? BCD *adds* can be done quickly (even 4/8 digits in parallel), but multiplications and divisions are a major pain. Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
geoff@desint.UUCP (Geoff Kuenning) (11/29/84)
In article <257@rlgvax.UUCP> guy@rlgvax.UUCP (Guy Harris) writes: >Ummmmmmm... isn't there any seek time in there? Even with IBMish track-at- >a-time reads the heads'll have to move *some*time - and if you're not doing >sequential access of a batch file, but, say, a transaction processing >application they'll be moving more than that. It's not how much you read at once, it's how the filesystem organizes data. If your data is contiguous, we are talking 3-6ms to step to the next cylinder; on an Eagle this occurs only once every ~900 blocks (I don't remember the exact shape of that disk). Certainly transaction processing applications are dominated by seek time. But a lot of business processing (probably most) is done in batch mode. That's why they put so much effort into sort programs. >For that matter, what if the operation involves multiplication or, worse, >division? BCD *adds* can be done quickly (even 4/8 digits in parallel), but >multiplications and divisions are a major pain. Again, true. But how much business processing involves multiplication, compared to the amount of simple addition and subtraction? Interest rates and taxes are two, but most business arithmetic is simple. The IBM 1401 (which was designed for business) didn't even have a multiply instruction, and if you bought the option it operated by repeated addition (we're talking decrementing the multiplier for each addition here folks -- no shifting at all!). -- Geoff Kuenning ...!ihnp4!trwrb!desint!geoff