[C++] Problem mit einer Berechnung

[_fux_]

hi, ich poste mal schnell die codes und schreibe dann am enden die codes:

#include <iostream>
#include <iomanip>
#include <fstream>
#include <vector>
std::vector< double > vec;
using namespace std;

void integral_rek(int n)
{
// const double PI = 3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679;
const double PI = 3.14159265358979; //3;

double V_1[41];
double schritt1;
double schritt2;


V_1[0] = 2/PI;
V_1[1] = 1/PI;
 
if (n==2){	
cout << setprecision(14) << scientific << "0 " << V_1[0] << endl;
cout << setprecision(14) << scientific << "1 " << V_1[1] << endl;
}
if (n>=2){  
schritt1 = (n*(n-1))/(PI*PI);
schritt2 = schritt1 * V_1[n-2];
V_1[n-1] = V_1[1] -  schritt2;
cout << setprecision(14) << scientific << n << " " << V_1[n-1] << endl;
}
if (n<40) integral_rek(n+1);
}



int main()
{
	integral_rek(2);	
	return 0;
}

und:

double fn( int n )
{
const double PI = 3.14159265358979;
	if( n == 0 )
	{
		return 2/PI;
	}
	else if( n == 1 )
	{
		return 1/PI;
	}
	else
	{
		return 1/PI-(n*(n-1)/(PI*PI))*fn(n-2);
	}
}


int main()
{
	for( int i = 0; i < 40; i++ )
	{
		vec.push_back( fn( i ) );
		cout  << setprecision(14) << scientific << i << " , " <<  fn(i) << endl;
	}

	return 0;
}

der erste un der 2te code sollten eigntl. genau das selbe machen, aber der erste code bringt ab dem 4ten wert nur falsche werte und ich weiß ned warum....
es geht nicht um die Stil frage sondern rein um die begründung warum denn der erste Code nicht funktioniert Oo

 

[sw33tlull4by]

ich glaube das haengt mit dem Array V_1 zusammen.
Du hast in zwar mit 41 Elementen angelegt aber nur die ersten 2 initialisiert.
d.h.
bei den ersten 2 durchlaeufen ist n kleiner 2 und alles ist gut bei durchlauf 3 und 4 auch aber ab dem 5 greift er auf V_1[3] zu
siehe V_1[n-2]
und da der Wert an dieser Speicherzelle nicht definiert ist geht es in die Hose.
mfg

sw33t

ps.:
nur so nebenbei ein array vom typ double mit 41 Elementen frisst verdammt viel speicherplatz, zumal du nur 2 brauchst.
Du kannst das Problem loesen indem du anstatt V_1[n-2] V_1[n%2] schreibst.

P.p.s.:Ich kanns mir einfach nicht verkneifen zu bemerken das Code 1 schon verdammt abgefahren ist.^^

 

[_fux_]

< gelöst >
u.a. war auch die Rekursion falsch (wie du schon sagtest)... ich habs einfach iterativ gemacht, rekursiv ist ja fürn a****.

^^

 

[sw33tlull4by]

nicht unbedingt.
Rekursion ist eine natuerliche herangehensweise an ein Problem.
(wollen wir mal weglassen das es ein unterschied ist ob eine Prozedur oder ein Prozess Rekursiv ist, mach tbei C aber denke ich wenig sinn so eine Unterscheidung zu treffen).
ABER:
Speicherverbrauch ist hoch und die Effiziens meinstens niedrig.
so long.
sw33t

 

[CDW]

Bei manchen Algorithmen sind iterative Lösungen bloß schwerer zu lesen
(auf Anhieb würde ich da an Backtracking-Algo oder Baum-Balancierung (vielleicht sogar Baumsuche, da bin ich mir aber nicht sicher)) denken.
Allerdings sind Beispiele, mit denen Rekursion gelehrt wird, wirklcih für den ...

 

[_fux_]

das stimmt wohl, werde demnächst den code hier veröffentlichen, der hat noch kleine fehler! brauch's aber erst in 2 wochen... =D

#include <iostream>
#include <iomanip>
#include <fstream>
using namespace std;

double integral()
{
	const double PI = 3.14159265358979;
	double schritt1;
	double schritt2;
	double schritt3;
	int n=0;
	double fn[41];
	fn[0] = 2/PI;
	fn[1] = 1/PI;

	ofstream datei;
	datei.open ("ma1_2a.txt");

	do
	{
		if(n==0) cout  << setprecision(14) << scientific << n << " , " <<  fn[0] << endl;
		if(n==1) cout  << setprecision(14) << scientific << n << " , " <<  fn[1] << endl;
		if(n>=2){
			schritt1 = fn[1];
			schritt2 = (n*(n-1))/(PI*PI);
			schritt3 = schritt2 * fn[n-2];
			fn[n] = schritt1-schritt3;
			cout  << setprecision(14) << scientific << n << " , " <<  fn[n] << endl;
			datei << setprecision(14) << scientific << n << "\t" << fn[n] << endl;
		}
		n++;
	}

	while(n<41);
	datei.close();
	return 0;
}




int main()
{
	integral();	
	return 0;
}

naja hier der code, ist zwar nicht ganz exakt, aber funtzt so