Arithmetic

[Jim Janney]

Actually, I've yet to see a financial package that used anything but
integers for currency amounts, so in USD or GBP the amounts would be
cents and pence respectively the decimal point is just interpolated when
the value is displayed, e.g. in COBOL:

01 AMOUNT COMP SYNC PIC S9(9).
01 DISP_AMOUNT PIC -Z,ZZZ,ZZ9.99 BLANK WHEN ZERO.

MOVE 150 TO AMOUNT.
.....
MOVE AMOUNT TO DISP-AMOUNT.

would output the amount, $1.50 held internally as 150 cents, as
" 1.50"

Interest and exchange rates, etc. is quite another matter: whether they
are held internally as fixed point decimal or floating point is entirely
up to the system designer and the compiler writer.

In practice there's a strong tendency toward whatever the programming
language makes convenient. The system I work with was originally
written in RPG. RPG strongly favors fixed point decimal, and that's
what is mostly used in the RPG code and in the data base, for example
9 digits with 2 decimal places for dollar and cent amounts and 5
digits with 5 decimal places for interest rates. In Java we have USD
and Percent classes that use BigDecimal internally.

Using integers for currency amounts is numerically sound but relies on
the programmer to keep track of the decimal position. Not bad for
small projects but it would make me nervous for larger projects where
there's significant turnover among the programmers.

 

[Martin Gregorie]

In practice there's a strong tendency toward whatever the programming
language makes convenient. The system I work with was originally
written in RPG. RPG strongly favors fixed point decimal, and that's
what is mostly used in the RPG code and in the data base, for example 9
digits with 2 decimal places for dollar and cent amounts and 5 digits
with 5 decimal places for interest rates. In Java we have USD and
Percent classes that use BigDecimal internally.

Actually, that owes as much to the prehistoric IBM hardware that RPG was
initially designed for - most small S/360s, e.g. 360/30 and smaller (S/3,
S36, etc.) had no floating point available and many of them could only do
BCD arithmetic. The really small ones used a 4 bit serial adder.
Performance was terrible but there was no hardware limit to the number of
digits that composed a number.

Before that very few, if any, general purpose 2nd generation mainframes
had floating point hardware - that was restricted to 'scientific'
computers such as the Elliott 503.

Using integers for currency amounts is numerically sound but relies on
the programmer to keep track of the decimal position. Not bad for small
projects but it would make me nervous for larger projects where there's
significant turnover among the programmers.

That is a good reason for holding currency amounts in binary pence/cents
rather than fixed decimal dollars/pounds - decimal tracking is only an
issue when amounts are being converted to/from strings - tracking the
decimal point is largely a non-issue, even in assembler.

COBOL solved the problem another way - even when I first used it in 1969
the language had a COPY verb to pull in record definitions, etc. from a
source code library. There's no real equivalent in other languages and
certainly not in Java - COPY falls somewhere between C's use of #define
in header files and a decent macrogenerator.

 

[Lew]

Numerical analysis is not a big CS topic.

Big enough to represent an entire undergraduate semester in the computer
science curriculum when I was at university. Big enough to be the source of
questions such as the OP's time and time again. Big enough to spawn dozens,
perhaps hundreds of papers since the dawn of computer science, and cause a
major redesign in floating-point hardware across the industry a few decades
ago. Big enough to have 'strictfp' be a keyword in the Java language. Big
enough to make it into popular entertainment media. (The notion of skimming
"roundoff error" from financial transactions into a secret account has been
the key of fictional crime sprees in movies and novels.)

You're right in one sense, Arne. Numerical analysis isn't a big CS topic,
it's a *huge* CS topic.

 

[blmblm]

This is a FAQ. Don't they teach numerical analysis at university any
more? What's with the education system these days anyway?

A data point, for what it's worth ....

At the school where I teach undergrad CS courses, numerical
analysis is still taught, but the courses that focus on it
are not required parts of the CS degree programs. I suspect
that this is typical, and the reason for it has to do with
the ever-increasing number of things that *someone* thinks
All! Computer! Scientists! Must! Know! I'm inclined to think that
dropping the requirement for a whole course in numerical analysis
is not unreasonable, but then some of the basic information
(enough to answer the OP's question) should be folded into some
other course. *What* other course, though .... I usually mention
it any programming course in which it might be relevant, but I'm
not sure everyone does.

(I'd agree with your later post that numerical analysis is a big CS
topic, and one worthy of study, but I'm not sure I'd agree with a
claim that it's something all programmers should be experts about.)

 

[Lew]

(I'd agree with your later post that numerical analysis is a big CS
topic, and one worthy of study, but I'm not sure I'd agree with a
claim that it's something all programmers should be experts about.)

Huh? I never said that.

 

[blmblm]

Huh? I never said that.

And where did I say you did .... Sorry if I wasn't clear:

I originally wrote "I'm not sure I'd agree that it's something ....",
realized that I wasn't sure you'd made such a claim, rewrote,
and .... Still didn't communicate clearly! I guess I should have
said explicitly that I wasn't saying you were making such a claim,
rather than hoping that saying "a claim" rather than "your claim"
would convey my intended meaning. "Whatever"?

 

[Lew]

And where did I say you did .... Sorry if I wasn't clear:

And where did I say you said I said that?

The problem is the implications in the syntactic structure "I agree with you
that ..., but ...", whereby the "but" clause sets up a straw man for the
other's argument.

I originally wrote "I'm not sure I'd agree that it's something ....",
realized that I wasn't sure you'd made such a claim, rewrote,
and .... Still didn't communicate clearly! I guess I should have
said explicitly that I wasn't saying you were making such a claim,
rather than hoping that saying "a claim" rather than "your claim"
would convey my intended meaning. "Whatever"?

You're absolutely right. I guess I should've said explicitly that I wasn't
saying you were making such a claim, rather than hoping that saying "I never
said that" would convey that I was speaking to others who might misconstrue.
Once again,

I actually did understand that you'd made the "a claim" vs. "your claim"
distinction, albeit after I pressed SEND, but figured that if I could
misunderstand so could others, and chose to wait to press the point home once
you inevitably corrected me.

My concern is that computer programmers know the basics. That's all I've
advocated in this discussion. One need not be a numerical analysis expert to
be aware that floating-point representation is an approximation to real
numbers, and that Boris Punk's "missing" 111111s are a consequence of limited
precision. One does need at least to be aware of those limits to lay claim to
be any kind of professional programmer.

Kudos to you as an educator that you take the care to include fundamentals
such as the limitations of floating point in your curricula. Would that all
educators were so diligent!

 

[Martin Gregorie]

Kudos to you as an educator that you take the care to include
fundamentals such as the limitations of floating point in your
curricula. Would that all educators were so diligent!

My first language was and Eliott 503 dialect of Algol 60 . I don't
remember being taught much detail about real number representation other
than the number of significant digits it could handle (The Eliott used
single word values in a 39 bit word) and that real number representatin
wasn't always exact, but I do remember it being hammered in that equality
should *never* be used to compare real numbers: instead compare the
difference with a domain-specific limiting value. If both values are
known to have the same sign then "if a - b < 0.005 then ....;" would be
appropriate if the values are known to be accurate to two decimal places.

I'd always assumed that all programmers are taught this much about
dealing with floating point numbers regardless of what the language calls
the type(s). Am I wrong in this assumption?

 

[Jim Janney]

Actually, that owes as much to the prehistoric IBM hardware that RPG was
initially designed for - most small S/360s, e.g. 360/30 and smaller (S/3,
S36, etc.) had no floating point available and many of them could only do
BCD arithmetic. The really small ones used a 4 bit serial adder.
Performance was terrible but there was no hardware limit to the number of
digits that composed a number.

Before that very few, if any, general purpose 2nd generation mainframes
had floating point hardware - that was restricted to 'scientific'
computers such as the Elliott 503.

That is a good reason for holding currency amounts in binary pence/cents
rather than fixed decimal dollars/pounds - decimal tracking is only an
issue when amounts are being converted to/from strings - tracking the
decimal point is largely a non-issue, even in assembler.

COBOL solved the problem another way - even when I first used it in 1969
the language had a COPY verb to pull in record definitions, etc. from a
source code library. There's no real equivalent in other languages and
certainly not in Java - COPY falls somewhere between C's use of #define
in header files and a decent macrogenerator.

Yes, some of the code was originally written for the S/36. But the
reason these implemented decimal arithmetic in hardware is that they
were designed for the business and financial market.

 

[Arved Sandstrom]

My first language was and Eliott 503 dialect of Algol 60 . I don't
remember being taught much detail about real number representation other
than the number of significant digits it could handle (The Eliott used
single word values in a 39 bit word) and that real number representatin
wasn't always exact, but I do remember it being hammered in that equality
should *never* be used to compare real numbers: instead compare the
difference with a domain-specific limiting value. If both values are
known to have the same sign then "if a - b < 0.005 then ....;" would be
appropriate if the values are known to be accurate to two decimal places.

I'd always assumed that all programmers are taught this much about
dealing with floating point numbers regardless of what the language calls
the type(s). Am I wrong in this assumption?

It's not real numbers and equality that's problematic - it's their
floating point representation. If I undertook to carry out all my real
number computations with rational numbers then at any point I'd be able
to decide in my program whether real number a was equal to real number b.

AHS

 

[Martin Gregorie]

Yes, some of the code was originally written for the S/36.

System/360 actually. RPG first appeared on the bottom 360/20 and 360/30
models as a COBOL alternative in the late '60s. The improved RPG II
appeared on System/3 when it was launched 5 years later and was ported to
the S/32, S/34 and S/36 when these were launched. RPG III came in with
the S/38, later re-launched with 2nd gen hardware as the AS/400.

But the reason these implemented decimal arithmetic in hardware is
that they were designed for the business and financial market.

They could have equally well implemented normal integer arithmetic and
ignored BCD. The contemporary ICL 1900 series of mainframes did just that.
Both ranges omitted hardware floating point from the smaller machines or,
at best, made it an optional extra.

The bigger S/360s had 32 bit registers but the 'small business computers'
only used BCD arithmetic because implementing a 4 bit register + carry
ALU and only supporting BCD number representation was so much cheaper
than building a 32 bit ALU given the primitive integrated circuits of the
era.

 

[Martin Gregorie]

It's not real numbers and equality that's problematic - it's their
floating point representation. If I undertook to carry out all my real
number computations with rational numbers then at any point I'd be able
to decide in my program whether real number a was equal to real number
b.

Are you including the decimal expansion of rational numbers? If so, how
does this exact comparison deal with the set with terminal repeating
sequences given a fixed and/or limited length representation?

It seems to me that the rationals with terminal repeating sequences are
as problematic to handle as irrationals unless your numeric
representation can recognise and deal with the repeating unit explicitly,
e.g. you'd hold the mantissa as a prefix and a repeating unit.

 

[Arved Sandstrom]

Are you including the decimal expansion of rational numbers? If so, how
does this exact comparison deal with the set with terminal repeating
sequences given a fixed and/or limited length representation?

It seems to me that the rationals with terminal repeating sequences are
as problematic to handle as irrationals unless your numeric
representation can recognise and deal with the repeating unit explicitly,
e.g. you'd hold the mantissa as a prefix and a repeating unit.

No, I was not including the decimal expansion of rational numbers. It's
obvious that any given problem might not, from a practical standpoint,
admit of using rational numbers for all computations, in which case we
descend into the morass of questions such as the ones you just posed.

As you likely gathered my point was rather more simple. You probably
_were_ told way back when that it's not kosher to compare real numbers
for equality; in fact, so was I on more than one occasion. But it's
perfectly OK to compare real numbers for equality; what we can't so
easily do is compare their floating-point representations that way(*),
and so we often end up doing what you mentioned, using a limiting value.
I'm not convinced that all the people who pass this advice on understand
the difference between real numbers and their representations.

Rational numbers happen to be a good example of how we can actually work
with real numbers in computer programs, and not worry about
representation inaccuracies. To the extent, alluded to above, that other
considerations such as performance don't intrude.

AHS

** And I don't doubt that you're perfectly aware of the difference.

 

[Eric Sosman]

It's not real numbers and equality that's problematic - it's their
floating point representation. If I undertook to carry out all my real
number computations with rational numbers then at any point I'd be able
to decide in my program whether real number a was equal to real number b.

Rational representations can handle all the rational numbers,
yes (up to the point where the numerator and denominator grow too
big for virtual memory). But as I'm sure you're aware, the rational
numbers are an infinitesimal proportion of the real numbers: the log
of almost any number is irrational, and if the log isn't then the
number itself is (with one exception). Square roots, other roots,
trig functions, ... You've calculated the radius of that circle
there with perfect rational precision; what's its area?

Even with rational representations, many calculations will
eventually force you to accept the same kinds of approximations as
you must with floating-point. Rationals do have the advantage that
the precision is (usually) variable, in contrast to the fixed
precision of floating-point, so you can calculate the area of that
circle to a great number of digits if you wish. But it will take
you quite a long time to calculate the area exactly (there was a
Star Trek episode that hinged on essentially this point).

 

[Arved Sandstrom]

Rational representations can handle all the rational numbers,
yes (up to the point where the numerator and denominator grow too
big for virtual memory). But as I'm sure you're aware, the rational
numbers are an infinitesimal proportion of the real numbers: the log
of almost any number is irrational, and if the log isn't then the
number itself is (with one exception). Square roots, other roots,
trig functions, ... You've calculated the radius of that circle
there with perfect rational precision; what's its area?

Even with rational representations, many calculations will
eventually force you to accept the same kinds of approximations as
you must with floating-point. Rationals do have the advantage that
the precision is (usually) variable, in contrast to the fixed
precision of floating-point, so you can calculate the area of that
circle to a great number of digits if you wish. But it will take
you quite a long time to calculate the area exactly (there was a
Star Trek episode that hinged on essentially this point).

Absolutely, Eric, no argument from me. I believe that you and I and
Martin are all on the same sheet of music here. I know that Martin was
incorrectly told that real numbers cannot be compared for equality
because I've been told the same thing; using rational numbers is just
one example of how we can use reals in programming and compare for
equality. There's no question that actually using rationals is not
practical in many if not most applications. Although I'd argue that they
could be used more frequently than they currently seem to be.

AHS

 

[Dr J R Stockton]

In comp.lang.java.programmer message <[email protected]

, Sat, 10 Jul 2010 17:51:58, Martin Gregorie <martin@address-in-

sig.invalid> posted:

I'd always assumed that all programmers are taught this much about

==================================================

dealing with floating point numbers regardless of what the language calls
the type(s). Am I wrong in this assumption?

=

Yes, since the underlined part seems not to be true in practice.

 

[Arne Vajhøj]

Paid programmers?
Yes.

Computer science is knowing how information from the
real world can be represented within the constraints of a computer.
It's the basis for knowing what you're doing while programming.

Floating point is not important at all in computer science.

It is more the natural/social/medical sciences and engineering that uses
computers that have to deal with them.

And the question about how to represent information in a computer
belongs to electrical engineering.

Arne

 

[Arved Sandstrom]

Paid programmers? Computer science is knowing how information from the
real world can be represented within the constraints of a computer.
It's the basis for knowing what you're doing while programming.

Not only are there programmers who literally never use floating point,
but I'll wager that the huge majority of programmers who do use floating
point (which latter group is probably the majority of programmers
anyway) do _not_ understand the nuances. IOW, the majority of all
programmers couldn't tell you the 3 parts of an IEEE 754 floating point
representation if you held them up at gunpoint.

Most programmers who use floating point - so, most programmers - get by
without understanding the nuances. They hear one way or the other that
money shouldn't be handled with floats or doubles, so without really
understanding the details they use integer or fixed decimals instead,
and don't get bit. Of those who do use floating point for problems other
than money, not too many of them are doing scientific work, so the odds
are that while their use of FP is uninformed, most of them will scrape
by with just the occasional bug that simply disappears into the morass
of hundreds of other bugs that their team has in their defect-reporting
system anyway.

We can bemoan this ignorance, but it's simply another category of
ignorance that you can add to all the others that are possessed by
average "programmers" today.

AHS