06-24-2011 03:07 AM
Dear experts,
I have run into an issue I can't solve myself: the code in debug mode is OK, the code in release mode (32 bit) works OK if compiled with CVI, but it yields wrong results if compiled with clang... (C99 support is enabled)
The relevant code fragment is shown below. My question: Is there an obvious problem with the code, or is there a known issue with clang?
Thanks!
size_t elements;
long double fraction;
fraction = 0.025 * ( long double ) ( elements - 1 );
I have added a printf output to learn about the problem: with CVI I get
elements = 100623
fraction = 2515.55 (that's also the result of my good old HP15C handheld )
with clang the result is:
elements = 100623
fraction = -0.0
Seems like clang doesn't like long double??
Solved! Go to Solution.
06-27-2011 04:56 PM
Hello Wolfgang -
I've reproduced this and filed a bug with id 306206. In the meantime, you should be able to use just 'double', as 'long double' doesn't (to my knowledge) provide any additional resolution on x86 or x64.
NickB
National Instruments
06-28-2011 12:28 AM
Hey Nick,
I am glad it's not me...
Yes, I am aware that right now long double doesn't help - but I have supported the petition for 80 bit precision here and I really hope that it will be implemented in the next version of CVI: While CVI is good in data acquisition, data processing frequently requires intermediate results with higher precision to minimize roundoff errors - hence double may not always be sufficient. So for some applications 80 bits of precision really is something extremely important and I would be delighted to see it implemented in the not too distant future
06-28-2011 12:45 AM
By the way... (I am not experienced in using the preprocessor): Is there a possibility to change all instances of long double to double if clang is chosen as the release compiler?
06-28-2011 10:23 AM
One way to do it would be to define your own type, ie MYLDOUBLE. You could then define it as follows, using a preprocessor symbol the clang compiler exports:
NickB
National Instruments
06-28-2011 10:34 AM
Thanks, Nick! ... but actually this is not what I was looking for... I would prefer having not to touch the code but simply add a line to the include file, something like
This would fulfill my request of leaving the code as is, but it doesn't work, of course... Nevermind, don't worry about it
06-29-2011 09:04 PM
long double is from C89, and does not require that that long double provide any more precision than double or float for that matter.
Intel IEEE 754 math processors use 80 bits internally on 64 bit doubles, the extra 16 bits are used as guard bits to help manage precision during operations.
IEEE 754 - 2008 quadruple precision (128 bits) would make for a good "long double" format if someone wants to update the compiler. It'd be useless on a machine without the quad precision. This link
http://babbage.cs.qc.edu/courses/cs341/IEEE-754references.html
explains the floating point issues fairly well. It claims that the long double type in "C" is IEEE 754 quad precision, not 80 bit extended precision.
I don't know if the newer Intel micros support quad precision or not.
Some languages provide facilities for arbitrary precision artihmetic - Java has BigDecimal, C# the decimal type (128 bits) and BigInteger.
06-29-2011 09:34 PM
Apparently there is no specific HW support in the latest Intel uPs for quad precision. Intel will sell you a SW package that implements quad precision on an intel uP, but it uses binary integers to do it, not 128 bit flt pt HW.
And I could find no indication that Intel intends to do 128 bit flt pt HW in the future.
06-30-2011 12:56 AM
Thank you, Bob, for the background information on long double!
06-30-2011 02:25 PM
My pleasure