problem with 'double'

[Andrew Thompson]

I can't believe you believe that.

I suspect you missed the ' ;-) '
at the bottom.

 

[Roedy Green]

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.

If the internal form used for computation exactly match the form used
for representation, in some sense it is perfect.

People are used to the problem of 1/3 being inexact, but not 1/10.

You can't get away from the fact some fractions are inexact, but you
can get away from unexpected ones being inexact.

 

[Liz]

that -0.0525
is


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

Well, on the IBM 360/370 series, base = 16.

 

[Liz]

If the internal form used for computation exactly match the form used
for representation, in some sense it is perfect.

People are used to the problem of 1/3 being inexact, but not 1/10.

But this is only because you don't have 3 fingers, you have 10 fingers.
If you had 3 fingers it would be exact.

 

[Roedy Green]

But this is only because you don't have 3 fingers, you have 10 fingers.
If you had 3 fingers it would be exact.

My math prof suggested we use a prime number as base, to disabuse
people of the notions common fractions should have exact
representations.

People most naturally use base 12 numbers -- the dozen, because it has
so many factors to divide it up. Also notice the number 16 showing up
as a natural base with 16 ounces to a pound. In ancient times 60 and
360 showed up because it approximates the number of days in a year.

Martians use a base 16 system. See
http://mindprod.com/jgloss/inwords.html

 

[Liz]

My math prof suggested we use a prime number as base, to disabuse
people of the notions common fractions should have exact
representations.

People most naturally use base 12 numbers -- the dozen, because it has
so many factors to divide it up. Also notice the number 16 showing up
as a natural base with 16 ounces to a pound. In ancient times 60 and
360 showed up because it approximates the number of days in a year.

Martians use a base 16 system. See
http://mindprod.com/jgloss/inwords.html

But, Roedy, can you figure out why women like to count to 20 but men like
to count to 21?

 

[John B. Matthews]

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).

Perhaps you meant aleph-null, the cardinality of the rationals,
among other things.

If we used base pi, would the ratio of a circle's circumference
to its diameter be 10?

John

 

[Roedy Green]

But, Roedy, can you figure out why women like to count to 20 but men like
to count to 21?

I saw a documentary a little while ago that showed how some primitive
group counted by using various body parts, each number had a
corresponding body part gesture.

they also counted forearm, upper arm etc.

 

[Gary Labowitz]

Perhaps you meant aleph-null, the cardinality of the rationals,
among other things.

Of course. Thanks.

If we used base pi, would the ratio of a circle's circumference
to its diameter be 10?

I give up. Would it?

 

[Liz]

Yes, of course.

Of course. Thanks.


I give up. Would it?

 

[Liz]

good one ;-)

I saw a documentary a little while ago that showed how some primitive
group counted by using various body parts, each number had a
corresponding body part gesture.

they also counted forearm, upper arm etc.

 

[Roedy Green]

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

sign * mantissa * base ^ exponent

Not quite. floating point handles the scale stuff for you
automatically. BigDecimal handles it semi-automatically.


BigDecimal keeps accumplating extra precision unless you tell it to
stop. Floating point keeps roughly the same precision all the time.

 

[George Neuner]

I saw a documentary a little while ago that showed how some primitive
group counted by using various body parts, each number had a
corresponding body part gesture.

There once was a primitive tribe whose number system is based on the
number of legs on a dog. They would count "one", "two", "three",
"doggy", then "doggy-one", "doggy-two", etc. So what was "doggy"
squared? "One houndred" ... of course.

George

 

[Eric Sosman]

I can't believe you believe that.

You snipped the smiley ...

On a more serious note, one salient argument against
bases greater than two is the "wobbling precision" problem,
best known from the experience with the IBM System/360's
base-sixteen floating point. A floating-point fraction
is normalized when its leading digit is non-zero -- but
in base sixteen, that leading digit can be anything from
1 through F, a spread of three bits' worth. Because of
the "leading digits are usually small" phenomenon, the
four bits of the "average" leading hex digit contribute
only about 2.5 bits' worth of information to the number's
value; 37% of the bits are "wasted."

Base 10 suffers the same problem to a smaller degree:
a decimal digit is equivalent to about 3.3 bits but the
"average" leading decimal digit has only about 1.8 bits'
worth of significance, for 34% "waste." My tongue-in-
cheek suggestion of using the Babylonians' base sixty
underpinned with six bits would "waste" about 42% of the
information in the "average" leading digit.

(Take all these calculations with a grain of salt;
there's more hand-waving than rigor behind them. They're
an attempt to point out one of the disadvantages of non-
binary floating point, not to measure the disadvantages
in a truly precise way.)

 

[Liz]

You snipped the smiley ...

On a more serious note, one salient argument against
bases greater than two is the "wobbling precision" problem,
best known from the experience with the IBM System/360's
base-sixteen floating point. A floating-point fraction
is normalized when its leading digit is non-zero -- but

Not true, base 16 does not require the leading bit to be zero,
BUT IT IS NORMALIZED. Your opinion may vary.

 

[Eric Sosman]

Not true, base 16 does not require the leading bit to be zero,
BUT IT IS NORMALIZED. Your opinion may vary.

I don't understand your objection. I did not say
that the leading bit is required to be zero, but that
the leading *digit* (hexadecimal) has to be *non*-zero
in a normalized floating-point number.

It is, of course, possible to work with unnormalized
numbers, and the System/360 has/had factilities to do so.
However, this can only reduce the fraction's precision,
not increase it, by forcing low-order digits "off the end"
to make space for the high-order zeroes.

 

[Liz]

sorry, i read your stuff too fast
so many words, so little time

 

[Dale King]

Not quite. floating point handles the scale stuff for you
automatically. BigDecimal handles it semi-automatically.


BigDecimal keeps accumplating extra precision unless you tell it to
stop. Floating point keeps roughly the same precision all the time.

That is a distinction between whether the representation is fixed-size
versus variable-sized. It is floating point in that the location of the
decimal point (or would that be a binary point in binary?) can move.

 

[Liz]

That is a distinction between whether the representation is fixed-size
versus variable-sized. It is floating point in that the location of the
decimal point (or would that be a binary point in binary?) can move.

It doesn't move, the exponent changes instead. In the first implementations
many years ago it moved.

 

[Dale King]

It doesn't move, the exponent changes instead. In the first implementations
many years ago it moved.

Changing the exponent is moving the decimal point! Considering a decimal
floating point example if the mantissa were 123456789 then by changing the
exponent you can have 123456.789 or 123456789000000.0 or 0.00000123456789
all of which would be expressed using the same mantissa and different
exponents where the exponent is controlling where the decimal point goes.