Is there a bigger data type in c than the double one?

[Daniel Fadlun]

Is there a bigger, mathematical, data type in C than the double (64 bit) one
or the old long double (80 bit)?
I'd like to add precision to my mathematical application, but I can't figure
out how.
Thanks alot.

 

[Gordon Burditt]

Is there a bigger, mathematical, data type in C than the double (64 bit) one

or the old long double (80 bit)?

C doubles are not guaranteed to be 64 bits.
long double is not guaranteed to be 80 bits, and why is it the *OLD*
long double?

Do you have floating-point hardware that uses more than 80 bits
to represent a number?

I'd like to add precision to my mathematical application, but I can't figure
out how.

An int could conceivably be 128 bits, although if your machine has
128-bit operations, the 128-bit integer type is more likely long long.

Gordon L. Burditt

 

[Daniel Fadlun]

C doubles are not guaranteed to be 64 bits.
long double is not guaranteed to be 80 bits, and why is it the *OLD*
long double?

Do you have floating-point hardware that uses more than 80 bits
to represent a number?


An int could conceivably be 128 bits, although if your machine has
128-bit operations, the 128-bit integer type is more likely long long.

Gordon L. Burditt

My machine is a p4 pc using Windowsme;
I would like to add decimals to my results example instead of
17 decimals 30 or 40.

 

[Eric Sosman]

My machine is a p4 pc using Windowsme;
I would like to add decimals to my results example instead of
17 decimals 30 or 40.

That's 100-133 significand bits. H-format numbers on
the VAX could approach the lower end (I don't recall just
how many of its 128 bits were exponent), but I'm not aware
of any C compiler that made use of H-format.

The big question, though, is why do you want so many
digits? What meaning could you assign to a plus-or-minus
one fluctuation in the fortieth decimal place? If you're
trying to calculate the radius of the Universe in Angstrom
units, forty places are far more than you need.

 

[Joe Wright]

That's 100-133 significand bits. H-format numbers on
the VAX could approach the lower end (I don't recall just
how many of its 128 bits were exponent), but I'm not aware
of any C compiler that made use of H-format.

The big question, though, is why do you want so many
digits? What meaning could you assign to a plus-or-minus
one fluctuation in the fortieth decimal place? If you're
trying to calculate the radius of the Universe in Angstrom
units, forty places are far more than you need.

I'll be sorry I did this but..

angstrom
n : a metric unit of length equal to one ten billionth of a
meter (or 0.0001 micron); used to specify wavelengths of
electromagnetic radiation [syn: angstrom unit, A]

...and so 1 meter is 10,000,000,000 angstroms.

The speed of Light is 300 million meters per second. In angstroms we
have 1e10 * 3e8. That would bring us to 3e18 or

3,000,000,000,000,000,000

angstroms per second Light speed. That's only 19 digits but it's
only one second. I'm not sure the 'correct' seconds per year but 60
* 60 * 24 * 365.25 yields 31,557,600 seconds. One Light Year would
be about 9.46728e25 angstroms. Let's say 1e26 angstroms.

Ah now, what is the radius of the Universe? Even if we thought it
could be 10 billion Light Years that would be 1e10 and would be only
1e36 angstroms. Eric is right. 40 digits will be enough.

How many digits can a 128-bit int represent? 40?

I'm right after all. I'm sorry I did this. ;-)

 

[suman kar]

My machine is a p4 pc using Windowsme;
I would like to add decimals to my results example instead of
17 decimals 30 or 40.

Do you know how to implement big big number addition/subtraction etc
using arrays/linked lists(yes, you do the operations by hand).You can
try the
same for figures following the decimal point.So conceptually you will
be adding elements of two arrays.You just keep an index as to where to
put the decimal point while printing.

If you are through with this, or this is way too inefficent, think how
you can
use the array element to hold more than one integer (as in 1 of 3.21).

HTH
Suman.

 

[Neo]

That's 100-133 significand bits. H-format numbers on
the VAX could approach the lower end (I don't recall just
how many of its 128 bits were exponent), but I'm not aware
of any C compiler that made use of H-format.

The big question, though, is why do you want so many
digits? What meaning could you assign to a plus-or-minus
one fluctuation in the fortieth decimal place? If you're
trying to calculate the radius of the Universe in Angstrom
units, forty places are far more than you need.

I'll be sorry I did this but..

angstrom
n : a metric unit of length equal to one ten billionth of a
meter (or 0.0001 micron); used to specify wavelengths of
electromagnetic radiation [syn: angstrom unit, A]

..and so 1 meter is 10,000,000,000 angstroms.

The speed of Light is 300 million meters per second. In angstroms we have
1e10 * 3e8. That would bring us to 3e18 or

3,000,000,000,000,000,000

angstroms per second Light speed. That's only 19 digits but it's only one
second. I'm not sure the 'correct' seconds per year but 60 * 60 * 24 *
365.25 yields 31,557,600 seconds. One Light Year would be about 9.46728e25
angstroms. Let's say 1e26 angstroms.

Ah now, what is the radius of the Universe? Even if we thought it could be
10 billion Light Years that would be 1e10 and would be only 1e36
angstroms. Eric is right. 40 digits will be enough.

How many digits can a 128-bit int represent? 40?

I'm right after all. I'm sorry I did this. ;-)

gud wrk n nice explanation.
-Neo

 

[jacob navia]

Is there a bigger, mathematical, data type in C than the double (64 bit) one
or the old long double (80 bit)?
I'd like to add precision to my mathematical application, but I can't figure
out how.
Thanks alot.

With lcc-win32 you can use the qfloat data type with 350 bits and
approx 100 digits precision.

You use just as the other data types:

qfloat m = 23.3;

qfloat p = exp(m,6.0);

etc

lcc-win32:
http://www.cs.virginia.edu/~lcc-win32

 

[Jack Klein]

That's 100-133 significand bits. H-format numbers on
the VAX could approach the lower end (I don't recall just
how many of its 128 bits were exponent), but I'm not aware
of any C compiler that made use of H-format.

The big question, though, is why do you want so many
digits? What meaning could you assign to a plus-or-minus
one fluctuation in the fortieth decimal place? If you're
trying to calculate the radius of the Universe in Angstrom
units, forty places are far more than you need.

Often the need for high precision is not for either the input data or
output results, but to minimize the inevitable rounding (and other)
errors in complex calculations.

But even for that purpose, 30 to 40 decimal places seems excessive.

 

[dandelion]

How many digits can a 128-bit int represent? 40?

unsigned: floor(log10(2^n)) + 1
signed: floor(log10(2^(n-1))) + 1

Assuming 2's complement is used. Which by the way poses the queston wether
or not 2's complement is mandated/required by the standard or merely by many
CPU's (i assume it's the latter, but the question is a real one *and*
topical)

 

[Dan Pop]

Often the need for high precision is not for either the input data or
output results, but to minimize the inevitable rounding (and other)
errors in complex calculations.

And when this is the case, it is quite often due to an inappropriate
choice of the algorithm. If hardware support for 128 floats has never
been popular, it is because there is precious little *real* demand for
this kind of precision.

Dan

 

[Randy Howard]

With lcc-win32 you can use the qfloat data type with 350 bits and
approx 100 digits precision.

You use just as the other data types:

qfloat m = 23.3;

qfloat p = exp(m,6.0);

etc

lcc-win32:
http://www.cs.virginia.edu/~lcc-win32

Please stop posting unportable "my compiler only" solutions to problems in
c.l.c.

 

[Dave Vandervies]

unsigned: floor(log10(2^n)) + 1
signed: floor(log10(2^(n-1))) + 1

Assuming 2's complement is used.

....or any other sensible way of encoding values in binary form without
using some bits for parity checking or error correcting. Some sensible
forms will have both positive and negative representations for zero,
but otherwise they'll use all 2^n possible bit patterns to represent
different values.
Ten bits is slightly more than three digits (2^10=1024), so without
calculating any logarithms 38-39 digits is a reasonable guess for
128-bit binary.

Which by the way poses the queston wether
or not 2's complement is mandated/required by the standard or merely by many
CPU's (i assume it's the latter, but the question is a real one *and*
topical)

Not required by the standard.

I believe C99 requires one of binary 2s-complement, binary 1s-complement,
or binary sign-magnitude for signed integer types. I'm not sure what
C90 has to say on the subject.


dave

 

[Eric Sosman]

unsigned: floor(log10(2^n)) + 1
signed: floor(log10(2^(n-1))) + 1

Assuming 2's complement is used. Which by the way poses the queston wether
or not 2's complement is mandated/required by the standard or merely by many
CPU's (i assume it's the latter, but the question is a real one *and*
topical)

The Standard permits two's complement, ones' complement,
and signed magnitude representations for negative integers.
Oddly, it *requires* two's complement for exact-width integer
types, if the implementation provides them.

 

[Dan Pop]

With lcc-win32 you can use the qfloat data type with 350 bits and
approx 100 digits precision.

What part of "in C" was too difficult for you to understand?

lcc-win32 is not a C compiler and qfloat is not a C feature.

Your advice is about as topical as "get a VAX/VMS box, rewrite your
code in FORTRAN and use the REAL*16 data type".

Dan

 

[Bart]

lcc-win32 is not a C compiler and qfloat is not a C feature.

Qfloat seems a 'vendor-specific' feature that seems a reasonable thing
to point out, especially as lcc-win32 is free.

Perhaps the OP's compiler has a similar extension. If portability is
not an issue, then go for it.

Otherwise there are BIGNUM-type libraries for arbitrary precision
arithmetic.

The answer to the OP's original question seems to be: No, nothing
beyond double/long double built-in to C. And the advice seems to be:
You don't need that much precision, which I would dispute..

Your advice is about as topical as "get a VAX/VMS box, rewrite your
code in FORTRAN and use the REAL*16 data type".

That's a good idea. Why not float*16 (or C equivalent syntax) in C?


Bart C.

 

[jacob navia]

Qfloat seems a 'vendor-specific' feature that seems a reasonable thing
to point out, especially as lcc-win32 is free.

Perhaps the OP's compiler has a similar extension. If portability is
not an issue, then go for it.

Otherwise there are BIGNUM-type libraries for arbitrary precision
arithmetic.

The answer to the OP's original question seems to be: No, nothing
beyond double/long double built-in to C. And the advice seems to be:
You don't need that much precision, which I would dispute..




That's a good idea. Why not float*16 (or C equivalent syntax) in C?


Bart C.

An example where the extra precision is needed is... printf
To *implement* printf without greater precision than long double
means that round-off errors will creep in when processing the
"%lld" directive.

Most quality implementation of printf include a higher precision
module, see for instance the implementation of gcc.

lcc-win32 uses the qfloat package internally when reading and writing
floating point. The extra time that this uses is justified by
the greater accuracy of the printouts.

 

[sam1967]

Is there a bigger, mathematical, data type in C than the double (64 bit) one
or the old long double (80 bit)?
I'd like to add precision to my mathematical application, but I can't figure
out how.

yes GMP.

Introduction to GNU MP

GNU MP is a portable library written in C for arbitrary precision
arithmetic on integers, rational numbers, and floating-point numbers.
It aims to provide the fastest possible arithmetic for all
applications that need higher precision than is directly supported by
the basic C types.

ftp.gnu.org/gnu/gmp

 

[Michael Mair]

jacob navia wrote:

[snip: Discussion about the topicality of qfloat in lcc-win32 and
the usefulness for the OP]

An example where the extra precision is needed is... printf
To *implement* printf without greater precision than long double
means that round-off errors will creep in when processing the
"%lld" directive.

Most quality implementation of printf include a higher precision
module, see for instance the implementation of gcc.

lcc-win32 uses the qfloat package internally when reading and writing
floating point. The extra time that this uses is justified by
the greater accuracy of the printouts.

You got me there -- what do you need long doubles for when you
want to print a signed long long int? I would have gone for an
efficient "itoa" variant but am aware that compiler builders
want the thing to be fast, and not necessarily conforming...

If there is a nice trick I would be very interested

Apart from that: How bad can the rounding error be when only
working with long doubles? As every binary fraction has a
finite decimal fraction representation, it should be
theoretically possible to print out with a certain
rounding behaviour and no deviation (maybe I am too naive
with respect to the cost).


Cheers
Michael

 

[jacob navia]

jacob navia wrote:


You got me there -- what do you need long doubles for when you
want to print a signed long long int?

Jeeeeez.... Sorry about that. It should have been "%Ld" of course!!!
Excuse me.

Apart from that: How bad can the rounding error be when only
working with long doubles? As every binary fraction has a
finite decimal fraction representation, it should be
theoretically possible to print out with a certain
rounding behaviour and no deviation (maybe I am too naive
with respect to the cost).

The complications arise with sub-normal numbers, i.e. numbers
just below the normalization threshold, typically the results
of underflow. Gcc (and lcc-win32) can print those numbers with
great precision because of the extended precision module, where
the underflow is eliminated.

Other problems arise when trying to print the infamous *last*
digit accurately, because it must be rounded, and not truncated
as it would be staying with the given precision.