Is there any reason for this data type nightmare?
Hardly a "nightmare". In most cases the conversion happens automatically.
Many Arduinos (e.g. all AVR-type) don't even support type double, and merely substitute "float" for "double".
What's units and data types you considered as "nightmare"?
radians ?
float?
double?
Yeah; on AVR Arduinos, "float" and "double" are the same thing (32bit floating point)
With 32bit CPUs, both parameter and return value will be a 64-bit "double" (unless you use sinf()/etc)
Note that while the 32bit CPUs default to 64bit doubles for most math functions, they don't have any HW support for 64bit doubles, and using the default behavior will result in significantly slower code (ESPECIALLY on the CPUs that DO have 32bit HW floating point.)
You may be interested in this discussion.
1 Like
is the issue that trig functions normally operate on angles expressed as radians and not degrees? (see wiki radian)
I thought the issue was using double one place and float in the other.
So
Sloppy to zero editing. Which seems largely to be a lost art.
a7
1 Like
Radians is OK, but a function which takes a float argument and returns a double value is strange, especially when used on an STM32 M4 CPU (like on Arduino GIGA) as the FPU on the M4 ist 32bit wide. So a function with this behavior would trigger lots of unnecessary type conversions.
Herbert
Then you should look up what the exact prototype is for the function on that platform.
I'd think most implicit conversions are handled by the compiler with little to no run-time penalty.
This is true for constants but not if variables are used. Those need to be converted during runtime.
Ok, then I'll go back to my suggestion from that same post:
IMO, the Arduino Language Reference is too dumbed-down to be really useful. Go to the source code and look at the function prototypes. Then you'll know for sure.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.