This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Why does this subtraction not equal zero?
I just came across a weird situation. Why is below code not returning 0? Instead it's returning a very small negative number.
<cfset x = 5448.10-3311.23-2136.87>
<cfoutput>x=#x#</cfoutput>
Above code will output: x=4.54747350886E-013
I ran above code both in CF9 and CF10 with the same results.
Any help is greatly appreciated.
<cfset x = PrecisionEvaluate(5448.10-3311.23-2136.87)>
<cfoutput>x=#x#</cfoutput>
Doc for PrecisionEvaluate():
http://help.adobe.com/en_US/ColdFusion/9.0/CFMLRef/WSc3ff6d0ea77859461172e0811cbec22c24-7fd9.html
As others have stated it is Floating point accuracy related. I just wanted to point out a resolution if you are trying to get a reasonable result
<cfset x1 = 5448.19-3311.23-2136.87 />
<cfset x2 = numberformat(x1, "9.99") />
<cfoutput>x1=#x1#<br />x2=#x2#</cfoutput>
Result
x1=0.0899999999997
x2=0.09
The numberformat function will round the number to the specified decimal place when given mask.
Related
This question already has answers here:
What exactly is the "as-if" rule?
(3 answers)
Closed 3 years ago.
My actual concern is about what happens if I write an expression that causes the assignment of a value to a variable, in which the value I want to assign has already been stored.
For Example:
#include <stdio.h>
int main(void)
{
int var = 1;
printf("The actual value of var is %d",var);
var = 1; // What happens exactly if I bring in this expression?
// Does it rewrite the memory?
return 0;
}
Does it rewrite the value of 1 to var in the memory and is this causing longer run-time?
Or does it just seemingly skip the assignment command anyhow?
I´ve searched for an exact answer but I couldn't find one inside questions already made here, as well as not in C99 at my sight.
The question is for C and C++, as I work with both and I didn´t want to make the same question twice. If the answer between those two alternatives, please mention which language is in focus.
Let's try that here:
As you can see, this compiler reassigns the value. The var = 1; statement translates to a mov instruction. Now let's try that with a higher optimization level:
Now the var = 1; doesn't translate to any assembly. It has been optimized away. Even the int var = 1; has been optimized away, the value of 1 is now hardcoded for that printf call.
Generally it depends on the compiler, the options, the language and possibly lots of other things. Nowadays a modern compiler will often optimize such code, but if you want to be sure, you should always try it yourself.
Closed. This question is not reproducible or was caused by typos. It is not currently accepting answers.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Closed 3 years ago.
Improve this question
In C I put in a big number, like 1e-12, in float data and add 1. It's gave me a correct answer.
In C++ I made the same, but when I add 1 to 1e-12, it returns me 1.
float a = 1e-12;
std::cout << "The number is : " << a + 1 << std::endl;
Output:
The number is: 1
I don't have any error messages. The program just returns the wrong result.
(!! 1e-12 + 1 is not equal to 1!!)
Compilers by default take some short-cuts when doing floating-point math. (They typically have a command-line switch to enforce the rules)
In this case, the rule is that the compiler should store the double value 1e-12 as a float in a, and then, in the output statement, add 1 to the stored value.
The optimization is probably that one of the compilers never stored the value; instead, it added 1 to the double value 1e-12. With the higher precision initial value there are more low bits in the fraction part, and that will affect the result of adding 1.
So the results can be different, depending on how the compiler treats those values.
That's just handwaving, though; if this is really important to you, look at the machine code that the compiler generates in both cases to see what's being done differently.
This question already has answers here:
Best practices for circular shift (rotate) operations in C++
(16 answers)
Closed 9 years ago.
I need to do a 3 bit left end around rotation in C++.
So far I have:
A[i] = (A[i] << 3)|(A[i] >> 5);
A is an unsigned char array.
Is this correct? If not how can I fix it? Also what is the best way to test and see if this is correct?
Thanks
Looks fine to me.
If you really want to test it, work out a bunch of inputs and outputs by hand and check your program produces them.
Or devise another method that you're absolutely sure will produce results (eg convert unsigned char to binary string, rotate the string, convert back to unsigned char) and compare the two against all 256 possible inputs.
This question already has answers here:
C: How to wrap a float to the interval [-pi, pi)
(15 answers)
Closed 9 years ago.
I'm wondering if it's possible to define a custom data type which can only take a value between -3.1415926535897932 and 3.1415926535897931.
The idea is that a value below or above the range would automatically "wrap-around", eliminating the need to write code to do the conversion and also eliminating the possibility of error somewhere.
Yes it is possible. In the method that sets the value check to see if it outside the limits and if so do whatever operation you want to do to force it to be inside the limits. fmod is one good choice for operation.
This question already has an answer here:
Stopping the debugger when a NaN floating point number is produced
(1 answer)
Closed 7 years ago.
Is there a simple way to check a C++ code in a debugger for the very first appearance of a NaN value?
The answer is given here: https://stackoverflow.com/a/5394095/1326595
Just include
#include <fenv.h>
and than add the following line to the code:
feenableexcept(FE_INVALID | FE_OVERFLOW);
The debugger is than able to capture the signal and shows the very first occurrence of a NaN.
By IEEE standard the following condition is false for NaN's:
val == val
and you could use it to trigger assert or software breakpoint, but beware of compiler optimizations. Probably, in debug build it would not get optimized away
You can put an assert(val >= 0 || val <= 0) to catch a NaN