-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Just a quick question. What exactly is the difference between
Floating point integers and normal integers?

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.2 - not licensed for commercial use: www.pgp.com

iQA/AwUBPx8oNyGLC8LJMtEeEQJ3WQCdHvE7Xle3PqjgubT0gHTiDJ WykNYAn1ne
qCy9IVu/jSutQ7WoohfJzQQ1
=pFVE
-----END PGP SIGNATURE-----

Rayden <Rayd3n@nospam.bellsouth.net> writes:

Floating point numbers aren't necessarily integers. That's the
essential fact.
--
"There's only one thing that will make them stop hating you.
And that's being so good at what you do that they can't ignore you.
I told them you were the best. Now you damn well better be."
--Orson Scott Card, _Ender's Game_

Ben Pfaff <blp@cs.stanford.edu> wrote in
news:87vfts3gxt.fsf@pfaff.Stanford.EDU:

Another essential fact is that all integers that can be represented
on a computer can be represented exactly while floating point numbers
are approximations.

Floating point numbers can be used to represent a wider range of values
than normal integers on a computer. The difference is that you loose
some precision in the extremes.

For instance, a float on many systems produces 9 decimal digits of
precision and has a dynamic range of -1.0E38 to 1.0E38. What do you
notice here? A float with the range specified above can represent
the value

1000000000000

It cannot represent the value

1000000000001

It does not have enough digits of precision. Only the first 9 digits
are significant. Anything after that is simply an approximation filled
with 0's.

This leads to an interesting discussion about the appropriateness of
using floating point numbers for financial calculations. As long as the
financial calculations can be accurately represented by a float the
answer is YES. When the numbers get very very large the answer is NO.

This is the reason that most computer systems and languages support
at least two sizes of floating point types. On 32 bit processors the
larger floating point type provides 15 decimal digits and has a
dynamic range of -1.0E308 to 1.-E308. The larger floating point
representation does handle most financial and scientific calculations
very well.

Some languages provide another kind of numeric type as a partial
solution to the problem. This other type is often called a decimal
or fixed decimal type. Such a type represents all values with a fixed
number of digits to the right of the radix (or decimal) point.

Fixed decimal types solve another problem related to floating point
types and financial calculations, the rounding problems.

What is the floating point value obtained when you calculate 3% of
100? The answer is 3.33333333. Most currencies do not have valid
values below the second digit to the right of the radix point. The
extra digits cannot be paid to an account, if this is interest
earned. Where should they be placed? Ignoring them causes a ledger
to go out of balance. The problem is amplified with volume. How much
money extra is indicated when this calculation is performed for
100000 accounts? The answer is A LOT.

Fixed decimal values always result in calculations to the exact
precision requested. For instance, if you defined a fixed decimal
type with two digits to the right of the radix, the result of
the calculation of 3% of 100 is always 3.33
No extra digits are laying about to muddle the calculation.

Jim Rogers

Rayden <Rayd3n@nospam.bellsouth.net> wrote in message news:<wzFTa.10748$h9.7254@fe04.atl2.webusenet.com> ...

In addition to reading Jim's response, and if you want to explore this
further, consider reading

"What Every Computer Scientist Should Know About Floating-Point
Arithmetic" by David Goldberg, widely reprinted on the web.

James Rogers wrote:

I suppose the parallel is that "all floating point values that can be
represented on a computer can be represented exactly" as well. It's
tautological. Yes, floating point can approximate many values more
closely than most integer representations. On many systems floating
point can also exactly represent more integers than the largest native
integer size.

When I want to work with integers that are slightly larger than the
largest support integer type, I often use long double because on my
compiler it can exactly represent a larger range of integers.

Extra precision "muddling" the results? I would say in those cases the
result of each transaction is rounded to the nearest penny. Pennies
then are the relevant unit, not dollars (Euro's, etc.).

Thad

billg-usenet@bacchae.f9.co.uk.invalid (Bill Godfrey) wrote in message news:<20030724065234.213$a7@newsreader.com>...
You are correct. The math does not correctly support my point.
A more supportive value would be the using a simple interest
rate of 5.875%.

Thanks for the correction.

Jim Rogers

Thad Smith <thadsmith@acm.org> wrote in news:3F2008A2.A901FB2F@acm.org:

Your parallel is not true. Not all floating point values that can be
represented on a computer can be represented exactly. Remember, the
computer stores the value internally as a binary pattern. There is no
exact binary representation for the decimal value 0.1. The result is
an endlessly repeating value, something like the value of PI in
decimal.

This does work, within some limits. Even a double fails to exactly
represent very large integers.

Extra precision muddles the values because the extra precision has no
intrinsic meaning. If the smallest unit of a currency is represented by
the second digit to the right of the radix, any digits following that one
represent approximation errors.

It is true that you can round a floating point to two decimal places. The
problem occurs during calculations. You cannot round in the middle of a
calculation. The extra digits do skew the results. After several
compound calculations floating point values can be seriously in error.
Rounding an erroneous value often does not improve the results.

Fixed decimal types eliminate the rounding problems, resulting in
consistently correct values when the number of decimal places for the
result is known a-priori.

Fixed decimal types are not a panacea. They cannot always replace a
floating point type. However, if you want to calculate the interest
on the U.S. National debt to the penny you want to use a fixed point
type. A double precision floating point type will not work properly
for that task.

Jim Rogers

James Rogers wrote:
that and it is represented exactly in binary. Of course the decimal 0.1
cannot be represented exactly in binary because of the reasons you
state.
ability of a floating point representation to represent an integer
exactly is the width of the mantissa. On my machine (and I suspect
yours) double is 64 bits and the mantissa is 53 bits wide. So double can
represent exactly integers in the range of +- 2**53-1 which looks like
this...

9,007,199,254,740,991

which would satisfy my 'very large integer' quite nicely.
decimal places? Usually what you are doing is representing the binary in
decimal notation, itself flawed, and then rounding the notation to fit
the format. This does not round the floating point number at all.

--
Joe Wright mailto:joewwright@earthlink.net
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

Joe Wright <joewwright@earthlink.net> wrote in
news:3F20812B.40D5@earthlink.net:

Interesting. If you use Java you are stuck with an IEEE floating point
representation, no matter what your computer implements under the
covers. A double in Java always has the following range:

-4.94065645842146533e-324 thru
1.79769313486231570e308

A Java double is always implemented as a 64-bit floating point
number. Note that the Java double has 18 decimal digits of
precision.

Yes, and it still clearly has limits to its ability to properly
represent integers. You are better off using all 64 bits as an
integer value to represent a somewhat larger integer.

Remember, all data in your computer is stored as binary data.
Most humans are much more comfortable dealing with decimal numbers
than with binary numbers. This is particularly true when dealing with
real numbers as opposed to integers. Representing a binary value in
decimal notation is not flawed. It is exactly what the human user
wants and needs. Representing a floating point number as a binary
value is flawed. Very few users will accept such a representation.

Humans will want the values rounded to their understanding
of numbers. That means the values will be rounded to some power of
10 (decimal).

Rounding can be done at the point of output, or it can be done to
a stored value at the end of computation. The former does not
modified the stored binary value. The latter does.

Jim Rogers

James Rogers wrote:

Yes, if you have that available. For a compiler that I used, it
supported 16 and 32-bit integers, 32, 64, and 80 bit floating point, the
last with 64 bits of mantissa, allowing a much larger range of exact
integer representation that the native integer types. Standard C now
has 64 bit ints and of course there are multiple precision packages, but
for the 33-64 bit situation, the double / long double worked nicely,
assuming that I was careful in knowing when the integer was exactly
represented.

True, you can exactly represent any binary value in a finite number of
decimal digits.

A floating point number is one which can be expressed in a floating
point format. As such, it can be represented exactly as a binary
number, assuming the normal power of two exponent.

Perhaps you mean that representing a _real number_ as a binary value is
flawed. Certainly you can't exactly represent all real values with a
floating point format. So what? You can't exactly represent all real
values as a finite decimal number, either fixed or floating point.

Fixed point computations definitely have value. I have used non-integer
fixed point arithmetic to advantage. Floating point computation can
also be used well when you understand the strengths and weaknesses.

That's why we have conversion routines. ;-)

That's why conversion routines can round.

Thad

James Rogers wrote:

(Very, very small interjection: pi is transcendental--its digits
never repeat; decimal 0.1 repeats its sequence when expressed in
binary; both never terminate. (This problem exists for all number
bases wrt fractions.))

Sometimes "banker's rounding" helps that situation. (Banker's
rounding rounds the "cusp" up or down depending on whether the
number is odd or even.)

However, I agree that floating point numbers are a poor choice
for currency calculations. MS has a Currency data type that is
fairly handy. It's 64-bits, fixed-point, scaled by 10,000, has
15 digits to the left of the dp, 4 to the right. It has a range
of -922,337,203,685,477.5808 to 922,337,203,685,477.5807 .

If I were writing a financial program, I'd probably create a
"money" class of some type and keep all 'to-the-penny' rounding
stuff hidden inside.

--
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL |
|_____________________________________________|___ ____________________|