Zero inner product when using std::inner_product - c++

The C++ program below should return a stricly positive value. However, it returns 0.
What happens ? I suspect an int-double conversion, but I can't figure out why and how.
#include <iostream>
#include <vector>
#include <numeric>
using namespace std;
int main()
{
vector<double> coordinates;
coordinates.push_back(0.5);
coordinates.push_back(0.5);
coordinates.push_back(0.5);
cout<<inner_product(coordinates.begin(), coordinates.end(), coordinates.begin(), 0)<<endl;
return 0;
}

Because you've supplied an initial value of 0, an int. Your code is internally equivalent to:
int result = 0;
result = result + 0.5 * 0.5; // first iteration
result = result + 0.5 * 0.5; // second iteration
result = result + 0.5 * 0.5; // third iteration
return result;
While result + 0.5 * 0.5 produces the correct value (result is promoted to double in this expression), when that value is assigned back into result, it's truncated (that expression is cast to int). You never get above 1, so you see 0.
Give it an initial value of 0.0 instead.

This is because you provided zero as an integer constant. The resultant operations are all in integers, so the final value (0.75) is truncated to an int as well.
Change zero to 0.0 to make it work:
cout << inner_product(coord.begin(), coord.end(),coord.begin(), 0.0) << endl;
This produces 0.75 on ideone.

Related

How does Cpp work with large numbers in calculations?

I have a code that tries to solve an integral of a function in a given interval numerically, using the method of Trapezoidal Rule (see the formula in Trapezoid method ), now, for the function sin(x) in the interval [-pi/2.0,pi/2.0], the integral is waited to be zero.
In this case, I take the number of partitions 'n' equal to 4. The problem is that when I have pi with 20 decimal places it is zero, with 14 decimal places it is 8.72e^(-17), then with 11 decimal places, it is zero, with 8 decimal places it is 8.72e^(-17), with 3 decimal places it is zero. I mean, the integral is zero or a number near zero for different approximations of pi, but it doesn't have a clear trend.
I would appreciate your help in understanding why this happens. (I did run it in Dev-C++).
#include <iostream>
#include <math.h>
using namespace std;
#define pi 3.14159265358979323846
//Pi: 3.14159265358979323846
double func(double x){
return sin(x);
}
int main() {
double x0 = -pi/2.0, xf = pi/2.0;
int n = 4;
double delta_x = (xf-x0)/(n*1.0);
double sum = (func(x0)+func(xf))/2.0;
double integral;
for (int k = 1; k<n; k++){
// cout<<"func: "<<func(x0+(k*delta_x))<<" "<<"last sum: "<<sum<<endl;
sum = sum + func(x0+(k*delta_x));
// cout<<"func + last sum= "<<sum<<endl;
}
integral = delta_x*sum;
cout<<"The value for the integral is: "<<integral<<endl;
return 0;
}
OP is integrating y=sin(x) from -a to +a. The various tests use different values of a, all near pi/2.
The approach uses a linear summation of values near -1.0, down to 0 and then up to near 1.0.
This summation is sensitive to calculation error with the last terms as the final math sum is expected to be 0.0. Since the start/end a varies, the error varies.
A more stable result would be had adding the extreme f = sin(f(k)) values first. e.g. sum += sin(f(k=1)), then sum += sin(f(k=3)), then sum += sin(f(k=2)) rather than k=1,2,3. In particular the formation of term x=f(k=3) is likely a bit off from the negative of its x=f(k=1) earlier term, further compounding the issue.
Welcome to the world or numerical analysis.
Problem exists if code used all float or all long double, just different degrees.
Problem is not due to using an inexact value of pi (Exact value is impossible with FP as pi is irrational and all finite FP are rational).
Much is due to the formation of x. Could try the below to form the x symmetrically about 0.0. Compare exactly x generated this way to x the original way.
x = (x0-x1)/2 + ((k - n/2)*delta_x)
Print out the exact values computed for deeper understanding.
printf("x:%a y:%a\n", x0+(k*delta_x), func(x0+(k*delta_x)));

Function for calculating Pi using taylor series in c++

So I'm at a loss on why my code isn't working, essentially the function I am writing calculates an estimate for Pi using the taylor series, it just crashes whenever I try run the program.
here is my code
#include <iostream>
#include <math.h>
#include <stdlib.h>
using namespace std;
double get_pi(double accuracy)
{
double estimate_of_pi, latest_term, estimated_error;
int sign = -1;
int n;
estimate_of_pi = 0;
n = 0;
do
{
sign = -sign;
estimated_error = 4 * abs(1.0 / (2*n + 1.0)); //equation for error
latest_term = 4 * (1.0 *(2.0 * n + 1.0)); //calculation for latest term in series
estimate_of_pi = estimate_of_pi + latest_term; //adding latest term to estimate of pi
n = n + 1; //changing value of n for next run of the loop
}
while(abs(latest_term)< estimated_error);
return get_pi(accuracy);
}
int main()
{
cout << get_pi(100);
}
the logic behind the code is the following:
define all variables
set estimate of pi to be 0
calculate a term from the taylor series and calculate the error in
this term
it then adds the latest term to the estimate of pi
the program should then work out the next term in the series and the error in it and add it to the estimate of pi, until the condition in the while statement is satisfied
Thanks for any help I might get
There are several errors in your function. See my comments with lines starting with "//NOTE:".
double get_pi(double accuracy)
{
double estimate_of_pi, latest_term, estimated_error;
int sign = -1;
int n;
estimate_of_pi = 0;
n = 0;
do
{
sign = -sign;
//NOTE: This is an unnecessary line.
estimated_error = 4 * abs(1.0 / (2*n + 1.0)); //equation for error
//NOTE: You have encoded the formula incorrectly.
// The RHS needs to be "sign*4 * (1.0 /(2.0 * n + 1.0))"
// ^^^^ ^
latest_term = 4 * (1.0 *(2.0 * n + 1.0)); //calculation for latest term in series
estimate_of_pi = estimate_of_pi + latest_term; //adding latest term to estimate of pi
n = n + 1; //changing value of n for next run of the loop
}
//NOTE: The comparison is wrong.
// The conditional needs to be "fabs(latest_term) > estimated_error"
// ^^^^ ^^^
while(abs(latest_term)< estimated_error);
//NOTE: You are calling the function again.
// This leads to infinite recursion.
// It needs to be "return estimate_of_pi;"
return get_pi(accuracy);
}
Also, the function call in main is wrong. It needs to be:
get_pi(0.001)
to indicate that if the absolute value of the term is less then 0.001, the function can return.
Here's an updated version of the function that works for me.
double get_pi(double accuracy)
{
double estimate_of_pi, latest_term;
int sign = -1;
int n;
estimate_of_pi = 0;
n = 0;
do
{
sign = -sign;
latest_term = sign * 4 * (1.0 /(2.0 * n + 1.0)); //calculation for latest term in series
estimate_of_pi += latest_term; //adding latest term to estimate of pi
++n; //changing value of n for next run of the loop
}
while(fabs(latest_term) > accuracy);
return estimate_of_pi;
}
Your return statement may be the cause.
Try returning "estimate_of_pi" instead of get_pi(accuracy).
Your break condition can be rewritten as
2*n + 1 < 1/(2*n + 1) => (2*n + 1)^2 < 1
and this will never be true for any positive n. Thus your loop will never end. After fixing this you should change the return statement to
return estimated_error;
You currently are calling the function recursively without an end (assuming you fixed the stop condition).
Moreoever you have a sign and the parameter accuracy that you do not use at all in the calculation.
My advice for such iterations would be to always break on some maximum number of iterations. In this case you know it converges (assuming you fix the maths), but in general you can never be sure that your iteration converges.

Floating point difficulty in area of triangle

The output created by my program is at first accurate, then becomes 0 for all answers above 5000000. I would like to know why this is the case when I use the function I have called Heron's Area.
#include "stdafx.h"
#include "stdlib.h"
#include <iostream>
#include <math.h>
#include <stdio.h>
float heron_area(float a, float c) {
float s = (a + a + c) / 2.0f;
return (s - a)*sqrtf(s*(s - c));
}
int main(void) {
int j = 18;
float i = 10;
for (int k = 0; k < j; k++){
float g = i * 10;
std::cout << heron_area(g, 1) << std::endl;
i = g;
}
return 0;
}
It is potentially to do with the issue with using floating point numbers. Why am I getting the output of 0 after the last output 500000?
It is the issue with floating point numbers as you suspect.
If you print a and s in heron_area, you'll note that they very quickly become identical, making s - a zero.
This happens when c is much smaller than a (that is, when you have a very "pointy" triangle; your zeros appear when two sides are 10,000,000 and the third is 1).
Changing the type to double makes the problem appear later, but it won't go away.
You'll need to rearrange your computations if you want to handle very large differences in magnitude.
There's a solution on Wikipedia (linked by #harold in the comments) that gives
Area = 0.25 * sqrt((a+(b+c)) * (c-(a-b)) * (c+(a-b)) * (a+(b-c)))
where a >= b and b >= c, and the brackets are necessary.
Yes, you need to worry about the order of operations.
(And there's a very detailed article here with an analysis of this solution.)
As the variable a in the function heron_area grows exponentially larger and larger, the variable c, which is constant, with the value 1.0f, becomes less and less relevant.
Due to limited precision of the floating point the expression:
float s = (a + a + c) / 2.0f;
then simplifies to:
float s = (a + a) / 2.0f;
which is the same as:
float s = a;
Thus the variables s and a have the same value, so the expression:
return (s - a)*sqrtf(s*(s - c));
always yields 0.0f, as the result of subtracting s - a is 0.0f, and multiplying zero by anything is always zero.

Value inside loop doesnt change in C++

here is a sample code that doesnt seem to work. I get the same value of X and Y ( both of them equal to zero ) for all the iteration. Can someone help me with this mistake of mine?
#include <iostream>
using namespace std;
int main()
{
double coord[4][2];
int div_x, div_y;
coord[1][0]=2;
coord[1][1]=0;
coord[2][0]=2;
coord[2][1]=4;
coord[3][0]=0;
coord[3][1]=4;
div_x = 4;
div_y = 3;
double a =0,b=0,c=0,d=0,e=0,f=0,g=0,h=0;
a = coord[1][0]+coord[2][0]+coord[3][0];
b = coord[1][0]+coord[2][0]-coord[3][0];
c = coord[2][0]-coord[1][0]+coord[3][0];
d = coord[2][0]-coord[1][0]-coord[3][0];
e = coord[1][1]+coord[2][1]+coord[3][1];
f = coord[1][1]+coord[2][1]-coord[3][1];
g = coord[2][1]-coord[1][1]+coord[3][1];
h = coord[2][1]-coord[1][1]-coord[3][1];
for (int i=0; i<div_y+1; i++){ // loop all rows (blue)
for (int j=0; j<div_x+1; j++){ // loop all nodes of one row (green)
double w = -1 + (2/div_x)*j;
double s = -1 + (2/div_y)*i;
double X = (a+b*w+c*s+(w*s*d));
double Y = (e+f*w+g*s+(h*s*w));
cout<<"\nX "<<X<<endl;
cout<<"\nY "<<Y<<endl;
}
}
return 0;
}
.
Your problem is with the divisions here:
double w = -1 + (2/div_x)*j;
double s = -1 + (2/div_y)*i;
2/div_x and 2/div_y are integer divisions. When you divide two values of type integer in C++, the division is carried out as an integer division. Since div_x is 4 and div_y is 3, the result of both of them is 0. As an integer division:
2 / 4 = 0
2 / 3 = 0
The easiest way to fix this is to use a double value for one of the two values, which results in a double division. For example:
double w = -1.0 + (2.0/div_x)*j;
double s = -1.0 + (2.0/div_y)*i;
You may also want to consider using the float type instead of double, unless you really need more than float precision, which is about 7 decimal digits.
In your code, div_x and div_y are int, thus, (2/div_x) and (2/div_y) are integer divisions, and evaluate to 0.
So w and s are both always equal to -1.
You can force float evaluation by using : (2.0/div_x) and (2.0/div_y)

Code for normal distribution returns unexpected values [duplicate]

From this question: Random number generator which gravitates numbers to any given number in range? I did some research since I've come across such a random number generator before. All I remember was the name "Mueller", so I guess I found it, here:
Box-Mueller transform
I can find numerous implementations of it in other languages, but I can't seem to implement it correctly in C#.
This page, for instance, The Box-Muller Method for Generating Gaussian Random Numbers says that the code should look like this (this is not C#):
#include <stdio.h>
#include <stdlib.h>
#include <math.h>
#include <time.h>
double gaussian(void)
{
static double v, fac;
static int phase = 0;
double S, Z, U1, U2, u;
if (phase)
Z = v * fac;
else
{
do
{
U1 = (double)rand() / RAND_MAX;
U2 = (double)rand() / RAND_MAX;
u = 2. * U1 - 1.;
v = 2. * U2 - 1.;
S = u * u + v * v;
} while (S >= 1);
fac = sqrt (-2. * log(S) / S);
Z = u * fac;
}
phase = 1 - phase;
return Z;
}
Now, here's my implementation of the above in C#. Note that the transform produces 2 numbers, hence the trick with the "phase" above. I simply discard the second value and return the first.
public static double NextGaussianDouble(this Random r)
{
double u, v, S;
do
{
u = 2.0 * r.NextDouble() - 1.0;
v = 2.0 * r.NextDouble() - 1.0;
S = u * u + v * v;
}
while (S >= 1.0);
double fac = Math.Sqrt(-2.0 * Math.Log(S) / S);
return u * fac;
}
My question is with the following specific scenario, where my code doesn't return a value in the range of 0-1, and I can't understand how the original code can either.
u = 0.5, v = 0.1
S becomes 0.5*0.5 + 0.1*0.1 = 0.26
fac becomes ~3.22
the return value is thus ~0.5 * 3.22 or ~1.6
That's not within 0 .. 1.
What am I doing wrong/not understanding?
If I modify my code so that instead of multiplying fac with u, I multiply by S, I get a value that ranges from 0 to 1, but it has the wrong distribution (seems to have a maximum distribution around 0.7-0.8 and then tapers off in both directions.)
Your code is fine. Your mistake is thinking that it should return values exclusively within [0, 1]. The (standard) normal distribution is a distribution with nonzero weight on the entire real line. That is, values outside of [0, 1] are possible. In fact, values within [-1, 0] are just as likely as values within [0, 1], and moreover, the complement of [0, 1] has about 66% of the weight of the normal distribution. Therefore, 66% of the time we expect a value outside of [0, 1].
Also, I think this is not the Box-Mueller transform, but is actually the Marsaglia polar method.
I am no mathematician, or statistician, but if I think about this I would not expect a Gaussian distribution to return numbers in an exact range. Given your implementation the mean is 0 and the standard deviation is 1 so I would expect values distributed on the bell curve with 0 at the center and then reducing as the numbers deviate from 0 on either side. So the sequence would definitely cover both +/- numbers.
Then since it is statistical, why would it be hard limited to -1..1 just because the std.dev is 1? There can statistically be some play on either side and still fulfill the statistical requirement.
The uniform random variate is indeed within 0..1, but the gaussian random variate (which is what Box-Muller algorithm generates) can be anywhere on the real line. See wiki/NormalDistribution for details.
I think the function returns polar coordinates. So you need both values to get correct results.
Also, Gaussian distribution is not between 0 .. 1. It can easily end up as 1000, but probability of such occurrence is extremely low.
This is a monte carlo method so you can't clamp the result, but what you can do is ignore samples.
// return random value in the range [0,1].
double gaussian_random()
{
double sigma = 1.0/8.0; // or whatever works.
while ( 1 ) {
double z = gaussian() * sigma + 0.5;
if (z >= 0.0 && z <= 1.0)
return z;
}
}