problem with 'double'

[RobertMaas]

Perhaps some future format will represent numbers as a/b instead of
as the current a*2^b

Future?? LISP has had that, namely ratios of integers, for many years.
So instead of typing -0.07 and 0.0175 you type -7/100 and 175/10000.
It would be trivial to write a Java class RatioBigInteger which is
based upon the BigInteger class. You get exact answers if you always
start with ratios of integers such as those, and the only operations
you perform are the four basic ones (+ - * /), but as soon as you do
square root or trigonometric etc. the result can't be represented as
exact ratios of integers so you're stuck again.

IMO, the right thing is to use interval arithmetic. Whenever the answer
can't be expressed exactly in the particular representation, you get an
interval expressing lower and upper bound. These intervals would be
carried through the whole chain of calculations, then when you're ready
to output the final result you can use the bounds to determine how many
digits are accurate enough to be worth printing, or you can do that
plus also represent the next digit by a range. For example, if you
tried to do the 1/3 * 3 calculation, converting to range of decimal
fractions for printing, you'd get successively:
0.3333333333[3..4]
0.9999999999[9..C] (using hexadecimal notation for digits larger than 9)
or if you allowed negative digits (using J K ... for -1 -2 ...):
1.0000000000[J..2]
(Oldtimers may recognize J K ... as Hollerith keypunch codes for zone
minus combined with digit 1 2 ... in same column.)

 

[Filip Larsen]

IMO, the right thing is to use interval arithmetic.

Which, I believe, is supported by the Pentium FPU and perhaps even other
common FPUs as well. In C++ it is fairly easy to make an interval
arithmetic library supported by the FPU, so a Java version shouldn't be
too hard either, although it probably will be platform dependend.


Regards,

 

[Michael Borgwardt]

For many purposes, a fraction based implementation akin to Lisp's
rational numbers would be a reasonable choice. Using 64-bit integers
for numerator and denominator gives plenty of range and precision and
covers most typical program uses of reals.

No, it doesn't. The range would be only a tiny fraction of what can
be (and often is) represented by a floating point number.

 

[Michael Borgwardt]

Perhaps some future format will represent numbers as a/b instead of as
the current a*2^b - or at least as an addition.

Mathematical software like Mathematifcan and Maple (and their predecessors)
have been doing that for decades - in software, of course. Doing it in
hardware would be just plain silly - no advantage for most applicatios,
and a huge slowdown for all.

 

[George Neuner]

No, it doesn't. The range would be only a tiny fraction of what can
be (and often is) represented by a floating point number.

I didn't say it was appropriate for all programs - just for many.
Numerical applications which really need the extended magnitudes of
floating point are a small percentage of all applications.

University studies examining the use of real numbers in actual
programs have shown that they most often represent small magnitude
values which are well within the range of a 64-bit int/int fraction.
IIRC, the consensus was that the vast majority of programs require
number magnitudes no greater than 10^(±9).

The studies I have seen were done in the 1980's - but I don't think
the situation has changed radically since then. If anything, I would
bet that the percentage of numerical programs to all programs is less
today than it was then.

I don't know if any of these old studies are online - you can
certainly find them in back issues of IEEE and ACM transactions.

George

 

[Filip Larsen]

I wrote

In C++ it is fairly easy to make an interval
arithmetic library supported by the FPU, so a Java version shouldn't be
too hard either, although it probably will be platform dependend.

I should have googled before I answered. There is at least one
implementation of interval arithmetic:
http://interval.sourceforge.net/interval/.


Regards,

 

[Roedy Green]

University studies examining the use of real numbers in actual
programs have shown that they most often represent small magnitude
values which are well within the range of a 64-bit int/int fraction.
IIRC, the consensus was that the vast majority of programs require
number magnitudes no greater than 10^(±9).

The main reason for this is we arrange our units of measure so that
is it so.

 

[Tony Morris]

This subject comes up every week or two on the Java newsgroups and

equivalently frequently in every other language newsgroup that I've
followed. While I understand that binary representations of
floating point numbers are more efficient, I wonder if this continual
misunderstanding of floating point suggests that the
default floating point representation for data should be decimal rather
than binary.

http://www.xdweb.net/~dibblego/java/faq/answers.html#q41

 

[George Neuner]

The main reason for this is we arrange our units of measure so that
is it so.

I'm not sure I agree with your assessment in general - it is quite
obviously true of older professionals, but I rather doubt that the
current generation of programmers, having grown up with 32-bit
machines and using languages that (to varying degrees) save them from
their own stupidity, really worry much about scaling units until
something bites them in the ass.

The limits imposed by current desktop/server hardware are really only
limiting to a select few. Scientific and embedded programming ( in a
previous life I did embedded RT for 10 years ) are the only areas
which tend to bump hardware limits on a regular basis and, taken
together, they are a small percentage of all programming.

George

 

[Roedy Green]

I'm not sure I agree with your assessment in general - it is quite
obviously true of older professionals, but I rather doubt that the
current generation of programmers, having grown up with 32-bit
machines and using languages that (to varying degrees) save them from
their own stupidity, really worry much about scaling units until
something bites them in the ass.

I don't mean we scale the units of measure in programs. That is a lost
art. What I mean is the units themselves are designed that
measurements are small numbers, e.g. you measure air pressure in
KiloPascals, rather that say some unit like dynes/cm^2

 

[Iris]

Thank you!!

http://mindprod.com/jgloss/floatingpoint.html
http://mindprod.com/jgloss/gettingstarted.html

 

[Michael Borgwardt]

I didn't say it was appropriate for all programs - just for many.
Numerical applications which really need the extended magnitudes of
floating point are a small percentage of all applications.

So what would those use? Completely different machine instructions than
anyone else? Do you really believe that the benefit of sparing novice
programmers the effort to understand the properties of binary float types
justifies this additional complexity (to say nothing of the performance
implications)?

 

[George Neuner]

So what would those use? Completely different machine instructions than
anyone else? Do you really believe that the benefit of sparing novice
programmers the effort to understand the properties of binary float types
justifies this additional complexity (to say nothing of the performance
implications)?

What's your problem with different instructions?

Every chip made requires different instructions to handle different
data formats ... for load, store and conversion even if it's math and
logic instructions are uniform. On many non-Intel chips, the math and
logic ops actually use different instructions for different formats.
And absolutely none of this matters unless you are programming in
assembler. So I repeat ... What's your problem?

Novices? If they want to pursue programming they had better damn well
learn something about the execution hardware - preferably by reading
the friggin' manuals like the rest of us. I don't believe in
shielding newbies from anything. I *do* believe, however, that there
should be alternatives for people who are either troubled by the
inexactness of binary floating point formats or who, for whatever
reason, must have exact answers.

I once used a mainframe C library that implemented arbitrary precision
fractions based on a power series. It was slow as molasses in
Antarctica, but it was the Right Thing(tm) for calculating the speed
of a snail in light years per second. Many scientists mourned the
passing of the Vaxen which had a 128-bit float format with 112 bits of
mantissa.

Lisp provides exact rational formats which have arbitrary precision if
bignums are used. In Lisp these are all built-in types but Java
already provides BigInteger in java.math so there is no reason not to
offer a rational type also. It might even work better than the Lisp
version on 32-bit machines because Java's native integers are larger
and so fewer uses would have to resort to big numbers.

George

 

[Liz]

I like the RCA 1802 myself.

What's your problem with different instructions?

Every chip made requires different instructions to handle different
data formats ... for load, store and conversion even if it's math and
logic instructions are uniform. On many non-Intel chips, the math and
logic ops actually use different instructions for different formats.
And absolutely none of this matters unless you are programming in
assembler. So I repeat ... What's your problem?

Novices? If they want to pursue programming they had better damn well
learn something about the execution hardware - preferably by reading
the friggin' manuals like the rest of us. I don't believe in
shielding newbies from anything. I *do* believe, however, that there
should be alternatives for people who are either troubled by the
inexactness of binary floating point formats or who, for whatever
reason, must have exact answers.

I once used a mainframe C library that implemented arbitrary precision
fractions based on a power series. It was slow as molasses in
Antarctica, but it was the Right Thing(tm) for calculating the speed
of a snail in light years per second. Many scientists mourned the
passing of the Vaxen which had a 128-bit float format with 112 bits of
mantissa.

Lisp provides exact rational formats which have arbitrary precision if
bignums are used. In Lisp these are all built-in types but Java
already provides BigInteger in java.math so there is no reason not to
offer a rational type also. It might even work better than the Lisp
version on 32-bit machines because Java's native integers are larger
and so fewer uses would have to resort to big numbers.

George

 

[Dale King]

BigDecimal is a scaled representation. What Tim was calling for was
decimal floating point.

Big Decimal is decimal floating point. Floating point is where the numbers
are expressed as

sign * mantissa * base ^ exponent

The difference between double and BigDecimal is that:
- base = 2 for double and base = 10 for BigDecimal
- mantissa is a fixed size for double and can be unbounded for BigDecimal

 

[Dale King]

Not at all. There then becomes no NEED to play silly games to dance
around the problem of imperfect representation.

To call it an imperfect representation implies that there is a "perfect"
representation. I contend that there can be no "perfect" representation that
is finite. Any finite representation will only represent a finite number of
values from the uncountably infinite number of real numbers. Which subset
you choose is fairly arbitrary and I fail to see what makes one particular
subset more perfect than another. There are an infinite number of values
that don't have an exact representation in whatever set you choose.

 

[Dale King]

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

Which looks pretty much like BigDecimal to me.

 

[Dale King]

No, it doesn't. The range would be only a tiny fraction of what can
be (and often is) represented by a floating point number.

Not necessarily. Consider if floating point were combined with fractions.
Floating point is defined as:

sign * mantissa * base ^ exponent

What if that were changed to:

( sign * mantissa * base ^ exponent ) / divisor

The problem with that then is that is inefficient because you have multiple
ways to represent the same number.

Oh, well just thinking out loud here.

 

[Eric Sosman]

To call it an imperfect representation implies that there is a "perfect"
representation. I contend that there can be no "perfect" representation that
is finite. Any finite representation will only represent a finite number of
values from the uncountably infinite number of real numbers. Which subset
you choose is fairly arbitrary and I fail to see what makes one particular
subset more perfect than another. There are an infinite number of values
that don't have an exact representation in whatever set you choose.

Maybe it's time to return to base sixty, which was what the
people who invented floating point used. Even if you simulated
the sexagesimal digits with six binary digits "under the hood,"
the efficiency would be better than 98%. Er, that is, better than
fifty-nine per sixty, or would it be three thousand five hundred
forty-four per thirty-six hundred?

;-)

 

[Gary Labowitz]

Maybe it's time to return to base sixty, which was what the
people who invented floating point used. Even if you simulated
the sexagesimal digits with six binary digits "under the hood,"
the efficiency would be better than 98%. Er, that is, better than
fifty-nine per sixty, or would it be three thousand five hundred
forty-four per thirty-six hundred?

I can't believe you believe that. No matter what base you use there is still
a finite representation of an infinite domain. Mapping the finite to the
infinite will always be inexact. At the point where the smallest change
possible to distinguish two numbers is made using the finite representation
there are still an infinite number of real values between those two finite
representations which cannot be expressed using the finite notation. If you
had a base gadzillion it still couldn't represent the set of real numbers.
It could represent a lot of them but would still not be able to represent an
infinity of them (alpha-zero).
I bet the scientists at Sun know that.