Re: Gentler Decimal Floating-Point

Quadibloc wrote:

(snip)

I've heard of that characteristic of PL/I - that binary constants have
to be *written* in binary. I consider that to be utterly bizarre.
Binary numbers inside the computer are still made to represent
numbers, so of course they will be written *in programs* in decimal.

Except for DEC assemblers which seem to prefer octal, it is
usual even for assembly code for the default to be decimal.

For PL/I I was never sure if the intent was to specify the
desired range in decimal, or really to specify decimal arithmetic.
Consider that the Fortran SELECTED_REAL_KIND and SELECTED_INT_KIND
specify the precision and range in decimal digits independent
of the base (any base greater than one) in use.

One possibility is that the PL/I DECIMAL specifier indicates
that the range, precision, or scale factor is specified in decimal
digits. For fixed point with non-zero scale factor that will result
in a lot of multiply and divide by powers of ten, somewhat easier
to do in decimal arithmetic. For FLOAT DECIMAL until recently it
looks like IBM has considered it a way to specify the desired
precision in decimal digits for binary arithmetic.

PL/I was supposed to be usable as a replacement for both FORTRAN and
COBOL, but this one thing is enough to throw out its usability as a
FORTRAN replacement. (Although, I suppose if no implementations are
insane enough to convert from decimal to binary at run time, it could
be tolerated, but it still has a vast potential to create pitfalls.

Yes, I believe compilers are expected to convert constants at compile
time. The language rules specify how those conversions are to be
done. Overall the rules seem to make sense, though in some specific
cases they seem wrong.

> Although I thought this applied only to fixed-point binary and
> decimal, float only existing as binary, at least on System/360 at that
> time.)

Yes. FLOAT DECIMAL could be considered a way to specify the desired
precision in decimal digits, not a request for actual decimal
arithmetic. It does seem convenient to be able to specify the
range or precision actually needed in a given calculation,
instead of depending and/or hoping that the processor defaults
are good enough. In most cases one doesn't really know so
precisely how many digits they need, so popular defaults are used.

-- glen

.

Relevant Pages

  • Re: Is it time to legitimise REAL*8 etc?
    ... want/need to specify things. ... Decimal digits of precision might seem fine ... but that just isn't a good match the reality of programming. ...
    (comp.lang.fortran)
  • Re: prePEP: Decimal data type
    ... You fought against limited precision, ... arbitrarily) coerced into a decimal-fraction before operating ... of "unbounded precision" to come up with real use cases for them, ... > with a divfunction that lets you specify the number of places ...
    (comp.lang.python)
  • Re: Monetary calculations in CL
    ... things like yield rates that specify a number of places of precision and ... round the 13th (by implication do not employ precision to more than the ... calculations can easily consume 20 or more significant digits. ... of places of significance and the rounding policy are supplied. ...
    (comp.lang.lisp)
  • Re: Is it time to legitimise REAL*8 etc?
    ... want/need to specify things. ... Decimal digits of precision might seem fine ... I was wishing I had used "obtuseness" as opposed to simply cumbersome as it is what I find particularly the most difficult issue, ...
    (comp.lang.fortran)
  • Re: SELECTED_REAL_KIND clarification plse
    ... >> relationship between the arguments and the bytes of storage used. ... this will produce a REAL with at least as much precision as IEEE ... >> precision vs exponent range issues for reals, ... eg. if I specify SELECTED_INT_KIND, ...
    (comp.lang.fortran)