next topic »

[on:]

The documentation says that the size of a double is 8 bytes (http://www.arduino.cc/en/Reference/Double) but I find that in a C program, sizeof(double) returns 4. Is the documentation in error?

Joe

[Reply #1 on:]

Good catch. I'll fix it.

[Reply #2 on:]

The documentation says that the size of a double is 8 bytes (http://www.arduino.cc/en/Reference/Double) but I find that in a C program, sizeof(double) returns 4.

Isn't a double that is the same size as a float (i.e. a single) a contradiction in terms?

Does this issue highlight that the Arduino doesn't actually have a double?

I'm basing this on:

Single precision floating point is an IEEE 754 standard for encoding floating point numbers that uses 4 bytes. (reference)

and

Double precision floating point is an IEEE 754 standard for encoding floating point numbers that uses 8 bytes. (reference)

I concede I may be missing some nuance here, but it seems a little counter-intuitive to me currently.

--Phil.

[Reply #3 on:]

Hmmm, so according to the avr-libc FAQ:

char is 8 bits, int is 16 bits, long is 32 bits, long long is 64 bits, float and double are 32 bits (this is the only supported floating point format)

I think I'm going to stop trying to fit my head around this now, but I guess that means that floats are doubles in this instance but doesn't that mean that doubles are actually IEEE754 single precision floats..? I guess that's more a question for the avr-libc folks.

I can't help thinking something about this needs to be documented. :-/

--Phil.

[Reply #4 on:]

The C standard doesn't actually specify a size for data types, only some relative requirements (e.g. a double can't be smaller than a float).  Most modern 32 bit CPUs use a 64-bit double, but an AVR isn't really a modern 32-bit CPU.  For example, int is only 16 bits in Arduino, as opposed to 32 bits on most computers.

[Reply #5 on:]

The wiki article quoted on single-precision vs double-precision is pretty questionable.  There are/were many floating point formats in use that are not IEEE754 based that still had what they called single and double precision.

[Reply #6 on:]

The wiki article quoted on single-precision vs double-precision is pretty questionable.  There are/were many floating point formats in use that are not IEEE754 based that still had what they called single and double precision.

All real number representation in a computer architecture is based on some arbitrary use of bits to represent the exponent and the base (is that how you say it in English?  My college education was in Spanish), so I think it is possible to have single and double floating point numbers represented using the same 32-bits.  Just for double, dedicate more bits to represent the exponent and that is it.  I hope my memory is not failing this time...

[Reply #7 on:]

This test program reports the same thing for each type so that seems to indicate there isn't any processing that's different with the types, so the takehome is that  AVR float == double ?

/* Float double test */

float vfloat;                            
double vdouble;                        

long start;
void setup()
{
 Serial.begin(9600);
}
 
void loop()
{
   start = millis();
  for(vfloat = 0 ; vfloat <= 100000; vfloat+=.111) // fade in (from min to max)
  {
 
  }
  
  Serial.println(millis() - start);
  
  start = millis();
  for(vdouble = 0 ; vdouble <= 100000; vdouble+=.111) // fade in (from min to max)
  {
  }
  
  Serial.println(millis() - start);
}

[Reply #8 on:]

Confirmed, in winavr float == double (source: "WinAVR / gccavr does not support doubles, in other words: double is considered as float" in http://www.avrfreaks.net/wiki/index.php/Documentation:AVR_Float) and also from the maintainer of avr-libc: http://www.avrfreaks.net/index.php?module=PNphpBB2&file=viewtopic&t=50770&highlight=

[Reply #9 on:]

I think it is possible to have single and double floating point numbers represented using the same 32-bits.  Just for double, dedicate more bits to represent the exponent and that is it.

Double precision usually means more precision, or more "significant digits", which is more bits in the mantissa rather than in the exponent.  There's an interesting table of various FP formats here: http://home.earthlink.net/~mrob/pub/math/floatformats.html
You could theoretically expand the RANGE of a FP number by increasing either the exponent bits or exponent base (I imagine the latter has an "interesting" effect on precision...

I remember having a particularly educational experience with FP numbers back in college, trying to do my physics homework on the local mainframes in APL.  Seems the PDP-10 FP format had a max/min exponent of +/-38 (as does IEEE 754 single precision, apparently), which was not at all enough to handle hbar².  Annoying.  (how may ways does this paragraph give away my age ? :-))

[Reply #10 on:]

the PDP-10 FP format had a max/min exponent of +/-38

Oops.  the format had a range of 10^+/-38.  The exponent was actually 8bits (7bits + sign) and 2¹²⁸ is approximately 10³⁸