![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> Paul Fuller <pgf### [at] optusnet com au> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible <voi### [at] dev null> wrote:
> Warp wrote:
> > Paul Fuller <pgf### [at] optusnet com au> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>>>> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New <dne### [at] san rr com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |