I try to compile these lines but it says Compilation error: invalid operands of types 'float' and 'float' to binary 'operator^'
float a=3.75;
float b=6.0;
float c=-3.0;
float negRoot=(-b-sqrt(b^2-(4*a*c)))/(2*a);
float posRoot=(-b+sqrt(b^2-(4*a*c)))/(2*a);
I tried putting periods after all the numbers in it.
You do not want to use the ^ operator, which is the bitwise exclusive OR operator.
C does not have a built-in operator for exponentiation. But the standard library provide some functions:
#include <math.h>
double pow(double x, double y);
float powf(float x, float y);
long double powl(long double x, long double y);
Or as #Steve Summit suggests, just use x * x.
Related
I'm learning C++, and encountering these problems in a simple program, so please help me out.
This is the code
#include<iostream>
using std::cout;
int main()
{ float pie;
pie = (22/7);
cout<<"The Value of Pi(22/7) is "<< pie<<"\n";
return 0;
}
and the output is
The Value of Pi(22/7) is 3
Why is the value of Pi not in decimal?
That's because you're doing integer division.
What you want is really float division:
#include<iostream>
using std::cout;
int main()
{
float pie;
pie = float(22)/7;// 22/(float(7)) is also equivalent
cout<<"The Value of Pi(22/7) is "<< pie<<"\n";
return 0;
}
However, this type conversion: float(variable) or float(value) isn't type safe.
You could have gotten the value you wanted by ensuring that the values you were computing were floating point to begin with as follows:
22.0/7
OR
22/7.0
OR
22.0/7.0
But, that's generally a hassle and will involve that you keep track of all the types you're working with. Thus, the final and best method involves using static_cast:
static_cast<float>(22)/7
OR
22/static_cast<float>(7)
As for why you should use static_cast - see this:
Why use static_cast<int>(x) instead of (int)x?
pie = (22/7);
Here the division is integer division, because both operands are int.
What you intend to do is floating-point division:
pie = (22.0/7);
Here 22.0 is double, so the division becomes floating-point division (even though 7 is still int).
The rule is that IF both operands are integral type (such as int, long, char etc), then it is integer division, ELSE it is floating-point division (i.e when even if a single operand is float or double).
Use:
pi = 22/7.0
If u give the two operands to the / operator as integer then the division performed will be integer division and a float will not be the result.
The build returns -11 error. Removing pow function compiles fine. I'm not using embedded profile.
__kernel void VectorAdd(__global int* a)
{
unsigned int n = get_global_id(0);
a[n] = pow(2, 2);
}
Im catching the error but the string is empty
int err = clBuildProgram(OpenCLProgram, 0, NULL, NULL, NULL, NULL);
if (err != CL_SUCCESS)
{
size_t len;
char buffer[2048];
printf("Error: Failed to build program executable!\n");
clGetProgramBuildInfo(OpenCLProgram, cdDevice, CL_PROGRAM_BUILD_LOG, sizeof(buffer), buffer, &len);
printf("%s\n", buffer);
exit(1);
}
Some useful info:
CL_DEVICE_NAME: AMD Radeon HD - FirePro D300 Compute Engine
CL_DRIVER_VERSION: 1.2 (Jan 10 2017 22:25:08)
If you look at the OpenCL documentation for pow you will notice that it is defined as gentype pow(gentype x, gentype y). The document also states that
The generic type name gentype is used to indicate that the function can take float, float2, float3, float4, float8, float16, double, double2, double3, double4, double8, or double16 as the type for the arguments.
So pow() takes two float or two double values or vectors thereof and returns a value of the same type. Since the compiler cannot determine wether you wanted to call pow(2.0, 2.0) (double precision) or pow(2.0f, 2.0f) (single precision), you get an error instead.
Note that there is also the similar-named function float pown(float x, int y) which takes an integer value for the exponent (e.g. pown(2.0f, 2)) and may provide an optimized implementation of this case.
What does clGetProgramBuildInfo() with param_name=CL_PROGRAM_BUILD_LOG say? This should give you a much more detailed error message. Update the question with this and I might be able to expand this answer.
What version of OpenCL is this? Note that prior to 1.2, the pow() function was only defined for floating-point types; you're expecting it to work with integers.
I have a string like that "2.1648797E -05" and I need to format it to convert "0.00021648797"
Is there any solution to do this conversion
try to use double or long long
cout << setiosflags(ios::fixed) << thefloat << endl;
An important characteristic of floating point is that they do not have precision associated with all the significant figures back to the decimal point for large values. The "scientific" display reasonably reflects the inherent internal storage realities.
In C++ you can use std::stringstream First print the number, then read it as double and then print it using format specifiers to set the accuracy of the number to 12 digits. Take a look at this question for how to print decimal number with fixed precision.
If you are really just going from string representation to string representation and precision is very important or values may leave the valid range for doubles then I would avoid converting to a double.
Your value may get altered by that due to precision errors or range problems.
Try writing a simple text parser. Roughly like that:
Read the digits, omitting the decimal point up to the 'E' but store the decimal point position.
After the 'E' read the exponent as a number and add that to your stored decimal position.
Then output the digits again properly appending zeros at beginning or end and inserting the decimal point.
There are unclear issues here
1. Was the space in "2.1648797E -05" intended, let's assume it is OK.
2. 2.1648797E-05 is 10 times smaller than 0.00021648797. Assume OP meant "0.000021648797" (another zero).
3. Windows is not tagged, but OP posted a Windows answer.
The major challenge here, and I think is the OP's core question is that std::precision() has different meanings in fixed versus default and the OP wants the default meaning in fixed.
Precision field differs between fixed and default floating-point notation. On default, the precision field specifies the maximum number of useful digits to display both before and after the decimal point, possible using scientific notation, while in fixed, the precision field specifies exactly how many digits to display after the decimal point.
2 approaches to solve this: Change the input string to a number and then output the number in the new fixed space format - that is presented below. 2nd method is to parse the input string and form the new format - not done here.
#include <iostream>
#include <iomanip>
#include <string>
#include <sstream>
#include <cmath>
#include <cfloat>
double ConvertStringWithSpaceToDouble(std::string s) {
// Get rid of pesky space in "2.1648797E -05"
s.erase (std::remove (s.begin(), s.end(), ' '), s.end());
std::istringstream i(s);
double x;
if (!(i >> x)) {
x = 0; // handle error;
}
std::cout << x << std::endl;
return x;
}
std::string ConvertDoubleToString(double x) {
std::ostringstream s;
double fraction = fabs(modf(x, &x));
s.precision(0);
s.setf(std::ios::fixed);
// stream whole number part
s << x << '.';
// Threshold becomes non-zero once a non-zero digit found.
// Its level increases with each additional digit streamed to prevent excess trailing zeros.
double threshold = 0.0;
while (fraction > threshold) {
double digit;
fraction = modf(fraction*10, &digit);
s << digit;
if (threshold) {
threshold *= 10.0;
}
else if (digit > 0) {
// Use DBL_DIG to define number of interesting digits
threshold = pow(10, -DBL_DIG);
}
}
return s.str();
}
int main(int argc, char* argv[]){
std::string s("2.1648797E -05");
double x = ConvertStringWithSpaceToDouble(s);
s = ConvertDoubleToString(x);
std::cout << s << std::endl;
return 0;
}
thanks guys and i fix it using :
Decimal dec = Decimal.Parse(str, System.Globalization.NumberStyles.Any);
I saw somewhere that this is a special case and that +NaN goes from 0x7F800001 to 0x7FFFFFFF. Is the answer +NaN?
If you interpret 7FFFFFFF as an IEEE754 32-bit float then yes, 7FFFFFFF is NaN. You can understand these things from looking at the Wikipedia page for Single-precision floating-point format. I wrote this little C program to illustrate the point:
#include <stdio.h>
int main(){
unsigned u0 = 0x7FFFFFFF;
unsigned u1 = 0x7F800001;
unsigned u2 = 0x7F800000;
unsigned u3 = 0x7F7FFFFF;
// *(float*)&u0 causes the data stored in u0 to be interpreted as a float
printf("%e\n", *(float*)&u0); // This gives nan
printf("%e\n", *(float*)&u1); // This also gives nan
printf("%e\n", *(float*)&u2); // This gives inf
printf("%e\n", *(float*)&u3); // This gives 3.402823e+38, the largest possible IEEE754 32-bit float
// The above code only works because sizeof(unsigned)==sizeof(float)
printf("%u\t%u\n", sizeof(unsigned), sizeof(float));
// Remember that nan is only for floats, u0 is a perfectly valid unsigned.
printf("%u\n", u0); // This gives 2147483647
}
Again, it has to be mentioned that NaN only exists as a floating point number.
+NaN is a special value for floating point numbers (And it has no decimal equivalent. It's "Not a Number").
If you just want the decimal representation of the integer, which has 7FFFFFFF as hexadecimal representation, there's no floating point involved, and no +NaN
I just upgraded from OpenCL 1.0 to 1.1. When I make my call to the min() function, I get error output:
<program source>:45:44: error: call to 'min' is ambiguous
int nFramesThisKernelIngests = min(nFramesToIngest - nAvg*nPP*get_global_id(2), nAvg*nPP);
<built-in>:3569:27: note: candidate function
double16 __OVERLOADABLE__ min(double16, double16);
^
<built-in>:3568:26: note: candidate function
double8 __OVERLOADABLE__ min(double8, double8);
The error output continues for more lines with different types.
When I tried to isolate the problem, get_global_id(2) appears to be the problem. I thought that casting get_global_id(2) to an int from a uint (I believe it returns a uint) would solve the problem but it doesn't. Does anybody know what is going on? I looked at the 1.0 and 1.1 specs and I am still confused as to why this is happening.
The OpenCL 1.0 and 1.1 specifications define min to have the following function signatures:
gentype min (gentype x, gentype y)
gentype min (gentype x, sgentype y)
As such, the argument types must be the same, or 1 vector and a scalar matching the vector element type e.g.
int4 a,b;
int c;
min(a,b); // All arguments have the same type
min(a,c); // 2nd element may be scalar, matching the
// element type of the 1st argument ( a vector type )
Note also that the return type of get_global_id is size_t, which may be 32 or 64bits in size.
You will have to cast the expression results to select a specific overload of min.
There are many overloads of min (as the compiler error message is somewhat unhelpfully indicating) e.g.
min(float a, float b);
min(float2 a, float2 b);
min(float2 a, float b);
min(float3 a, float3 b);
min(float3 a, float b);
min(float4 a, float4 b);
... // and vector sizes 4,8,16
min(double a, double b); // With an OpenCL 64bit floating point extension enabled
min(double2 a, double b); // With an OpenCL 64bit floating point extension enabled
... // and integral scalar and vector types (char, schar, short, ushort, int, etc)
...
I don't really know OpenCL, but it looks like the compiler doesn't know if it should promote min's arguments to double8 or double16. Since those types are vectors and not scalars, I guess min is not the function you're looking for. Try fmin instead.
EDIT: Do you see the following in the error messages?
<built-in>:xxxx:yy: note: candidate function
int __OVERLOADABLE__ min(int, int);
JAB IN THE DARK: Cast everything to int:
int nFramesThisKernelIngests = (int) min(
(int) (nFramesToIngest - nAvg * nPP * get_global_id(2)),
(int) (nAvg * nPP));
If that compiles, remove the casts in descending order of silliness (e.g. the first cast is probably meaningless, but YMMV).