Thread: Short program overflow issue?

10 in base 3 is 3, not 1/3, right?

Yes, but no need to correct that typo in thought since matsp already did so.

Originally Posted by matsp

Actually, floating point numbers consist of a sign, a mantissa (not "base", but number betwee 0.0 and 1.0 expressed in base 2), and an exponent. The actual number is then sign * mantissa * 2 ^ exponent.

To be absolutely precise, the formula is:
(-1^sign)*(1. mantissa)*2^(exponent-bais)

The mantissa thus is a list of significant figures starting at the second. (The first is always 1)

The original was, however, that floating point numbers are raised to an exponent and can therefore not represent as much as a 128-bit number consisting as two 64-bit parts, one for real and one for float.
Floating numbers are approximations, and a computer could very well calculate many, many more digits than ones a float or double can represent.
But even so, I guess that sometimes, there are some numbers that simply cannot be presented by the decimal system.
The solution for that would be to use exact numbers. It's not impossible for computers to do this, but the IEE standard doesn't specify all of this, so the IEE standard falls short, not the computers.

Obviously, there are all sorts of different ways that you CAN represent a number - an in some cases, ALL possible options are approximations (e.g. pi, e, sqrt(2), sqrt(3), and many others).

Of course, you can express pi or e precisely in the form of pi and e respectively - but if you actually want to eventually get a numeric value, you would have to somehow use an approximation of some sort - it may be 4 billion digits long, but it would still be an approximation.

Some numbers could of course be described as fractions (e.g. 1/10, 1/3, and so on) - and you could create a math library that multiplies 1/10 * 2/3 and comes up with 2/30, etc. But again, if you want a single numeric answer, it would have to be approximated.

For most things, the 15-18 digits you can get out of a double is perfectly adequate (in fact, most things are probably precise enough with floats). For example, if you want to figure out if a wall being hit by a car at x meter per second, then 3-4 places would certainly be sufficient to know whether it does or not. If you rely on the fifth place or further down, perhaps you should consider making the wall stronger [if that's what you wanted to know, or drive a bit faster if you are doing a ram-raid]

If you want more precision, then use GMP or some other multiprecision library.

--
Mats

Originally Posted by Elysia

The original was, however, that floating point numbers are raised to an exponent and can therefore not represent as much as a 128-bit number consisting as two 64-bit parts, one for real and one for float.

You mean like a 128 fixed point number with 2^-64 precision?

Floating numbers are approximations, and a computer could very well calculate many, many more digits than ones a float or double can represent.
But even so, I guess that sometimes, there are some numbers that simply cannot be presented by the decimal system.
The solution for that would be to use exact numbers. It's not impossible for computers to do this, but the IEE standard doesn't specify all of this, so the IEE standard falls short, not the computers.

Sure. A variable width number format is possible, one that stores any arbitrary constant arithmetic expression.

Originally Posted by King Mir

You mean like a 128 fixed point number with 2^-64 precision?

I was maybe hinting at:
11111.22222
(Real) (Float)
To separate parts, each stored as two 64-bit numbers.

Originally Posted by Elysia

I was maybe hinting at:
11111.22222
(Real) (Float)
To separate parts, each stored as two 64-bit numbers.

That would be a 128-bit fixed point number with 64-bit integer and 64-bit fraction part.

--
Mats