next topic »

[on:]

There have been a number posts indicating that people are unclear about the difference between a float and a double ( for example http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1230603646/0#9).

 I suggest that a statement is added to both entries saying that float and double are identical on the arduino.

FYI, here is the reference to float and double being 32 bits in the compiler user manual: http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_reg_usage  (see data types)

[Reply #1 on:]

It might be good to issue a warning or error if double is used while arduino ide is doing its own "pre-processing".  Documentation is fine and all, but a smart tool is arguably better from an easy to use perspective.

[Reply #2 on:]

The standard math.h (and other traditional libraries) use the double data type all over the place.  Longtime C experts are just as much a constituency as those who only know of C because their Christmas Arduino happens to use it.  The issue is not to try to rid the platform of mention of double, but to make the documentation clear that it is no different from the float data type.

[Reply #3 on:]

Yes, float and double are both perfectly valid data types on the Arduino. Like many C data types, they have different implementations on different platforms - it's the job of good documentation to make the implementation (and its implications) clear.

[Reply #4 on:]

I think you guys are approaching this from a C developers perspective.  What I'm saying is that instead of trying to make hard core C programmers out of arduinites, make something friendlier instead.  

Yes there are uses of double outside a user script, I am talking about the ones in the script.  double does you very little good there and in fact causes folks to trip up because its behavior is unexpected (regardless of where it is documented).  The arduino pre-processor can check for it and issue a warning.  It would be the nice thing to do.

Edit, or better yet, help implement a real double.
http://www.mail-archive.com/avr-libc-dev@nongnu.org/msg03052.html

[Reply #5 on:]

Hi dcb, I am all for making the user experience friendlier, but I don't think pre-processor warnings are a friendly way of providing information to non-programmers.

A good solution would be to implement an 8 bit double. But there would still need to be good documentation explaining the difference between a float and double so the user understood the trade-offs.

In the mean time, It should be easy to add a sentence to the Arduino reference clarifying that float and double are the same on the Arduino. Perhaps add that the double is there so that external code using doubles will compile,  but note that if the code was not written for the avr GCC compiler there may be a loss of accuracy.

[Reply #6 on:]

Perhaps this thread isn't the correct forum, but I'm not sure we are talking about the same pre-processor, or even what format the warning would present itself.  Nonetheless the fake double was a hack from decades ago, and all but forgotten about except in microcontroller land.  

Yes please lets document its suckiness, but ideally we should not leave it at that.

[Reply #7 on:]

I'm not sure we are talking about the same pre-processor

Please do say more about how you would provide friendly user warnings. The idea of clear and helpful hints being presented to users does appeal,  but I am not aware of a mechanism for providing this. Did you have something in mind?

[Reply #8 on:]

Just adding float support to a sketch adds about 2KB of program space.  That's all the implementations of float=float+float, float=float*float, float=float/float, etc.

If you add a real 64-bit double type and support, at minimum:

   (1) write double=double+double (etc.) operators,
   (2) write a double-to-float and a float-to-double cast converter,
   (3) fix any runtime library errors that assumed a specific sizeof(),
   (4) accept much slower computations in double as an 8bit engine chugs through twice as many compute stages,
   (5) recall that the C language prefers promotion to double over float when operands differ,
   (6) recall that the standard C runtime library prefers double over float arguments.

Maybe when everyone has an ATmega5128 at 1GHz, or Arduino goes to a floating coprocessor solution, all this makes sense.

[Reply #9 on:]

The avr guys have been looking for volunteers to make a double happen, I don't think you need a hyperbolic 1ghz mega512 to make use of it either.

But if you wanted to entertain having arduino intervene and have a framework for detecting more common errors then perhaps:

1. create a type/identifier for the warnings (i.e. 0001, use of doubles in a script).

2.  have the arduino preprocessor (the thing that figures out what #include statements to add), also scan for such warnings and pitfalls.  It would detect variables being declared as doubles or methods using doubles within the script itself in this case, don't care about libraries at the moment.

3. display a list of any warnings at compile time, and of course create the option to ignore a particular type of warning next time.  It would be nice if the warning could link to the source code that caused the error and a link to open a browser window to a more detailed web page to explain the situation better.

[Reply #10 on:]

dcb, I agree that adding smart and friendly compile time messages to the Arduino would be a nice thing to do and I would think the considerable amount of effort to implement it would be worthwhile if you can harness the necessary skills to define and code it.  Were you volunteering to drive an initiative to make this happen?

[Reply #11 on:]

I'd like to see it discussed a bit further.  I don't mind working on it, technically it isn't that challenging, a lot of the pieces are already in place.  But need to hash out what exactly "it" is before spending too much time on it, and get some buy-in from the core folks that it isn't pre-destined for the circular file.  

But the impetus goes away if there is an 8 byte double, which I think is a better solution in this particular instance, and that is in all probability a task better suited to your skill set than mine.

[Reply #12 on:]

OK there's the new docs, comments welcome.

The powers that be sometimes fret when this much information is put into the hands of Arduino users, so of course they are subject to change.

PaulB