Data type: Float Point or Double?

[dimensionless]

I'm sure one could find a reason to use any data type. There is a lot you can do with just intergers. I do, however, have a computational physics book and they make wide use of the type double. Could float be used as an alternative?

[ComputerGeek]

I'm sure one could find a reason to use any data type. There is a lot you can do with just intergers. I do, however, have a computational physics book and they make wide use of the type double. Could float be used as an alternative?

The reason that they use Double is because in order to get the best accuracy, using double precision floating point values allows them use significant digit calculations with the smallest loss of precision due to rounding as possible.

Float would be fine for a home work problem, but I would not use it when calculating vectors on a trip to mars.

[jim mcnamara]

Languages have limits on their implementations of data types.
In C the "#include <limits.h>" brings in defined values that tell you how much precision a datatype has.

Number of accurate digits in floating point from HP UX (UNIX) C:

FLT_DIG 6 digits of precision
DBL_DIG 15 digits of precision

Which would you rather have when it takes no more CPU (with a floating point processor) to do "double" math or "float" math operations?

[chroot]

Jim,

Different compilers, in fact, regard the types "float" and "double" differently. On most compilers, floats are 4 bytes and doubles are 8 bytes.

Also, double-precision arithmetic is certainly slower than single-precision arithmetic. Modern processors have vector-math units (MMX, SSE, etc.), the use of which is scheduled by your compiler. You can do twice as many single-precision operations per unit time as double-precision operations with these vector-math units.

- Warren

[jim mcnamara]

chroot -

I disagree with your statement that double precision is always slower than single. If your model were correct everywhere, the following assembler sequences would never occur.

HPUX V-class PA-RISC boxes preferentially use double precision FP
operations, because they are more efficient. I've been on other platforms
where this is also true. Here is a concrete HPUX 11.00 example.

Consider some C code compiled with cc -S myfile.c -DTYPE=<float or double, see below> to create ASM:


#include <math.h>
/* TYPE defined by -DTYPE=float or -DTYPE=double */
TYPE process(TYPE a, TYPE b)
{
TYPE tmp=a;
tmp -=.05;
tmp*=.5;
tmp+=b;
if ( fabs(a+b)>0.) tmp/=(a+b);
return tmp;
}


On HPUX V-class, PA-RISC boxes, when compiled with -DTYPE=double
This is the assember produced when the compiler is dealing with double datatypes,
I put some *'s in front of one area of interest. Note there are no FCNV calls,
and all FP operations (FMPY FSUB, etc) are on double precision FP numbers.

process
.PROC
.CALLINFO CALLER,FRAME=16,SAVE_RP,ARGS_SAVED,ORDERING_AWARE
.ENTRY
STW %r2,-20(%r30) ;offset 0x0
LDO 64(%r30),%r30 ;offset 0x4
* FSTD %fr5,-104(%r30) ;offset 0x8
* FSTD %fr7,-112(%r30) ;offset 0xc
* FLDD -104(%r30),%fr4 ;offset 0x10
* FSTD %fr4,-56(%r30) ;offset 0x14
* FLDD -56(%r30),%fr5 ;offset 0x18
* LDIL LR'S$6$process,%r1 ;offset 0x1c
* FLDD RR'S$6$process(%r1),%fr6 ;offset 0x20
* FSUB,DBL %fr5,%fr6,%fr7 ;offset 0x24
FSTD %fr7,-56(%r30) ;offset 0x28
FLDD -56(%r30),%fr8 ;offset 0x2c
LDIL LR'S$6$process,%r31 ;offset 0x30
FLDD RR'S$6$process+8(%r31),%fr9 ;offset 0x34
FMPY,DBL %fr8,%fr9,%fr10 ;offset 0x38
FSTD %fr10,-56(%r30) ;offset 0x3c
FLDD -56(%r30),%fr11 ;offset 0x40
FLDD -112(%r30),%fr22 ;offset 0x44
FADD,DBL %fr11,%fr22,%fr23 ;offset 0x48
FSTD %fr23,-56(%r30) ;offset 0x4c
FLDD -104(%r30),%fr24 ;offset 0x50
FLDD -112(%r30),%fr25 ;offset 0x54
FADD,DBL %fr24,%fr25,%fr5 ;offset 0x58
LDIL L'fabs,%r31 ;offset 0x5c
.CALL ARGW0=FR,ARGW1=FU,RTNVAL=FU ;fpin=105;fpout=104;
BE,L R'fabs(%sr4,%r31),%r31 ;offset 0x60
COPY %r31,%r2 ;offset 0x64
FCPY,DBL %fr0,%fr26 ;offset 0x68
FCMP,DBL,> %fr4,%fr26 ;offset 0x6c
FTEST ;offset 0x70
B,N $00000001 ;offset 0x74
FLDD -104(%r30),%fr27 ;offset 0x78
FLDD -112(%r30),%fr28 ;offset 0x7c
FADD,DBL %fr27,%fr28,%fr29 ;offset 0x80
FLDD -56(%r30),%fr30 ;offset 0x84
FDIV,DBL %fr30,%fr29,%fr31 ;offset 0x88
.............. code omitted to save space.


When the same code is compiled with -DTYPE=float, note that FCNV is called to convert float to double, and FMPY and FSUB use double precision. FADD does not.

process
.PROC
.CALLINFO CALLER,FRAME=16,SAVE_RP,ARGS_SAVED,ORDERING_AWARE
.ENTRY
STW %r2,-20(%r30) ;offset 0x0
LDO 64(%r30),%r30 ;offset 0x4
* FSTW %fr4L,-100(%r30) ;offset 0x8
* FSTW %fr5L,-104(%r30) ;offset 0xc
* FLDW -100(%r30),%fr4L ;offset 0x10
* FSTW %fr4L,-56(%r30) ;offset 0x14
* FLDW -56(%r30),%fr4R ;offset 0x18
* FCNV,SGL,DBL %fr4R,%fr4 ;offset 0x1c
* LDIL LR'S$6$process,%r1 ;offset 0x20
* FLDD RR'S$6$process(%r1),%fr5 ;offset 0x24
* FSUB,DBL %fr4,%fr5,%fr6 ;offset 0x28
* FCNV,DBL,SGL %fr6,%fr5L ;offset 0x2c
FSTW %fr5L,-56(%r30) ;offset 0x30
FLDW -56(%r30),%fr5R ;offset 0x34
FCNV,SGL,DBL %fr5R,%fr7 ;offset 0x38
LDIL LR'S$6$process,%r31 ;offset 0x3c
FLDD RR'S$6$process+8(%r31),%fr8 ;offset 0x40
FMPY,DBL %fr7,%fr8,%fr9 ;offset 0x44
FCNV,DBL,SGL %fr9,%fr6L ;offset 0x48
FSTW %fr6L,-56(%r30) ;offset 0x4c
FLDW -56(%r30),%fr6R ;offset 0x50
FLDW -104(%r30),%fr7L ;offset 0x54
FADD,SGL %fr6R,%fr7L,%fr7R ;offset 0x58
FSTW %fr7R,-56(%r30) ;offset 0x5c
FLDW -100(%r30),%fr8L ;offset 0x60
FLDW -104(%r30),%fr8R ;offset 0x64
FADD,SGL %fr8L,%fr8R,%fr9L ;offset 0x68
FCNV,SGL,DBL %fr9L,%fr5 ;offset 0x6c
LDIL L'fabs,%r31 ;offset 0x70
.CALL ARGW0=FR,ARGW1=FU,RTNVAL=FU ;fpin=105;fpout=104;
BE,L R'fabs(%sr4,%r31),%r31 ;offset 0x74
COPY %r31,%r2 ;offset 0x78
FCPY,DBL %fr0,%fr10 ;offset 0x7c
FCMP,DBL,> %fr4,%fr10 ;offset 0x80
FTEST ;offset 0x84
B,N $00000001 ;offset 0x88
............. code omitted
Please notice that floats are converted to doubles (FCNV mnemonic is float convert)
before most arithmetic operations on floats.

[chroot]

Jim,

I never said double-precision is always slower than single-precision. I just took offense to your statement that single-precision is never faster than double-precision. I don't have much experience with the PA-RISC instruction set, but, on many processors, under many conditions, single-precision is indeed faster than double-precision.

- Warren