Warp wrote:
> Paul Fuller <pgf### [at] optusnetcomau> wrote:
>> The 'packed decimal' format was really perfect for banks and similar.
> 
>   I really can't understand why. The user doesn't need to know how
> integers are represented internally, so why would he care?

You know that 1/10 can't be exactly represented in binary, but can be 
represented exactly in decimal, right?

Post a reply to this message

> You know that 1/10 can't be exactly represented in binary, but can be 
> represented exactly in decimal, right?

Why not just store the total pence/cents in an int?

Anyway, I thought banks worked internally to fractions of a pence/cent and 
only rounded for statements etc?

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Warp wrote:
> > Paul Fuller <pgf### [at] optusnetcomau> wrote:
> >> The 'packed decimal' format was really perfect for banks and similar.
> > 
> >   I really can't understand why. The user doesn't need to know how
> > integers are represented internally, so why would he care?

> You know that 1/10 can't be exactly represented in binary, but can be 
> represented exactly in decimal, right?

  And 1/3 cannot be represented exactly in *any* base being currently
used in any computer system. So what?

  Besides, 1/10 isn't an integer, so what would BCD integer registers
help that? Any solution you devise will also work with plain binary
registers as well.

-- 
                                                          - Warp

Post a reply to this message

>>>> The 'packed decimal' format was really perfect for banks and similar.
>>>   I really can't understand why. The user doesn't need to know how
>>> integers are represented internally, so why would he care?
> 
>> You know that 1/10 can't be exactly represented in binary, but can be 
>> represented exactly in decimal, right?
> 
>   And 1/3 cannot be represented exactly in *any* base being currently
> used in any computer system. So what?

Financial transactions don't involve units of 1/3. They *do* frequently 
involve 1/10, however. (And 1/100, and smaller.)

>   Besides, 1/10 isn't an integer, so what would BCD integer registers
> help that? Any solution you devise will also work with plain binary
> registers as well.

Oh, well, if it's only *integer* arithmetic then yeah, I have no idea 
what the advantage would be.

Post a reply to this message

scott wrote:
> Why not just store the total pence/cents in an int?

Because when you're talking about thousands of dollars as the smallest 
increment, that wastes space.  Because when you add dollars to pennies to 
fractional pennies, you need to do the scaling anyway.  Because when you 
print out the number, you wind up doing a whole bunch of divide-by-10's 
anyway, and lots and lots of financial processing involves printing out numbers.

And usually (at least in modern standards) these numbers go up to something 
like 38 digits. So why would an "int" be better than packed decimal in terms 
of processing speed?

Anyway, yes, that's basically what this is doing, except with appropriate 
scaling.  Your question is like asking "why not just store the floating 
point number without the exponent?"

The oldest mainframe I worked on has a "scientific" unit (the floating point 
coprocessor) and the "business" unit (the decimal math coprocessor). The 
business unit had things like scatter/gather memory moves, packed decimal, 
and the equivalent of BASIC's "print using" (which I think COBOL called an 
Edit field).

> Anyway, I thought banks worked internally to fractions of a pence/cent 
> and only rounded for statements etc?

Depends what you're doing.  Interest is probably in fractions of a cent. 
Statements are to the penny. Taxes are to the dollar. Etc.

-- 
Darren New, San Diego CA, USA (PST)
    C# - a language whose greatest drawback
    is that its best implementation comes
    from a company that doesn't hate Microsoft.

Post a reply to this message

Warp wrote:
>   Besides, 1/10 isn't an integer, so what would BCD integer registers
> help that? 

It's a scaled integer. Part of the decimal math mechanism includes aligning 
the decimal points.

 > Any solution you devise will also work with plain binary
> registers as well.

Yes, and so would floating point, if you made the registers big enough.

And, like floating point, it would be quite the PITA to translate scaled 
integer numbers into something you could print efficiently, compared to 
using BCD.

COBOL has "display" types (packed BCD) and "computation" types (two's 
complement integers), depending on what you want to do with them.

Why would plain integers be *better* than packed BCD for this sort of 
application? You're going to need specialized instructions if you want to 
run fast in either situation.

-- 
Darren New, San Diego CA, USA (PST)
    C# - a language whose greatest drawback
    is that its best implementation comes
    from a company that doesn't hate Microsoft.

Post a reply to this message

> Because when you're talking about thousands of dollars as the smallest 
> increment, that wastes space.

Oh I see, so it's like a base-10 float?

> And usually (at least in modern standards) these numbers go up to 
> something like 38 digits. So why would an "int" be better than packed 
> decimal in terms of processing speed?

It would avoid the need for custom hardware, but obviously it works out 
faster per $ to get the non-standard CPUs if that's what they actually use.

Post a reply to this message

scott wrote:
>> Because when you're talking about thousands of dollars as the smallest 
>> increment, that wastes space.
> 
> Oh I see, so it's like a base-10 float?

Not exactly.  It's packed BCD. Two decimal digits per byte. The exponent is 
declared at the source code level but isn't stored in memory. It's more like 
"take that number that has two decimal places and add it to this number here 
that has four decimal places."

>> And usually (at least in modern standards) these numbers go up to 
>> something like 38 digits. So why would an "int" be better than packed 
>> decimal in terms of processing speed?
> 
> It would avoid the need for custom hardware, but obviously it works out 
> faster per $ to get the non-standard CPUs if that's what they actually use.

They're really only non-standard compared to x86. Most of the mainframe CPUs 
have had decimal math for years. When you're talking about 38-digit binary 
numbers with assorted number of digits after the decimal points, trying to 
do all that in pure machine-register-size integer operations is slow. You 
don't want slow.

Or, to phrase it another way... You need to print 30 million phone bills 
with itemized phone calls today. How much time are you going to spend 
dividing by ten in order to be able to print the cost of each call, vs the 
storage space you waste by storing the call times and costs as BCD instead 
of binary?

-- 
Darren New, San Diego CA, USA (PST)
    C# - a language whose greatest drawback
    is that its best implementation comes
    from a company that doesn't hate Microsoft.

Post a reply to this message

Darren New wrote:
> They're really only non-standard compared to x86. Most of the mainframe 
> CPUs have had decimal math for years. 

Oh, as did the 6502 in its own way, for that matter. As does the 8086.

-- 
Darren New, San Diego CA, USA (PST)
    C# - a language whose greatest drawback
    is that its best implementation comes
    from a company that doesn't hate Microsoft.

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> And, like floating point, it would be quite the PITA to translate scaled 
> integer numbers into something you could print efficiently, compared to 
> using BCD.

  This CPU broke the 5 GHz barrier. I don't think printing efficiency is
an issue.

> Why would plain integers be *better* than packed BCD for this sort of 
> application?

  2's complement binary registers require simpler circuitry to be operated
with, compared to BCD registers, hence making the CPU design simpler (and
hence less expensive).

  The value range of BCD registers is smaller than that of 2's complement
binary registers.

-- 
                                                          - Warp

Post a reply to this message