#include <math.h>
#include <stdio.h>
int main() {
double x0, x, eps, dx, r;
x0 = 0.60000;
x = x0;
eps = 0.0001;
do {
r = x + pow(x, 1 / 2) + pow(x, 1 / 3) - 2.5;
dx = (r / (1 - 1 / 2 (x , -1 / 2) + 1/3 (x, -1 / 3)));
x = (x - dx);
} while ((abs(dx)) > eps);
printf("%f %f\n", x, r);
return 0;
}
*error: called object is not a function or function pointer *
the code does not work, what needs to be done to make everything right
You have tons of syntax and semantic errors:
pow(x, 1 / 2)
Here 1/2 does integer division which means that the resulting 0.5 is chopped to 0.
To get floating point results you must ensure that at least one operand is a floating type like 1.0/2.
Then you have a similar piece
1/2(x,-1/2)
Again, due to integer division -1/2 evaluates to 0.
Furthermore you are missing some operator before the brackets.
That means the compiler expects some function call.
But 2 is not a function. That is probably the place where you get your error message.
If you use , in other situations than a parameter list or variable definition list, it is taken as a "comma operator" that evaluates to the second operand. That means (x,-1/2)evaluates to (-1/2) which again evaluates to 0.
In this case I have no idea what you want to achieve with that expression and cannot give some fix for that.
Finally, you use a function that is not suitable for floating point numbers and don't provide a prototype for it as well:
abs(dx)
You should use fabs instead.
Usage of abs is also broken because it requires header stdlib.h which you do not include.
Related
#include <stdio.h>
#include <stdlib.h>
#include <math.h>
int main()
{
double a;
double b;
double q0 = 0.5 * M_PI + 0.5 * -2.1500000405000002;
double q1 = 0.5 * M_PI + 0.5 * 0.0000000000000000;
double w0 = 0.5 * M_PI + 0.5 * -43000.0008100000050000;
double w1 = 0.5 * M_PI + 0.5 * -0.0000000000000000;
double m = 1;
double g = 43000000.81;
double l1 = 0.1;
double l2 = 0.1;
double h = 0.0001;
a = ((-g / l1) * sin(q0) + (sin(q1 - q0) * (cos(q1 - q0) * (w0 * w0 + (g / l1) * cos(q0)) + l2 * (w1 * w1 / l1))) / (m + pow(sin(q1 - q0), 2)));
a = h * a;
b = h * ((-g / l1) * sin(q0) + (sin(q1 - q0) * (cos(q1 - q0) * (w0 * w0 + (g / l1) * cos(q0)) + l2 * (w1 * w1 / l1))) / (m + pow(sin(q1 - q0), 2)));
printf("%.20lf ", a);
printf("%.20lf", b);
return 0;
}
I do the same calculations with a and b, just with the difference that I get the value of a in two steps, and the b in one.
My code returns:
-629.47620126173774000000 -629.47620126173763000000
What is the reason of the difference between the two last decimals?
The C Standard (99 and 11) says:
The values of operations with floating operands and values subject to the usual arithmetic conversions and of floating constants are evaluated to a format whose range and precision may be greater than required by the type.
So in an expression such as h*(X+Y) as you have in the assignment to b, the implementation is allowed to use greater precision for the intermediate result of X+Y than can possibly be stored in a double, even though the type of the subexpression is still considered to be double. But in a=X+Y; a=h*a;, the first assignment forces the value to be one that actually can be stored in a double, causing a slightly different result.
Another possibility is that the compiler has done "floating point contraction". To quote the C Standard again,
A floating expression may be contracted, that is, evaluated as though it were an atomic operation, thereby omitting rounding errors implied by the source code and the expression evaluation method.
This would most likely happen if the processor has a single instruction that can do a floating point addition and then a multiplication in one step, and the compiler decided to use it.
Assuming one or both of these is the cause, your value b is likely a more accurate representation of the computation you specified (given that all the inputs were restricted to values which can be represented in a double).
The cppreference page about macro FLT_EVAL_METHOD discusses both of these issues in a little more detail. It may be interesting to find out your value of FLT_EVAL_METHOD and play with #pragma STDC FP_CONTRACT OFF.
The answer is because in the float numbers calculations the equation a=bcde does not have to be equal to x = bc y = de and a.= xy.
It is because floating point arithmetic has a limited precision.
That's my code -
main()
{
double x;
double y = pow(((1/3 + sin(x/2))(pow(x, 3) + 3)), 1/3);
printf("%f", y);
return 0;
}
I get an error in double y = pow((1/3 + sin(x/2))(pow(x, 3) + 3), 1/3);, it says that called object is not a function or function pointer. I don't get it though - (1/3 + sin(x/2))(pow(x, 3) + 3) is the first element of pow(x, y); that is the x I want to raise to y (1/3) power. Where lies the problem? I'm pretty new to c basic but I can't find the answer anywhere.
If you want to multiply, you need to use the * operator. You can't put parenthesized expressions adjacent to each other to denote multiplication.
(1/3 + sin(x/2))*(pow(x, 3) + 3)
That's because the return value of pow is a double, not a function. Maybe what you're trying to do is pass a call to pow as the second argument to the first pow.
#include <stdio.h>
#include <math.h> // For pow() function
int main() {
// Initialize with whatever value you want
double x = 100;
// Make sure to use an arithmetic operator
double y = pow(((1/3.0 + sin(x/2))*(pow(x, 3) + 3)), 1/3.0);
// Use right format specifier
printf("%lf", y);
return 0;
}
Don't forget to include math.h library.
Initialize x with a value.
Avoid using integer division 1/3, instead use 1/3.0 or 1.0/3.0 because 1/3 == 0.
Use an arithmetic operator (+, -, *, /) before middle pow() like pow(((1/3.0 + sin(x/2))+(pow(x, 3) + 3)), 1/3.0).
(Opt.) Use right format specifier for y which is %lf. But you may get away with %f.
I wrote a function to find the cube root of a number a using the Newton-Raphson method to find the root of the function f(x) = x^3 - a.
#include <stdio.h>
#include <math.h>
double cube_root(double a)
{
double x = a;
double y;
int equality = 0;
if(x == 0)
{
return(x);
}
else
{
while(equality == 0)
{
y = (2 * x * x * x + a) / (3 * x * x);
if(y == x)
{
equality = 1;
}
x = y;
}
return(x);
}
}
f(x) for a = 20 (blue) and a = -20 (red) http://graphsketch.com/?eqn1_color=1&eqn1_eqn=x*x*x%20-%2020&eqn2_color=2&eqn2_eqn=x*x*x%20%2B%2020&eqn3_color=3&eqn3_eqn=&eqn4_color=4&eqn4_eqn=&eqn5_color=5&eqn5_eqn=&eqn6_color=6&eqn6_eqn=&x_min=-8&x_max=8&y_min=-75&y_max=75&x_tick=1&y_tick=1&x_label_freq=5&y_label_freq=5&do_grid=0&bold_labeled_lines=0&line_width=4&image_w=850&image_h=525
The code seemed to be working well, for example it calculates the cube root of 338947578237847893823789474.324623784 just fine, but weirdly fails for some numbers for example 4783748237482394? The code just seems to go into an infinite loop and must be manually terminated.
Can anyone explain why the code should fail on this number? I've included the graph to show that, using the starting value of a, this method should always keep providing closer and closer estimates until the two values are equal to working precision. So I don't really get what's special about this number.
Apart from posting an incorrect formula...
You are performing floating point arithmetic, and floating point arithmetic has rounding errors. Even with the rounding errors, you will get very very close to a cube root, but you won't get exactly there (usually cube roots are irrational, and floating point numbers are rational).
Once your x is very close to the cube root, when you calculate y, you should get the same result as x, but because of rounding errors, you may get something very close to x but slightly different instead. So x != y. Then you do the same calculation starting with y, and you may get x as the result. So your result will forever switch between two values.
You can do the same thing with three numbers x, y and z and quit when either z == y or z == x. This is much more likely to stop, and with a bit of mathematics you might even be able to proof that it will always stop.
Better to calculate the change in x, and determine whether that change is small enough so that the next step will not change x except for rounding errors.
shouldn't it be:
y = x - (2 * x * x * x + a) / (3 * x * x);
?
So I am trying to cast (3/17) as double. This is for an assignment so the professor wants it to be this way for some reason.
I am trying to cast it by doing the following:
(double)(3/17)
Actual code:
int assignment7()
{
#include <stdio.h>
#define PI 3.14
int a=0;
double Ny=0,y=0,z=0,x=0,amod2=0;
printf("Enter values for x,y,z and a(must be an odd number): ");
scanf("%lf%lf%lf%d",&x,&y,&z,&a);
amod2=a%2;
printf("%.2lf\n",test);
Ny=y / (double)(3/17) - z + x / amod2 + PI;
printf("%lf\n",Ny);
}
The problem is occurring on the second to last line where it is interpreting 3/17 as an int thus it would equal 0. y / 0
Professors exact instructions:
"General equation: y = y / (3/17) - z + x / (a % 2) + PI (recall: a is an integer; the 3 and 17 constants in the equation should be left as integers initially, but explicitly type-casted as floating-point values)"
(3/17) is equal to 0 because it is evaluated using integer arithmetic, and so you get a divide by zero, which is of course a run-time error. Change:
(double)(3/17)
to:
(3.0 / 17.0)
Note that the cast is redundant.
You have a division by zero as 3/17 is zero.
Instead use doubles to begin with: 3.0 / 17.0, then you don't even need the cast.
I'm using DevCPP IDE and I found that while programming in c,
Value returned by:
float f(float x)
{
return 1/(1+x*x);
}
and value returned by f(x) if it's defined as:
#define f(x) 1/(1+x*x)
are different.
Why am I getting different results in these cases?
EDIT:
Here's my code for which I'm getting the anomaly:
main()
{
int i;
float a=0, b=1, h, n=12, s1, s2=0;
h=(b-a)/n; //step length
s1=f(a)+f(b);
for(i=1;i<=n-1;i++)
{
s2+=f(a+(i*h));
}
s1=(s1+2*s2)*h/2;
printf("sum: %f", s1);
getch();
}
OUTPUT 1: 0.693581 (using MACRO)
OUTPUT 2: 0.785109 (using function)
There are many possibilities here. Here's a few.
In the function version, the argument is explicitly typed as a float. This means that if you call
f(1);
then 1 is converted to the float 1.0f as the argument. Then, when 1 / (1 + x * x) is computed, it evaluates to 1 / 2.0f, which comes out to 0.5f. However, in the macro version, f(1) would be evaluated as 1 / 2 using integer division, yielding the value 0.
Second, in the function version, the argument is evaluated only once. This means that
int x = 0;
f(x++);
will increment x to 1, then pass in the value 0. The result will then be 1.0f. In the macro version, however, the code expands to
1 / (1 + x++ * x++)
This causes has undefined behavior because there is no sequence point between the evaluations of x++. This expression could evaluate to anything, or it could crash the program outright.
Finally, the function version respects operator precedence while the macro does not. For example, in the function version, calling
f(1 - 1)
will call f(0), evaluating to 1.0f. In the macro version, this expands to
1 / (1 + 1 - 1 * 1 - 1)
= 1 / (1 + 1 - 1 - 1)
= 1 / 0
This causes undefined behavior because of a divide-by-zero error.
The simple way to avoid this is to not use macros to define functions. Way back in the Bad Old Days this was a standard practice, but now that C has inline functions and compilers are way smarter, you should prefer functions to macros. They're safer, easier to use, and harder to mess up. They're also type aware and don't evaluate arguments multiple times.
Hope this helps!
#define f(x) 1/(1+x*x)
should be defined as
#define f(x) 1/(1+(x)*(x))
Try this:
#define f(x) (1/(1+x*x))
A #define basically sticks the code where the #define'd name was, so order of operations and precedence will apply.