Re: Floating point questions

Tom Linden wrote:
On Tue, 11 Jul 2006 12:03:22 -0700, <briggs@xxxxxxxxxxxxxxxxx> wrote:

In article <890539d90607110905y144c0140kbcc400a7a0b20c4a@xxxxxxxxxxxxxx>, "Carl Friedberg" <frida.fried@xxxxxxxxx> writes:
From deepest, darkest memory niches (failing cells too)

The way that packed decimal interfaces to other formats is very interesting.

Packed decimal is definitely of IBM origin, but was fully supported on VAXn
of the 780/750 era. Beginning with MicroVAX II, the concept of partially
supported architectures was introduced, and packed decimal was allowed
to be migrated off the hardware. Various flavors of VAXen had various levels
of hardware support, but I believe that if you did Cobol benchmarks, in
many cases the results were dismal when Packed Decimal arithmetic
was at issue.

A funny thing: IIRC to convert from integer to floating, IBM first converted
from integer to Packed, and then from packed to floating, as it was much
faster that way.

Strange, if true.

IBM floating point has (had?) a binary fraction and a base 16 exponent.
The fraction was typically normalized so that the high order 4 bits were
not all zero. This is memory from circa 1974, I don't know whether
denormalized fractions were actually allowed.

IBM integers are 32 bit two's complement binary values.

Converting from integer to floating point is mainly a matter of deciding
what exponent to use and masking the appropriate set of bits from
the integer value into the fraction field in the floating point value.

Unless bit string operations are horrendously expensive and packed decimal
instructions are very well microcoded, the notion that converting
from binary to decimal and back is the most efficient way to change from
binary fixed point to binary floating point does not seem plausible.

For banking applications, there was no alternative to packed decimal because
there were no rounding errors (it wasn't floating point) and no issues with
handling pennies correctly...

Packed decimal is not immune to rounding errors (divide by 3 sometime).
Binary floating point need not have rounding errors (add 2 + 2 sometime).

What _is_ true is that packed decimal deals quite conveniently with
fractions that are powers of ten, that packed decimal implementations
typically include language support for decimal-scaled packed decimal (*)
and that packed decimal implementations typically support more significant
digits than double precision floating point.

As a practical matter, this means that packed decimal is the clear choice
for financial applications in languages that support it. And languages
that support it are the clear choice for financial applications.

It is possible to use scaled double-precision floating point as an
alternative.

In my younger days I did precisely this because what I had was VAX Fortran
and D-floating and what I needed were 9 and 10 digit dollar values
accurate to the penny. There was no 64 bit integer language support
or I'd have gone with scaled integers instead.

With a scaling factor of 100, floating point addition and subtraction in
pennies are not subject to round-off error as long as all the values
involved fall within the range of exactly expressible integers.

Multiplication by an integer is similarly not subject to round-off
errors as long as the product is an exactly expressible integer.

Division and multiplication by a decimal fraction won't usually
be exact. But in the usual case, those results don't need to be exact.
They'll be rounded off anyway. [In some applications such as, for
instance, currency exchange or the stock market, details of that round-off
may be very carefully specified]


* By language support for decimal-scaled packed decimal I mean constructs
like

05 YTD-PAY PICTURE S9(9)V99 USAGE IS PACKED-DECIMAL.

where the compiler automatically keeps track of the scaling factor of 100
for you.

In PL/I Picture data types are not packed decimal but are stored as character strings.
PL/I supports both Picture and scaled fixed decimal, the latter stored as
packed decimal, i.e., BCD. So how many bytes of storage are required for the above Cobol declaration?

From the Compaq COBOL Reference Manual (Table 5-13 in the Nov-2002 edition):

Picture clause Allocated Storage in Bytes

PIC 9(n)V9(s) COMP-3 (n+s+1)/2 rounded up

[(n+s) <= 31
(Alpha) or
18 (VAX)]


PIC S9(n)V9(s) COMP-3 (n+s+1)/2 rounded up
[(n+s) <= 31
(Alpha) or
18 (VAX)]

Sorry, I can't remember off the top of my head how the sign is represented.
.

Relevant Pages

  • Re: IEEE Decimal Float on Itanium
    ... Looks like IBM has the lead on everyone ... I too have used binary integers for years in such situations, ... hardware support on VAX, but which we do in runtime on Alpha, another Alpha ... WADU, binary is not the problem, the floating point is. ...
    (comp.os.vms)
  • Re: Floating point questions
    ... Packed decimal is definitely of IBM origin, but was fully supported on VAXn ... IIRC to convert from integer to floating, ... IBM floating point has a binary fraction and a base 16 exponent.. ... typically include language support for decimal-scaled packed decimal ...
    (comp.os.vms)
  • Re: Floating point questions
    ... Packed decimal is definitely of IBM origin, but was fully supported on VAXn ... IIRC to convert from integer to floating, ... IBM floating point has a binary fraction and a base 16 exponent. ... typically include language support for decimal-scaled packed decimal ...
    (comp.os.vms)
  • Re: Floating point questions
    ... Packed decimal is definitely of IBM origin, but was fully supported on VAXn ... IIRC to convert from integer to floating, ... >> Packed decimal is what IBM calls two BCD digits per byte. ... > Other vendors also support it. ...
    (comp.os.vms)
  • RE: Floating point arithmetic support in DCL
    ... /*> you provide inherent DCL symbol support for floating point. ... /*> The "decimals" would be used when converting the binary value ...
    (comp.os.vms)