why still use C?

[cody]

no this is no trollposting and please don't get it wrong but iam very
curious why people still use C instead of other languages especially C++.

i heard people say C++ is slower than C but i can't believe that. in pieces
of the application where speed really matters you can still use "normal"
functions or even static methods which is basically the same.

in C there arent the simplest things present like constants, each struct and
enum have to be prefixed with "struct" and "enum". iam sure there is much
more.

i don't get it why people program in C and faking OOP features(function
pointers in structs..) instead of using C++. are they simply masochists or
is there a logical reason?

i feel C has to benefit against C++.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Keith Thompson]

"Douglas A. Gwyn" <DA****@null.net> writes:

Dan Pop wrote:

This is, by far, the cleanest approach. Introduce something like
dfloat, ddouble and long ddouble and <dmath.h> and make them optional
(a macro in the implementation name space will indicate whether the
implementation supports them or not).

Unfortunately there are good arguments against that approach.
Ultimately the specification will be the result of negotiating
a consensus on the right balance among the competing factors.

Decimal floating-point isn't intended to *replace* binary
floating-point, is it?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
(Note new e-mail address)
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Thad Smith]

After reading comments on the proposed decimal fp standardization for C
and C++, I began
thinking more generally about the process of standardizing useful
features, I wonder if it is time to put effort into standardizing on two
(or possibly more) distinct levels: the core language, which should be
fairly stable, and add-on packages to suit various applications, such as
financial calculations.

There are many other such application types that would benefit from
extensions and standardization as have been mentioned here: extended
time/calendar calculations, extended scientific calculations, file
system control, external binary formatting, multi-threaded control, GUI
support, etc. Does it make sense to standardize these? I think so.
Does it make sense to attempt to put these all in one language
standard? I doubt it. I think the standard becomes too complex and
cumbersome.

Yes, there are add-on libraries to address these extended needs. Some
of these attempt to define a standard. Many are primarily targeted to
specific platforms and don't port well or are simply ignored when
implementing something for a different platform, vendor, etc.

Does a two-tiered system for standardization make sense? Will it work?
Has it been shown to work or fail in other instances?

Thad
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Brian Inglis]

On 11 Nov 2003 19:53:12 GMT in comp.lang.c.moderated, Fergus Henderson
<fj*@cs.mu.oz.au> wrote:

Ben Pfaff <bl*@cs.stanford.edu> writes:

"Douglas A. Gwyn" <DA****@null.net> writes:

Exactly how the C standard will accommodate this is still an
open question; we might simply revise the floating-point model
to allow float, double, and long double to use decimal
representation, [...]

Doesn't it already? FLT_RADIX is constrained to be greater than
or equal to 2, which doesn't preclude decimal representation
as far as I can tell.

In theory, perhaps; but in practice, no, because backwards compatibility,
binary compatibility, and compatibility with other standards would prevent
implementations from defining `float' and `double' with decimal
representations. The only feasible way of supporting decimal floating
point in C would be for it to be a new type, rather than replacing one
of the existing types.

Not at all -- IBM M/F 360/370/390 native compilers use FLT_RADIX 16 --
and newer systems also support IEEE FP -- so supporting another FP
option would only be a SMOP.
Has any machine ever supported *hardware* *decimal* *floating point*
arithmetic? Not *fixed* (un-/packed) decimal arithmetic, which
requires the programmer or compiler and library to do the scaling, and
not software decimal floating point.
--
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada

Br**********@CSi.com (Brian dot Inglis at SystematicSw dot ab dot ca)
fake address use address above to reply
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Brian Inglis]

On 13 Nov 2003 02:52:50 GMT in comp.lang.c.moderated, Keith Thompson
<ks***@mib.org> wrote:

"P.J. Plauger" <pj*@dinkumware.com> writes:
[...]

One possibility the C and C++ committees will have to explore is simply
rounding out the consequences of having an implementation where float,
double, and long double are these new decimal formats instead of binary
IEEE 754 and its ilk. That's a *very* lightweight change, from a language
point of view, because the C Standard already permits decimal floating
point. The folks who have to do the heavy lifting are us library
implementors, who have many math functions to convert over. (We'll have
to do that for *any* approach.)

[...]

Hmm. I'm a bit skeptical that the existing floating-point types can
be made decimal without breaking existing code, especially scientific
code. No, the standard doesn't guarantee that the existing types are
binary, but it's a common assumption.

My concern is that existing code, compiled with a new compiler, could
produce subtly different results.

One obvious solution would be to provide, say, a command-line option
that makes the predefined types binary, but then the semantics of the
program would depend on the source code plus the command-line options.

C compilers for IBM 360/370/390 MFs have supported native hexadecimal
FP for years; newer compilers also now support IEEE (binary) FP on
their newer MFs; adding decimal FP as a third option should be easier
on those compilers than others that have not dealt with that
possibility.
GCC could fairly easily add submodel options such as
-mfpmath={2|10|16} or -mfp{b|d|h} as such options already exist for
M68K, i386, VAX, and other target architectures, although not sure
whether float.h definitions differed with any of these targets.
--
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada

Br**********@CSi.com (Brian dot Inglis at SystematicSw dot ab dot ca)
fake address use address above to reply
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Christian Bau]

In article <cl****************@plethora.net>,
Keith Thompson <ks***@mib.org> wrote:

"Douglas A. Gwyn" <DA****@null.net> writes:

Dan Pop wrote:

This is, by far, the cleanest approach. Introduce something like
dfloat, ddouble and long ddouble and <dmath.h> and make them optional
(a macro in the implementation name space will indicate whether the
implementation supports them or not).
Unfortunately there are good arguments against that approach.
Ultimately the specification will be the result of negotiating
a consensus on the right balance among the competing factors.

Decimal floating-point isn't intended to *replace* binary
floating-point, is it?

An implementation could replace binary floating-point with decimal
floating-point; the C Standard doesn't require that floating point is
binary. Since decimal floating point is likely to be hundred times
slower than binary floating point on the computer you are using right
now, such an implementation wouldn't be very popular :-(
From what I am reading, it seems that decimal floating point will

definitely be added to the IEEE 754 standard. In C++ decimal floating
point could be added quite easily as a class; no change in the compiler
needed, same as complex. In C, decimal floating point would have to be
added as proper new datatypes. I must say I would prefer if C++ did it
the same way.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Fred J. Tydeman]

Brian Inglis wrote:

Has any machine ever supported *hardware* *decimal* *floating point*
arithmetic? Not *fixed* (un-/packed) decimal arithmetic, which
requires the programmer or compiler and library to do the scaling, and
not software decimal floating point.

Yes. The IBM 1620 used variable length (up to 99 digits, with
2 digits of exponent) of BCD (binary coded decimal) as its only
floating-point type. This was done in hardware (but the hardware
used addition and multiplicatoin tables in user memory -- nasty
bugs resulted if you ever altered those tables).
This was the first machine I programmed on, back in 1967.
---
Fred J. Tydeman Tydeman Consulting
ty*****@tybor.com Programming, testing, numerics
[phone] Vice-chair of J11 (ANSI "C")
Sample C99+FPCE tests: ftp://jump.net/pub/tybor/
Savers sleep well, investors eat well, spenders work forever.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Morris Dovey]

Francis Glassborow wrote:

In article <cl****************@plethora.net>, Thad Smith
<th**@ionsky.com> writes

Francis Glassborow wrote:

During the last two weeks of October WG14 (C) and WG21
(C++) both voted to work on providing decimal floating
point types.
Where did the impetus for this originate?

IBM

<snip concurrency, C++ remarks>

Why is the C committee considering this?

You would be very surprised, but for many commercial
applications the cost of emulating decimal floating point
arithmetic is very high (factors of hundreds compared with
floating point arithmetic done in a base directly supported by
hardware. Typical billing programs (constrained by tax
legislation to high degrees of precision) can be improved by
overall factors in excess of three if direct hardware support
is provided for decimal floating point.

I'm having difficulty finding the point of these arguments.
Perhaps my experiences with binary floating point in commercial
applications has clouded my ability to see the "need" to emulate
decimal floating point.

I have no difficulty believing that if one were to require that
computations be performed in a radix 10 floating point, then a
hardware radix 10 capability would be orders of magnitude faster;
but I do have difficulty finding the "need" to perform those
computations in /any/ particular floating point radix.

The need for high degrees of precision in computation is not a
new issue and I fail to see how a change in radix will provide a
major improvement.

Has WG14 made the decision that the needs of "typical billing
programs" should determine the C language architecture and
associated standards?

Would anyone care to wager that "the typical billing program"
/cannot/ be improved by overall factors in excess of three even
if decimal floating point is not provided?
The exact way that C and C++ might utilise future decimal FPUs
is open for discussion but we are quite certain that if these
languages are to remain competitive (in overall performance)
for commercial applications we need to tackle the issue in a
timely fashion.
A certain amount of sarcasm might be appropriate at his point.
I'd be inclined to suggest a that a reworking of those portions
of the standard dealing with the commercial basics of /time/ and
/money|currency/ might be even more important and pressing set of
issues than the performance of a subset of a limited range of
applications.

[I recall a thread some time ago on comp.lang.c in which one of
the committee members mentioned that it was _IBM's_ desire to
ignore prior art and existing practice by rendering time_t
useless to application programmers.]

Since when (and by whom) has there been a declaration that C is
competing (with whom and for what) as a tool for building
commercial applications? Is the term "panacea" being added to the
language definition?
We are also certain that the two languages should tackle their
support in a way that ensures compatibility of code even
though C is likely to provide new fundamental types and C++ is
likely to work with library types. We do not want the problems
(small though they are if code is written carefully) that
surfaced through the independent support of complex types in C
and C++.
Given that the floating point radix has never been restricted to
any particular value, you should probably not contract the
language definition at this point by deciding that you've fallen
in love with ten. My sense is that any requirements (other than
the specific radix value, of course) for one radix should also be
in force for all others.
In addition it is a matter of choosing a single item to work
on though concurrency is far more demanding and hard to get
right.

This sounds like a really good rationale for deleting the last
four letters from "COBOL" and using that standard. Much less
demanding; and if it has flaws you can always point at someone
else...
--
Morris Dovey
West Des Moines, Iowa USA
C links at http://www.iedu.com/c
Read my lips: The apple doesn't fall far from the tree.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Brian Inglis]

On 11 Nov 2003 19:53:57 GMT in comp.lang.c.moderated, "P.J. Plauger"
<pj*@dinkumware.com> wrote:

"Thad Smith" <th*******@acm.org> wrote in message
news:cl****************@plethora.net...

Thanks P.J., Francis, and Douglas, and Fred for your helpful and
informed responses. I suspect there are other regular readers here that
were as surprised as I am about the proposal. IF decimal f.p. is going
to be added to both languages, it certainly makes sense to make them
compatible.

My bias is that decimal arithmetic is more the domain of Cobol and
PL/I. Perhaps it is time to add this support to other popular
languages. My first thought was "OK, add it to C++. It should be
relatively easy. Programmers who want decimal f.p. can use C++. C is
more for system routines and embedded applications that don't have much
demand for decimal f.p."

If that viewpoint is out of touch, please clue me in. ;-)
What's new here is the engineering that has gone into IEEE 754R. We now
have an encoding of decimal floating point with many desirable properties,
not the least of which is the potential for speed and storage economy
comparable to existing binary floating point. And we have IBM's public
commitment to producing hardware that uses this format.

Fairly easy for IBM, as they have the relatively recent experience of
adding IEEE FP support to their M/F compilers which only supported
their hex radix FP previously. Any other interest in building decimal
FP hardware, as from Intel or AMD?
One possibility the C and C++ committees will have to explore is simply
rounding out the consequences of having an implementation where float,
double, and long double are these new decimal formats instead of binary
IEEE 754 and its ilk. That's a *very* lightweight change, from a language
point of view, because the C Standard already permits decimal floating
point. The folks who have to do the heavy lifting are us library
implementors, who have many math functions to convert over. (We'll have
to do that for *any* approach.)

A slightly heavier possibility, which is more what IBM has proposed, is
to introduce decimal floating point alongside whatever the builtin
floating-point types currently provide. Doing that requires either adding
three more builtin floating-point types (certainly in C, possibly also in
C++), or adding some second-class citizens (easier in C++, thanks to
operator overloading).
Seems to be somewhat contrary to the "spirit of C" and existing
approaches where FP implementation variations are code gen and library
function options, and FP radix an implementation detail.
A still heavier possibility is to stick with just three builtin types,
which are either binary or decimal, and provide for *two* sets of
second-class citizens. One of these would be assuredly binary, the
other assuredly decimal. And one of the two would have the same
representation as the builtin types. That makes sense only if we can
demonstrate a clear need for both forms of arithmetic within one
program.
If the hardware, compiler, and library implementations are comparable,
are there many applications where properties of tuned binary FP
algorithms and decimal FP requirement are both required?
It's too soon to say what the best solution will be, but at least the
two committees will be in close communication during the exploration
and development.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

--
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada

Br**********@CSi.com (Brian dot Inglis at SystematicSw dot ab dot ca)
fake address use address above to reply
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Douglas A. Gwyn]

Keith Thompson wrote:

Decimal floating-point isn't intended to *replace* binary
floating-point, is it?

Several people think that on many platforms it might.
There would be a large cost in supporting both in a
microprocessor implementation.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Douglas A. Gwyn]

Thad Smith wrote:

Does a two-tiered system for standardization make sense? Will it work?
Has it been shown to work or fail in other instances?

COBOL had various levels of conformance, and generally all
it accomplished was complication. In practice all implementations
ended up providing all the levels, so what was the point?

It would be great for some language with suitable support
for packaging to have a set of optional packages that did
not intrude if the ackages weren't used. C is not such a
language.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Keith Thompson]

Brian Inglis <Br**********@SystematicSw.ab.ca> writes:
[...]

Has any machine ever supported *hardware* *decimal* *floating point*
arithmetic? Not *fixed* (un-/packed) decimal arithmetic, which
requires the programmer or compiler and library to do the scaling, and
not software decimal floating point.

Most programmable calculators support hardware decimal floating point.
I don't think any of them have C implementations, but some of the more
powerful ones probably could.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
(Note new e-mail address)
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Morris Dovey]

Francis Glassborow wrote:

Ordinary users of either C or C++ should appreciate the degree
to which those who do the work on the relevant standards are
going the extra mile (kilometre) to work together.

Extra mile/kilometer noted and appreciated.

As an ordinary user of C my appreciation is multiplied by a
factor representing the perceived improvement in the language.

In the past, that factor has not always been greater than zero. I
would suggest that a standard change to the benefit of a single
hardware producer deserves /very/ close examination.

I haven't found any references to IBM patents covering decimal
floating point implementations. Does IBM hold and/or have
application(s) pending for such patents? If so, are those patents
sufficiently broad as to exclude other hardware producers from
producing decimal FPUs of equal (or better) performance at equal
(or better) cost?

If the answer is "yes" or even "I don't know", then those who do
the work on the relevant standards aren't going that extra mile
for me, the ordinary user (and, when all is said and done, merit
neither appreciation nor respect from ordinary users).
--
Morris Dovey
West Des Moines, Iowa USA
C links at http://www.iedu.com/c
Read my lips: The apple doesn't fall far from the tree.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[David Spencer]

Thad Smith <th*******@acm.org> writes:

I wonder if it is time to put effort into standardizing on two (or
possibly more) distinct levels: the core language, which should be
fairly stable, and add-on packages to suit various applications, such
as financial calculations.

This is the way most engineering standards are constructed. It would
be an excellent idea for a language as flexible as C.

--
dhs sp*****@panix.com
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[CBFalconer]

Brian Inglis wrote:

..... snip ...
Has any machine ever supported *hardware* *decimal* *floating point*
arithmetic? Not *fixed* (un-/packed) decimal arithmetic, which
requires the programmer or compiler and library to do the scaling,
and not software decimal floating point.

Yes. I built one almost 40 years ago. It was probably better
classified as a programmable calculator. It used excess-3 coding,
9 significant digits + sign digit, 2 digit exponent offset by 50.
Arithmetic was 9's complement.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Keith Thompson]

Christian Bau <ch***********@cbau.freeserve.co.uk> writes:
[...]

From what I am reading, it seems that decimal floating point will
definitely be added to the IEEE 754 standard. In C++ decimal floating
point could be added quite easily as a class; no change in the compiler
needed, same as complex. In C, decimal floating point would have to be
added as proper new datatypes. I must say I would prefer if C++ did it
the same way.

It seems to be that, assuming the existing binary FP support is left
in place, both C and C++ would have problems with floating-point
literals. (Yes, I'm assuming the existing FP types are binary; no,
that's not guaranteed by the current standard.)

For example, assuming that "d_double" is a decimal double-precision
type (perhaps a typedef), what would be the semantics of the
following?

d_double x = 0.1;

Ideally, you'd want to assign the exact value 0.1 to x, but 0.1 is a
literal of type double, so it's not exactly representable in a binary
type. Logically, the literal 0.1 should evaluate to a close binary
approximation which is then converted from double to d_double. Either
this can potentially lose information (e.g., setting x to
0.0999999999999), or you need a complicated set of rules to guarantee
that it doesn't.

For maximum user-friendliness, you'd want the above to mean just what
it looks like, but that would require the type of a literal to depend
on its context. At the least, I think you need another suffix to
specify that a literal is decimal:

d_double x = 0.1D;

but forgetting the suffix is likely to be a common subtle error.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
(Note new e-mail address)
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Alexander Terekhov]

Morris Dovey wrote:
[...]

I haven't found any references to IBM patents covering decimal
floating point implementations.

I'm not sure how relevant this is with respect to "final specs",
but some discussion on IBM decimal patents related stuff can be
found here:

http://grouper.ieee.org/groups/754/m.../02-04-18.html

That's 6,437,715/6,525,679 (equivalents in Europe and Japan aside
for a moment), I guess.

regards,
alexander.

--
http://groups.google.com/groups?selm...5BCA3%40web.de
(Subject: Re: Software patents make no sense)

[those who know me have no need of my name]

in comp.std.c i read:

Thad Smith wrote:

Does a two-tiered system for standardization make sense? Will it
work? Has it been shown to work or fail in other instances?

COBOL had various levels of conformance, and generally all
it accomplished was complication. In practice all implementations
ended up providing all the levels, so what was the point?

and, c already has two levels of conformance: hosted and free-standing.

--
a signature
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Francis Glassborow]

In article <cl****************@plethora.net>, Morris Dovey
<mr*****@iedu.com> writes

If the answer is "yes" or even "I don't know", then those who do the
work on the relevant standards aren't going that extra mile for me, the
ordinary user (and, when all is said and done, merit neither
appreciation nor respect from ordinary users).

As I understand it those involved in Standardisation are required to
declare any existing patents, copyrights etc. that are relevant. In
addition there are already several relevant standards:

IEEE 754R, IEEE 854, ANSI X3.274, ECMA 334

For more details check:

http://www2.hursley.ibm.com/decimal/

--
Francis Glassborow ACCU
If you are not using up-to-date virus protection you should not be reading
this. Viruses do not just hurt the infected but the whole community.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[James Kuyper]

Morris Dovey wrote:
....

The need for high degrees of precision in computation is not a
new issue and I fail to see how a change in radix will provide a
major improvement.
It's not "high degrees of precision" that are needed. It's a fairly low
degree of precision, but it needs to be provided exactly, which makes is
similar in some ways to requiring infinite precision.
Has WG14 made the decision that the needs of "typical billing
programs" should determine the C language architecture and
associated standards?
Apparantly they've decided that those needs should be considered. Your
use of "determine" is a loaded phrase; taken to it's logical extreme,
your criticism implies that the C standard should never contain any
feature that is needed only by a minority of the users. In fact, most of
C's features are needed only by a minority, especially in the C standard
library. A great many programs make no use of floating point at all,
whether binary or decimal.
Would anyone care to wager that "the typical billing program"
/cannot/ be improved by overall factors in excess of three even
if decimal floating point is not provided?
It's not an issue where improvement can be measured in terms of "[a]
factor in excess of three". The key point is that the financial
community has a commonly occuring need for the numbers, as printed with
a fixed number of decimal places, to add up exactly to the specified
total printed with the same number of decimal places, without roundoff
error. In general that will happen only when using a radix that is a
power of 10. One solution is to use scaled integers, such that an
integer such as 3412 represents a value of 34.12. However, use of scaled
integers complicates programs; a common problem is forgetting to apply
the scale factor, or applying it inappropriately.

.... Since when (and by whom) has there been a declaration that C is
competing (with whom and for what) as a tool for building
commercial applications? Is the term "panacea" being added to the
language definition?
The term "commercial" describes most of the software that has ever been
written in the C language. I suspect you may mean "financial" rather
than "commercial". There's a lot more freeware out there nowadays, but
most programs still have to be paid for.

C has always been meant to be a general-purpose language. That's similar
to "panacea", but not as ambitious. It's not meant to be the ideal
solution for every problem, but it's meant to be an acceptable solution
for a wide variety of problems. It's a low-level language, far closer to
assembly language than many others, but not so low-level as to be
inappropriate for some financial applications.

Given that the floating point radix has never been restricted to
any particular value, you should probably not contract the
language definition at this point by deciding that you've fallen
in love with ten. My sense is that any requirements (other than
the specific radix value, of course) for one radix should also be
in force for all others.

I think you're under the mistaken impression that decimal floating point
is being proposed as a replacement for binary floating point. Such a
mistake would make your criticisms seem more appropriate. My
understanding was that the proposal is to add support for decimal
floating point types, in addition to the default types, not that it
would be a mandatory re-interpretation of them.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Mike Cowlishaw]

Morris Dovey wrote:

I haven't found any references to IBM patents covering decimal
floating point implementations. Does IBM hold and/or have
application(s) pending for such patents? If so, are those patents
sufficiently broad as to exclude other hardware producers from
producing decimal FPUs of equal (or better) performance at equal
(or better) cost?

The only one that I am aware of that directly affects the decimal
formats in the draft IEEE 754 revision is the IBM patent which
covers my Densely Packed Decimal encoding scheme,
described at:

http://www2.hursley.ibm.com/decimal/DPDecimal.html

(This was patented before we considered proposing it for use
in IEEE 754.) IBM has already written the necessary formal
letter to the IEEE stating that this will be Royalty Free for
implementers of the standard (rather than RAND), though
RAND is permitted by IEEE rules. We really want to see
everyone using the new formats!

There are, of course, many patents issued to IBM and
other companies that cover various aspects of floating-point
arithmetic (both binary and decimal). These might constrain
certain methods of implementation, but would not prevent
implementation -- any 'obvious' implementation would not
be covered by patents, and many early patents on decimal
arithmetic have long since expired, in any case.

Mike Cowlishaw
IBM Fellow (Google: Cowlishaw)
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Fergus Henderson]

Keith Thompson <ks***@mib.org> writes:

I think you need another suffix to specify that a literal is decimal:

d_double x = 0.1D;

but forgetting the suffix is likely to be a common subtle error.

Compilers could easily warn about it, though.

--
Fergus Henderson <fj*@cs.mu.oz.au> | "I have always known that the pursuit
The University of Melbourne | of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Fergus Henderson]

"Douglas A. Gwyn" <DA****@null.net> writes:

Thad Smith wrote:

Does a two-tiered system for standardization make sense? Will it work?
Has it been shown to work or fail in other instances?

COBOL had various levels of conformance, and generally all
it accomplished was complication. In practice all implementations
ended up providing all the levels, so what was the point?

Are you sure? If so, how long did it take for this to occur?

The COBOL implementation that I used in my time as a COBOL programmer
(1988-1992), namely ACUCOBOL, did not support all of the optional
features in the COBOL-85 standard. In particular it lacked support for
nested subprograms.

A web search pulled up some documentation for ACUCOBOL-GT, dated >= 1995
(since it refers to Windows 95), which indicates that this is was still
the case then, ten years after the adoption of the COBOL-85 standard.

--
Fergus Henderson <fj*@cs.mu.oz.au> | "I have always known that the pursuit
The University of Melbourne | of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Morris Dovey]

James Kuyper wrote:

Morris Dovey wrote:
....
(Short reminder that I'm an "ordinary programmer" - and not a
language guru [IANAG])

The need for high degrees of precision in computation is not a
new issue and I fail to see how a change in radix will provide a
major improvement.

It's not "high degrees of precision" that are needed. It's a
fairly low degree of precision, but it needs to be provided
exactly, which makes is similar in some ways to requiring
infinite precision.

I'm going to have to think about this statement for a while. I'm
mulling over simple arithmatic operations like 1/3, 1/7, etc.;
and asking myself: "What's improved by performing this operation
in FP-10?" Am I grossly missing the point?

Has WG14 made the decision that the needs of "typical billing
programs" should determine the C language architecture and
associated standards?

Apparantly they've decided that those needs should be considered. Your
use of "determine" is a loaded phrase; taken to it's logical extreme,
your criticism implies that the C standard should never contain any
feature that is needed only by a minority of the users. In fact, most of
C's features are needed only by a minority, especially in the C standard
library. A great many programs make no use of floating point at all,
whether binary or decimal.

Unfair of me. I apologize. I value C as a "tiny" but "rich"
language. I don't worry much about the library (because it's so
easy to expand upon); but feel that the "tiny" and "rich" should
be preserved. In current context, I'd feel very much more at ease
if the change under consideration was to standardize a compiler
switch to produce code using a particular floating point radix;
and perhaps specifying (and requiring) conformance to specific
IEEE standards for each radix supported.

The addition of a decimal floating point type to the C standard
would seem to me burdensome to those who produce compilers for
"small" embedded systems, for example. Fully conforming compilers
are scarce enough already. If the core language becomes
sufficiently bloated, I'm concerned that the standard will become
(or be perceived by implementors as) non-relevant. Note that I'm
/not/ saying that FP-10 wouldn't be useful in embedded systems.

Would anyone care to wager that "the typical billing program"
/cannot/ be improved by overall factors in excess of three even
if decimal floating point is not provided?

It's not an issue where improvement can be measured in terms of "[a]
factor in excess of three". The key point is that the financial
community has a commonly occuring need for the numbers, as printed with
a fixed number of decimal places, to add up exactly to the specified
total printed with the same number of decimal places, without roundoff
error. In general that will happen only when using a radix that is a
power of 10. One solution is to use scaled integers, such that an
integer such as 3412 represents a value of 34.12. However, use of scaled
integers complicates programs; a common problem is forgetting to apply
the scale factor, or applying it inappropriately.

I guess I should have put a smiley on that statement - but I'd
like to respond seriously to your serious response. When PHLX
(The Philadelphia Stock Exchange) switched from fractional prices
to decimal prices in 2000, they switched from scaled integers to
binary floating point. The difficulties you present were examined
and efficient solutions implemented. It was a highly educational
process for all involved since we nearly all "knew" (at the
beginning) that floating point wasn't any good for monetary
values. My discovery was that the problem didn't lie with the
hardware or the format - it lay with the uninformed prejudice of
programmers.
....

Since when (and by whom) has there been a declaration that C is
competing (with whom and for what) as a tool for building
commercial applications? Is the term "panacea" being added to the
language definition? The term "commercial" describes most of the software that has ever been
written in the C language. I suspect you may mean "financial" rather
than "commercial". There's a lot more freeware out there nowadays, but
most programs still have to be paid for.
Yup. I did mean "financial". Sorry for the ambiguity. I'm a bigot
who likes freeware and who likes to be paid for designing and
writing programs (and of late, compiling the paid for code with
freeware compilers.)

What I was reacting to was the notion that the C language is
somehow engaged in a competition for the financial community's
attention. That notion struck me as particularly silly because
the financial community is perfectly aware of C and hasn't (in my
experience) needed to be "sold" on the idea of using it.
C has always been meant to be a general-purpose language. That's similar
to "panacea", but not as ambitious. It's not meant to be the ideal
solution for every problem, but it's meant to be an acceptable solution
for a wide variety of problems. It's a low-level language, far closer to
assembly language than many others, but not so low-level as to be
inappropriate for some financial applications.

/Exactly/ so!
Given that the floating point radix has never been restricted to
any particular value, you should probably not contract the
language definition at this point by deciding that you've fallen
in love with ten. My sense is that any requirements (other than
the specific radix value, of course) for one radix should also be
in force for all others.

I think you're under the mistaken impression that decimal floating point
is being proposed as a replacement for binary floating point. Such a
mistake would make your criticisms seem more appropriate. My
understanding was that the proposal is to add support for decimal
floating point types, in addition to the default types, not that it
would be a mandatory re-interpretation of them.

Never wanting to miss an opportunity to display my considerable
ignorance, why not leave selection of floating point radix a
compile/link option? I've been thinking back over all the
financial code I've ever written/seen and can't think of any
instance where use of more than a single floating point radix
made any sense at all. Why not simply use the type names we
already have?

If there is a strong desire to "marry" a program to a particular
radix, then why not just do so with a

#pragma fp_radix 10

or similar.

(After a break for a cup of coffee and a bit of soul searching) I
think I'm skeptical about the need for additional types rather
than simply being reactionary. I just don't see how a new FPU
architecture "under the covers" necessitates a language change.
--
Morris Dovey
West Des Moines, Iowa USA
C links at http://www.iedu.com/c
Read my lips: The apple doesn't fall far from the tree.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Morris Dovey]

Mike Cowlishaw wrote:

Morris Dovey wrote:

I haven't found any references to IBM patents covering decimal
floating point implementations. Does IBM hold and/or have
application(s) pending for such patents? If so, are those patents
sufficiently broad as to exclude other hardware producers from
producing decimal FPUs of equal (or better) performance at equal
(or better) cost?
The only one that I am aware of that directly affects the decimal
formats in the draft IEEE 754 revision is the IBM patent which
covers my Densely Packed Decimal encoding scheme,
described at:

http://www2.hursley.ibm.com/decimal/DPDecimal.html

(Nice work, by the way)
(This was patented before we considered proposing it for use
in IEEE 754.) IBM has already written the necessary formal
letter to the IEEE stating that this will be Royalty Free for
implementers of the standard (rather than RAND), though
RAND is permitted by IEEE rules. We really want to see
everyone using the new formats!
First class! My personal experience of IBM was that the people in
the labs were generally bright white hats; but that it hasn't
necessarily always been so throughout the remainder of the
corporation. Due diligence would require that the question be
asked regardless of the source of the proposal.
There are, of course, many patents issued to IBM and
other companies that cover various aspects of floating-point
arithmetic (both binary and decimal). These might constrain
certain methods of implementation, but would not prevent
implementation -- any 'obvious' implementation would not
be covered by patents, and many early patents on decimal
arithmetic have long since expired, in any case.

Understood from the outset. I've always thought of IBM as a
patent factory; and that's at least partly why I asked right out
loud. 8-)
--
Morris Dovey
West Des Moines, Iowa USA
C links at http://www.iedu.com/c
Read my lips: The apple doesn't fall far from the tree.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Eric Backus]

"P.J. Plauger" <pj*@dinkumware.com> wrote in message
news:cl****************@plethora.net...

IBM gave an excellent presentation on the need for decimal arithmetic in
a large proportion of calculations being performed these days. (Most tax
and interest laws specify decimal algorithms, which are hard to emulate
correctly with binary.) They also described the implementation being
developed as part of IEEE 754R, the current revision to the venerable
binary floating-point standard. And they informed us that they will be
producing CPUs with this arithmetic implemented in hardware.

I can tell you that both the C and C++ committees were skeptical at
the outset and pretty thoroughly convinced in the end. They've even
agreed to *cooperate* [sic] to ensure that C and C++ remain compatible
in this area.

Is IBM really suggesting that new financial programs be written in C? That
doesn't sound like a very good idea. I can maybe see putting support in
hardware, if this really is a speed bottleneck (which, frankly, I doubt) but
why does a low-level language like C need it? Surely a financial program
would use C++ or something higher level than that, and surely you would have
some standard class that deals with decimal arithmetic in a standard way.
How did they justify wanting to put it into C?

--
Eric Backus
R&D Design Engineer
Agilent Technologies, Inc.
425-356-6010 Tel
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Francis Glassborow]

In article <cl****************@plethora.net>, Morris Dovey
<mr*****@iedu.com> writes

Never wanting to miss an opportunity to display my considerable
ignorance, why not leave selection of floating point radix a
compile/link option? I've been thinking back over all the financial
code I've ever written/seen and can't think of any instance where use
of more than a single floating point radix made any sense at all. Why
not simply use the type names we already have?

WG14 will take time to consider all the options but the proposal from
IBM is for something that is considerably more than just a change of
radix.

The second issue is that tuning math libraries to work effectively
requires a great deal of skill and time. You cannot simply change the
radix and expect everything else to work.

I think that the fact that a total of nearly 100 largely sceptical
'experts' (some C some C++) have decided that they should take (a lot
more) time considering the issues might suggest that there was more to d
o than to just flick a switch for a different radix.
--
Francis Glassborow ACCU
If you are not using up-to-date virus protection you should not be reading
this. Viruses do not just hurt the infected but the whole community.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Douglas A. Gwyn]

Morris Dovey wrote:

The addition of a decimal floating point type to the C standard would
seem to me burdensome to those who produce compilers for "small"
embedded systems, for example.

Naturally it depends on details, but generally speaking it's
a relatively small burden compared to some other areas in
which C99 extended the language. Also, just because a system
is small doesn't mean that decimal floating point isn't
important to it. Some embedded systems would benefit greatly
from better support for this.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Mike Cowlishaw]

Morris Dovey wrote:

The need for high degrees of precision in computation is not a
new issue and I fail to see how a change in radix will provide a
major improvement. It's not "high degrees of precision" that are needed. It's a
fairly low degree of precision, but it needs to be provided
exactly, which makes is similar in some ways to requiring
infinite precision.

I'm going to have to think about this statement for a while. I'm
mulling over simple arithmatic operations like 1/3, 1/7, etc.;
and asking myself: "What's improved by performing this operation
in FP-10?" Am I grossly missing the point?

Perhaps so. Even with those divisions base 10 helps a little,
because the result you get will always be the same as a 'manual'
calculation of the same operation.

But the real benefits are where the results are expected to be
exact, or certain rounding rules must be strictly applied.
See the section 'What problems are caused by using binary floating-point?'
in: http://www2.hursley.ibm.com/decimal/decifaq.html

Would anyone care to wager that "the typical billing program"
/cannot/ be improved by overall factors in excess of three even
if decimal floating point is not provided?

It's not an issue where improvement can be measured in terms of "[a]
factor in excess of three". The key point is that the financial
community has a commonly occuring need for the numbers, as printed
with a fixed number of decimal places, to add up exactly to the
specified total printed with the same number of decimal places,
without roundoff error. In general that will happen only when using
a radix that is a power of 10. One solution is to use scaled
integers, such that an integer such as 3412 represents a value of
34.12. However, use of scaled integers complicates programs; a
common problem is forgetting to apply the scale factor, or applying
it inappropriately.

I guess I should have put a smiley on that statement - but I'd
like to respond seriously to your serious response. When PHLX
(The Philadelphia Stock Exchange) switched from fractional prices
to decimal prices in 2000, they switched from scaled integers to
binary floating point. The difficulties you present were examined
and efficient solutions implemented. It was a highly educational
process for all involved since we nearly all "knew" (at the
beginning) that floating point wasn't any good for monetary
values. My discovery was that the problem didn't lie with the
hardware or the format - it lay with the uninformed prejudice of
programmers.

It is indeed possible, with great care and skilled error analysis, to
use binary floating point for some financial applications (especially
those where no calculation takes place .. numbers are just moved
around). But it is hard and unnecessarily complicated -- and as
soon as the application is modified or maintained, 'accidents' are
just waiting to happen. It's faster (given the hardware), simpler,
and easier to use base-10 arithmetic.
Never wanting to miss an opportunity to display my considerable
ignorance, why not leave selection of floating point radix a
compile/link option? I've been thinking back over all the
financial code I've ever written/seen and can't think of any
instance where use of more than a single floating point radix
made any sense at all. Why not simply use the type names we
already have?

This would mean that one could never have both binary and decimal
FP data in the same program/structure. A pragma which could be used
inside a program would be especially dangerous (consider the
base being switched inside an #include). The entire existing base
of binary FP functions could not be used from a program which
selected base 10.

Mike Cowlishaw
Google: decimal arithmetic
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Mike Cowlishaw]

Eric Backus wrote:

"P.J. Plauger" <pj*@dinkumware.com> wrote in message
news:cl****************@plethora.net...

IBM gave an excellent presentation on the need for decimal
arithmetic in a large proportion of calculations being performed
these days. (Most tax and interest laws specify decimal algorithms,
which are hard to emulate correctly with binary.) They also
described the implementation being developed as part of IEEE 754R,
the current revision to the venerable binary floating-point
standard. And they informed us that they will be producing CPUs with
this arithmetic implemented in hardware.

I can tell you that both the C and C++ committees were skeptical at
the outset and pretty thoroughly convinced in the end. They've even
agreed to *cooperate* [sic] to ensure that C and C++ remain
compatible
in this area.
Is IBM really suggesting that new financial programs be written in C?

Not necessarily -- but remember that the interpreters and compilers
for just about every other language are written in C. Without the
decimal support in C, all these languages would have to switch to
assembler code to access the decimal instructions.
That doesn't sound like a very good idea. I can maybe see putting
support in hardware, if this really is a speed bottleneck (which,
frankly, I doubt)
See, for example, the 'telco' benchmark at:
http://www2.hursley.ibm.com/decimal/telco.html
but why does a low-level language like C need it?
Surely a financial program would use C++ or something higher level
than that, and surely you would have some standard class that deals
with decimal arithmetic in a standard way. How did they justify
wanting to put it into C?

Again: how would one write that class without the primitive
types in the language?

Mike Cowlishaw
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Dan Pop]

In <cl****************@plethora.net> Francis Glassborow <fr*****@robinton.demon.co.uk> writes:

In article <cl****************@plethora.net>, Morris Dovey
<mr*****@iedu.com> writes

Never wanting to miss an opportunity to display my considerable
ignorance, why not leave selection of floating point radix a
compile/link option? I've been thinking back over all the financial
code I've ever written/seen and can't think of any instance where use
of more than a single floating point radix made any sense at all. Why
not simply use the type names we already have?

WG14 will take time to consider all the options but the proposal from
IBM is for something that is considerably more than just a change of
radix.

This is what I've understood from Plauger's post, too, hence my option
for different types and a different standard header. If it were just a
change of radix, while keeping the floating point model of the C standard
unchanged, everything could be left up to the implementor, with no changes
made to the standard.

If, however, the IBM proposal doesn't fit the C floating point model, it
would be sheer insanity to change the latter in order to accomodate the
IBM proposal.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[CBFalconer]

Eric Backus wrote:

"P.J. Plauger" <pj*@dinkumware.com> wrote in message

..... snip ...
I can tell you that both the C and C++ committees were skeptical
at the outset and pretty thoroughly convinced in the end. They've
even agreed to *cooperate* [sic] to ensure that C and C++ remain
compatible in this area.

Is IBM really suggesting that new financial programs be written in
C? That doesn't sound like a very good idea. I can maybe see
putting support in hardware, if this really is a speed bottleneck
(which, frankly, I doubt) but why does a low-level language like C
need it? Surely a financial program would use C++ or something
higher level than that, and surely you would have some standard
class that deals with decimal arithmetic in a standard way. How
did they justify wanting to put it into C?

Many of us reactionary types do not consider C++ an improvement.
Especially when posting in c.l.c, c.l.c.m, c.s.c.

In point of fact even decimal FP will not avoid some of the
problems. Quite some time ago I had a payroll program, written in
Cobol (using decimal arithmetic), which I corrected to do better
rounding (by incorporating guard digits). The results sometimes
disagreed with some employees own calculations, which they rounded
to the penny at each stage. The employees rightly mistrusted all
computer programs, programmers, etc. :-)

I had to remove the guards to quiet the rebellion. There is a
moral here somewhere.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[James Kuyper]

Eric Backus wrote:
....

Is IBM really suggesting that new financial programs be written in C? That
doesn't sound like a very good idea. I can maybe see putting support in
hardware, if this really is a speed bottleneck (which, frankly, I doubt) but
why does a low-level language like C need it? Surely a financial program
would use C++ or something higher level than that, and surely you would have
some standard class that deals with decimal arithmetic in a standard way.
How did they justify wanting to put it into C?

Because not everyone believes that financial programs have to be
high-level.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Richard Bos]

Morris Dovey <mr*****@iedu.com> wrote:

James Kuyper wrote:

It's not "high degrees of precision" that are needed. It's a
fairly low degree of precision, but it needs to be provided
exactly, which makes is similar in some ways to requiring
infinite precision.

I'm going to have to think about this statement for a while. I'm
mulling over simple arithmatic operations like 1/3, 1/7, etc.;
and asking myself: "What's improved by performing this operation
in FP-10?" Am I grossly missing the point?

People enter numbers - especially amounts of money - as decimal, usually
fixed-point numbers, and they expect an exact decimal result.
Mathematically, decimal FP is not really better than binary FP, but
psychologically there's a great deal of difference, since we humans
insist on doing things in powers of ten ourselves and expect the same
from computers.

Richard
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[James Kuyper]

Mike Cowlishaw wrote:

Eric Backus wrote:

....

but why does a low-level language like C need it?
Surely a financial program would use C++ or something higher level
than that, and surely you would have some standard class that deals
with decimal arithmetic in a standard way. How did they justify
wanting to put it into C?

Again: how would one write that class without the primitive
types in the language?

You could do it rather inefficiently, as a wrapper for a scaled integer;
but then, that's precisely the point: it would be very inefficient.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Eric Backus]

"CBFalconer" <cb********@yahoo.com> wrote in message
news:cl****************@plethora.net...

Eric Backus wrote:

Is IBM really suggesting that new financial programs be written in
C? That doesn't sound like a very good idea. I can maybe see
putting support in hardware, if this really is a speed bottleneck
(which, frankly, I doubt) but why does a low-level language like C
need it? Surely a financial program would use C++ or something
higher level than that, and surely you would have some standard
class that deals with decimal arithmetic in a standard way. How
did they justify wanting to put it into C?
Many of us reactionary types do not consider C++ an improvement.
Especially when posting in c.l.c, c.l.c.m, c.s.c.

And I might agree with those reactionary types--note that I didn't claim C++
was an improvement, just that C would probably not be used for a financial
program.
In point of fact even decimal FP will not avoid some of the
problems.

I'm sure that's true.

--
Eric Backus
R&D Design Engineer
Agilent Technologies, Inc.
425-356-6010 Tel
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Eric Backus]

"Mike Cowlishaw" <mf*****@attglobal.net> wrote in message
news:cl****************@plethora.net...

Eric Backus wrote:

Is IBM really suggesting that new financial programs be written in C?

Not necessarily -- but remember that the interpreters and compilers
for just about every other language are written in C. Without the
decimal support in C, all these languages would have to switch to
assembler code to access the decimal instructions.

That doesn't sound like a very good idea. I can maybe see putting
support in hardware, if this really is a speed bottleneck (which,
frankly, I doubt)

See, for example, the 'telco' benchmark at:
http://www2.hursley.ibm.com/decimal/telco.html

First, thanks for posting some real arguments for decimal floating-point, I
hadn't actually seen any posted here yet.

However, as to your telco benchmark:

A. I expect that a real financial application would have to use database
accesses and when reading and writing its data, and would have to deal with
locking the database around critical changes and all that kind of stuff.
Which, I believe, would slow down I/O by at least an order of magnitude, so
I don't expect the decimal math to be the bottleneck in that case.

B. Don't forget Moore's law. It'll be at least, say, 5 years before you
could expect to have decimal floating-point in the C standard. By then,
computer hardware will be an order of magnitude faster, so even if decimal
math is the bottleneck in a real application today, it may not be by then.

If anything, don't the benchmark and the associated decimal floating-point
library you used prove that this *can* be solved without putting the
floating-point into hardware and into C?

but why does a low-level language like C need it?
Surely a financial program would use C++ or something higher level
than that, and surely you would have some standard class that deals
with decimal arithmetic in a standard way. How did they justify
wanting to put it into C?

Again: how would one write that class without the primitive
types in the language?

If I'm correct that you don't need hardware acceleration for this, you write
it using the existing primitive types, like you already have done. If I'm
wrong, I guess you resort to assembly.

Part of my objection to this is because it seems like a need only for one
specific application (very large financial programs). By that same
reasoning, should we build primitives into C for handling digital
signatures, because digital signatures are slow and hardware could be used
to speed them up? Should we add primitives to provide fast access to
high-quality random numbers, because getting good random numbers is a
problem in some kinds of Monte-Carlo simulations? Should we add primitives
for image manipulation, so that you can use C to do high-speed graphics on
today's graphics cards? I'm sure people could make a case for any of those,
but we need to have a really high bar before doing that kind of thing.

--
Eric Backus
R&D Design Engineer
Agilent Technologies, Inc.
425-356-6010 Tel
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Morris Dovey]

Francis Glassborow wrote:

WG14 will take time to consider all the options but the
proposal from IBM is for something that is considerably more
than just a change of radix.
Understood. My interest is in ensuring that C doesn't become a
disjoint collection of 'bumps', both syntactically and functionally.
The second issue is that tuning math libraries to work
effectively requires a great deal of skill and time. You
cannot simply change the radix and expect everything else to
work.
I've written software floating-point libraries and am aware of
this. I do expect that the additional "features" will be
completely consistant with the existing syntax and function.
I think that the fact that a total of nearly 100 largely
sceptical 'experts' (some C some C++) have decided that they
should take (a lot more) time considering the issues might
suggest that there was more to do than to just flick a switch
for a different radix.
Of course it does. I'm acutely aware that while I'm only an
'ordinary user' and not an 'expert', it's at least partly my
responsibility to voice my concerns and ask the questions that
help me be an /informed/ ordinary user.

Dan Pop wrote:
If, however, the IBM proposal doesn't fit the C floating point
model, it would be sheer insanity to change the latter in
order to accomodate the IBM proposal.
Well said, Dan. I heartily agree.

Douglas A. Gwyn wrote:
Naturally it depends on details, but generally speaking it's a
relatively small burden compared to some other areas in which
C99 extended the language. Also, just because a system is
small doesn't mean that decimal floating point isn't important
to it. Some embedded systems would benefit greatly from better
support for this.
I'll take your word on the relative burden sizes; ditto for the
comments regarding /some/ small and embedded systems.

Mike Cowlishaw wrote:
It is indeed possible, with great care and skilled error
analysis, to use binary floating point for some financial
applications (especially those where no calculation takes
place .. numbers are just moved around). But it is hard and
unnecessarily complicated -- and as soon as the application is
modified or maintained, 'accidents' are just waiting to
happen. It's faster (given the hardware), simpler, and easier
to use base-10 arithmetic.
It's even possible to use FP-2 for financial applications where
calculations /do/ take place. Moreover, the need for great care
and skilled error analysis (I think) doesn't go away just because
the calculations are done in FP-10.

"Hard" and "complicated" are relative and subjective and would
seem to have an inverse relationship with "understood". If an
application using FP-10 is not understood by the modifier or
maintainer, then it, too, is an accident about to happen.

I've never had FP-10 hardware so I'll take you at your word
concerning "faster", "simpler", and "easier".
This would mean that one could never have both binary and
decimal FP data in the same program/structure.
True. Would that necessarily be a problem? The only occasions I
can imagine would be (one time) database conversions.

Richard Bos wrote:
People enter numbers - especially amounts of money - as
decimal, usually fixed-point numbers, and they expect an exact
decimal result. Mathematically, decimal FP is not really
better than binary FP, but psychologically there's a great
deal of difference, since we humans insist on doing things in
powers of ten ourselves and expect the same from computers.

I may be just an ordinary programmer; but even so I don't write
user interfaces to input or output monetary amounts in binary,
octal, or hex! The need to do conversions to/from digit
characters remains regardless of the FP radix. I'm not sure I buy
the psychology argument either - do you suppose any normal person
ever wonders about the representation of values inside their
calculator? How about their digital watch or microwave oven?

Questions:

[1] Assuming the standard were changed to include FP-10, will the
compiler producers consider the new standard non-relevant, given
that it covers hardware not now available anywhere in the world?

[2] Assuming availability of conforming compilers, what is the
wisdom of incorporating changes that cannot be used in any
production CPU/FPU on the planet? Are we ready to declare all
current production CPUs obsolete?

[3] What will be the cost of adding a second (if FP-10 doesn't
simply replace FP-2) floating-point processor to all CPUs? I
strongly suspect that most CPUs don't have that much "spare" real
estate; so this will almost certainly mean substantial redesign
of all current CPUs (incorporate additional addressing, bussing,
interrupts, clocking,..,layout,power consumption [my head hurts])

[4] Would the application needs be met by a simpler, more direct
approach? If rounding is a problem, for example, could not logic
be added to current (FP-2,FP-16) FPUs to produce the desired
behaviors?
--
Morris Dovey
West Des Moines, Iowa USA
C links at http://www.iedu.com/c
Read my lips: The apple doesn't fall far from the tree.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Rob Windgassen]

On Sat, 22 Nov 2003 03:04:04 +0000, Eric Backus wrote:

Part of my objection to this is because it seems like a need only for one
specific application (very large financial programs).

You are restricting financial applications to just the financial applications
that you know.
But think for instance about vending machines:
- small footprint, embedded applications
- C often used
- need financial calcalutions for transactions

In the past I have written code for various instantations of this stuff, in C.
I know many others (still) do so.

Rob Windgassen
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Rob Windgassen]

On Sat, 22 Nov 2003 03:04:04 +0000, Eric Backus wrote:

Part of my objection to this is because it seems like a need only for one
specific application (very large financial programs).

You are restricting financial applications to just the financial applications
that you know.
But think for instance about vending machines:
- small footprint, embedded applications
- C often used
- need financial calcalutions for transactions

In the past I have written code for various instantations of this stuff, in C.
I know many others (still) do so.

Rob Windgassen
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Keith Thompson]

"Eric Backus" <er*********@alum.mit.edu> writes:
[...]

If anything, don't the benchmark and the associated decimal floating-point
library you used prove that this *can* be solved without putting the
floating-point into hardware and into C?

I think the relevant question is, will decimal floating-point be
implemented in hardware? If so, and if IBM isn't the only hardware
manufacturer to do it, then C should accomodate it.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
(Note new e-mail address)
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Jerry Feldman]

On 22 Nov 2003 02:16:49 GMT
"Eric Backus" <er*********@alum.mit.edu> wrote:

And I might agree with those reactionary types--note that I didn't
claim C++ was an improvement, just that C would probably not be used
for a financial program.

In point of fact even decimal FP will not avoid some of the
problems.

I'm sure that's true.

While I generally agree. I do think that C++ is more suited to financial
programming, I am aware of many financial systems written in C. Rather
than changing the C language standard floating point, I would prefer a
built-in fixed point type, somewhat similar to the PL/1 fixed type.

--
Jerry Feldman <gaf-nospam-at-blu.org>
Boston Linux and Unix user group
http://www.blu.org PGP key id:C5061EA9
PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Francis Glassborow]

In article <cl****************@plethora.net>, Morris Dovey
<mr*****@iedu.com> writes

Questions:

[1] Assuming the standard were changed to include FP-10, will the
compiler producers consider the new standard non-relevant, given
that it covers hardware not now available anywhere in the world?
I would lay fairly high odds that by the time a TR is completed on this
subject that there will be hardware with direct support for FP-10.

[2] Assuming availability of conforming compilers, what is the
wisdom of incorporating changes that cannot be used in any
production CPU/FPU on the planet? Are we ready to declare all
current production CPUs obsolete?
No, because it will be possible to support the new FP-10 types in
software (just at a serious performance cost)

[3] What will be the cost of adding a second (if FP-10 doesn't
simply replace FP-2) floating-point processor to all CPUs? I
strongly suspect that most CPUs don't have that much "spare" real
estate; so this will almost certainly mean substantial redesign
of all current CPUs (incorporate additional addressing, bussing,
interrupts, clocking,..,layout,power consumption [my head hurts])
Looking at the latest CPUs with multiple pipelines etc. I suspect that
this is an entirely non-issue.

[4] Would the application needs be met by a simpler, more direct
approach? If rounding is a problem, for example, could not logic
be added to current (FP-2,FP-16) FPUs to produce the desired
behaviors?

Much current financial software completely avoids use of the FPU and
does everything via integer arithmetic and fixed point arithmetic. I
think this point is being largely missed. In a way the proposal to
provide FP-10 FPUs is not very different from the inclusion of FPUs in
CPUs to replace the software emulation of FPUs normal throughout most of
the 1980's. I can remember the time when I would elect some form of
fixed point arithmetic in order to avoid the heavy computational costs
of binary floating point. Largely engineering and scientific computing
no longer has to go that route (Remember how dramatic Fractint was in
its performance because it use hand-coded fixed point arithmetic where
possible?) It is now the financial software that largely avoids direct
use of the hardware because it fails to meet their needs.
--
Francis Glassborow ACCU
If you are not using up-to-date virus protection you should not be reading
this. Viruses do not just hurt the infected but the whole community.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Gene Wirchenko]

Jerry Feldman <ga********@blu.org> wrote:

On 22 Nov 2003 02:16:49 GMT
"Eric Backus" <er*********@alum.mit.edu> wrote:

And I might agree with those reactionary types--note that I didn't
claim C++ was an improvement, just that C would probably not be used
for a financial program.

> In point of fact even decimal FP will not avoid some of the
> problems.

I'm sure that's true.

While I generally agree. I do think that C++ is more suited to financial
programming, I am aware of many financial systems written in C. Rather
than changing the C language standard floating point, I would prefer a
built-in fixed point type, somewhat similar to the PL/1 fixed type.

That would be nice, too, but what if you need decimal FLOAT?

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[lawrence.jones]

In comp.std.c Morris Dovey <mr*****@iedu.com> wrote:

Mike Cowlishaw wrote:

This would mean that one could never have both binary and
decimal FP data in the same program/structure.
True. Would that necessarily be a problem? The only occasions I
can imagine would be (one time) database conversions.

Yes, it would be a very big problem. What if the GUI library you want
to use is written with FP-10 and the statistical analysis library you
want to use is written with FP-2? *Those* are the kinds of issues that
will arise and cause the most problems.
[1] Assuming the standard were changed to include FP-10, will the
compiler producers consider the new standard non-relevant, given
that it covers hardware not now available anywhere in the world?

The standard could be changed to accomodate FP-10 without requiring it.
I sincerely doubt that the standard would mandate FP-10 without a broad
concensus among both users and implementors that that was the right
thing to do.

-Larry Jones

It must be sad being a species with so little imagination. -- Calvin
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Thad Smith]

Keith Thompson wrote:

"Eric Backus" <er*********@alum.mit.edu> writes:
[...]

If anything, don't the benchmark and the associated decimal floating-point
library you used prove that this *can* be solved without putting the
floating-point into hardware and into C?

I think the relevant question is, will decimal floating-point be
implemented in hardware? If so, and if IBM isn't the only hardware
manufacturer to do it, then C should accomodate it.

C has a mechanism to accommodate many innovative hardware features -- a
library function. This can be used without changing the language. If
putting direct hardware access into the language is a good idea, how
about C language direct support for hardware interrupts? power down
modes? I'm not suggesting these, just pointing out that new hardware
features are not a adequate reason to change the language.

Thad
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[glen herrmannsfeldt]

Keith Thompson wrote:

"Eric Backus" <er*********@alum.mit.edu> writes:
[...]

If anything, don't the benchmark and the associated decimal floating-point
library you used prove that this *can* be solved without putting the
floating-point into hardware and into C?

I think the relevant question is, will decimal floating-point be
implemented in hardware? If so, and if IBM isn't the only hardware
manufacturer to do it, then C should accomodate it.

It may or may not be relevant, but PL/I has supported FLOAT DECIMAL
since the beginning, even though no implementation that I know of
actually does it with decimal arithmetic. Having the attribute allows
precision to be specified in decimal digits instead of binary bytes.

If an implementation actually did have decimal float hardware, the
attribute is there and ready to use. IBM compilers usually do FIXED
DECIMAL with BCD hardware instructions, though.

-- glen
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Douglas A. Gwyn]

Francis Glassborow wrote:

In article <cl****************@plethora.net>, Morris Dovey
<mr*****@iedu.com> writes

[3] What will be the cost of adding a second (if FP-10 doesn't
simply replace FP-2) floating-point processor to all CPUs? ...

Looking at the latest CPUs with multiple pipelines etc. I suspect that
this is an entirely non-issue.

Actually it would be expensive to add another floating
coprocessor to the silicon, although if done as a mode
(binary/decimal) the cost would be reduced. There are
some who think it likely that either binary or decimal
f.p. (but not both) would be supported by the chip-level
hardware on some platforms. On more "mainframe"-like
platforms it is more likely that both would be supported.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Douglas A. Gwyn]

la************@eds.com wrote:

The standard could be changed to accomodate FP-10 without requiring it.
I sincerely doubt that the standard would mandate FP-10 without a broad
concensus among both users and implementors that that was the right
thing to do.

Note that IEEE/IEC binary floating point has an optional
binding to the C standard, and presumably 754R decimal
floating point could have a similar binding. The generic
support for decimal floating point could be specified so
that both binary and decimal were specifiable by the
programmer, but could be implemented using the same
representation (for non-IEEE/IEC decimal-f.p. platforms),
much as "int" and "long" have the same representation on
many platforms.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Dan Pop]

In <cl****************@plethora.net> ge***@mail.ocis.net (Gene Wirchenko) writes:

That would be nice, too, but what if you need decimal FLOAT?

What for? Given the intrinsic nature of floating point, if the base is
relevant to your application, then you should review the application.

If the ability of representing $3.11 *exactly* is important, simply do all
your computing in pennies and the base used by your floating point
representation no longer matters (only the precision is relevant).

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Hans-Bernhard Broeker]

In comp.lang.c.moderated Eric Backus <er*********@alum.mit.edu> wrote:

Is IBM really suggesting that new financial programs be written in C?
Let me answer this with another question: Would you prefer that they
forever keep being written in COBOL, instead?

Since legal requirements in the financial sector (tax calculations and
such) explicitly require decimal arithmetic and certain rounding
rules, having support for decimal FP in C could help put COBOL to its
long-deserved final sleep.

I'm all for it, _as_long_as_ it doesn't interfere with existing code.
Scientists will insist that behaviour of existing code that does rely
on FP being done in base 2 doesn't change. I.e. there really should
be a set of new types and library support for the guaranteed-decimal
FP. Overlaying the existing ones with base-10 ones isn't a viable
alternative, IMHO. To put it technically: existing code that does
(or should) have a fragment like

#include <float.h>
#if FLT_RADIX != 2
# error Sorry, this program only works in base-2 floating point!
#endif

inside _must_ continue to work, or you'll invoke on your heads the
wrath of the entire scientific community.
why does a low-level language like C need it?

Because it's the common-ground low-level language many other languages
(more precisely: their runtime libraries) are built on top of.

If you view C as "portable assembler", then C should support as many
aspects of assembler programming as remotely possible. CPUs with more
than one base available for floating point operations, or base-10 as
the native one, would be one such aspect that it currently doesn't
handle well.

--
Hans-Bernhard Broeker (br*****@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net