Bonjour tout le monde,

#include <stdio.h>
#include <stdlib.h>
#include <math.h>
#include <time.h>

double distance_plot(double x, double y, double plot_x, double plot_y){
	return pow( (x - plot_x) * (x - plot_x) + (y - plot_y) * (y - plot_y), 0.5 );
}

void euler(double h, double plot_x1, double plot_y1, double plot_x2, double plot_y2, double plot_x3, double plot_y3){

	FILE *data = fopen("data_euler3.txt", "w" "r");

	if(data == 0){
		printf("impossible\n");
		exit(0);
	}
	
	FILE *data1 = fopen("data1_euler3.txt", "a");

	if(data1 == NULL){
	perror("impossible");
	exit(0);
	}

	FILE *data2 = fopen("data2_euler3.txt", "w");

	if(data2 == NULL){
	perror("impossible");
	exit(EXIT_FAILURE);
	}

	FILE *data3 = fopen("data3_euler3.txt", "w");

	if(data3 == NULL){
	perror("impossible");
	exit(EXIT_FAILURE);
	}   

	FILE *points_out = fopen("out_euler3.txt", "w");

	if(points_out == NULL){
	perror("impossible");
	exit(EXIT_FAILURE);
	} 	
	
	
	double extension_spatiale = 1;	
	double x_0, y_0;
	double x_max = 50;
	double y_max = 50;
	double r1, r2, r3;	
		
	for(x_0 = 0; x_0 <= x_max ; x_0 += 1){
		for(y_0 = 0; y_0 <= y_max ; y_0 += 1){
		
			double v_x = 0, v_y = 0;
			double x = x_0 ;
			double y = y_0 ;
			int NbIteration = 0;
			int CdtExit = 1;		
			do{
			
				r1 = distance_plot(x, y, plot_x1, plot_y1);
				r2 = distance_plot(x, y, plot_x2, plot_y2);
				r3 = distance_plot(x, y, plot_x3, plot_y3);
				
				v_x  += h * -( (x - plot_x1) / pow(r1, 3.0) ) + h * -( (x - plot_x2) / pow(r2, 3.0) ) + h * -( (x - plot_x3) / pow(r3, 3.0) ) ;
				x    += h * v_x ;
			
				v_y  += h * -( (y - plot_y1) / pow(r1, 3.0) ) + h * -( (y - plot_y2) / pow(r2, 3.0) ) +  h * -( (y - plot_y3) / pow(r3, 3.0) ) ;
				y    += h * v_y ;			
	 						
				printf("\n*********\n pour x = %lf et y = %lf r1 = %lf r2 = %lf r3 = %lf\n", x_0, y_0, r1, r2, r3);	
		 		fprintf(data, "%e %e %e %e %e %e %e\n ", x, y, x_0, y_0, r1, r2, r3);
		 		
				/*
				if(NbIteration > 10000){
					CdtExit = 0;
					fprintf(points_out, "%lf %lf\n", x_0, y_0);
				}*/	
				
			} while(r1 > extension_spatiale &&(r2 > extension_spatiale) &&(r3 > extension_spatiale)); //&&(CdtExit));
			
			fprintf(test, "bonjour\n");
			
			if(r1 < extension_spatiale){
				fprintf(data, "NOUVELLE PARTICULE %lf %lf\n", x_0, y_0);
				fprintf(data1, "%lf %lf\n", x_0, y_0);
			}

			if(r2 < extension_spatiale){
				fprintf(data2, "%lf %lf\n", x_0, y_0);
			}

			if(r3 < extension_spatiale){
				fprintf(data3, "%lf %lf\n", x_0, y_0);	
			} 		
			
			
			
		
		}
	}
	
	fclose(data1);
	fclose(data2);
	fclose(data3);
	fclose(data);	
}

int main(){
	
	double h = 0.001;
	
	double CENTRE_PLOT_x1 = 3;
	double CENTRE_PLOT_y1 = 5;

	double CENTRE_PLOT_x2 = 8;
	double CENTRE_PLOT_y2 = 18;

	double CENTRE_PLOT_x3 = 17;
	double CENTRE_PLOT_y3 = 13; 
	
	euler(h, CENTRE_PLOT_x1, CENTRE_PLOT_y1, CENTRE_PLOT_x2, CENTRE_PLOT_y2, CENTRE_PLOT_x3, CENTRE_PLOT_y3);
 		
}

Voici mon problème qui est survenu depuis peu  :

Dans le code ci-dessus, qui décrit un problème physique, j'ai un soucis avec l'écriture dans mes fichiers. Ma condition "r1 < extension_spatiale" est bien vérifié et donc on rentre dans la boucle. Le programme écrit dans le fichier "data_euler3.txt" : NOUVELLE PARTICULE x_0 y_0. Mais n'écrit en AUCUN cas dans le fichier "data1_euler3.txt" qui est la ligne de code qui suit.

Je ne comprends pas pourquoi mon programme écrit bien dans le premier fichier mais pas dans le deuxième sachant que je suis dans la boucle car la condition est respectée.

Pouvez-vous m'aider svpp ??

____

-
Edité par edgarjacobs 18 avril 2023 à 1:11:40

Je n'ai pas trouvé non plus.
Je te suggère d'écrire une petite fonction qui ferait les fopen(). Tu lui donne le nom du fichier et le mode d'accès.
Dans la fonction, tu appelles perror et tu affiches le nom du fichier en cas d'erreur entre ' ... '
ça va simplifier un peu ton code.
Pour les fprintf(), cette fonction retourne le nombre de caractères écrits (du moins formatés).
C'est peut-être une indication pour t'aider.
Tu sembles dire que l'erreur est récente. Sais-tu ce que tu as changé depuis le moment où ça marchait?

Sur la ligne suivante:
    FILE *data = fopen("data_euler3.txt", "w" "r");
Si je fais un petit test, c'est bloquant. "w" "r" donne "wr"
et je suppose que le "r" est pris en compte plutôt que le "w".

Autre test:
 
#include <stdio.h>
#include <stdlib.h>
FILE *file_open(char *name, char *access) {
    FILE *file = fopen(name, access);
    if(file) return file;
    perror("fopen");
    fprintf(stderr, "File: '%s', access: '%s'\n", name, access);
    exit(EXIT_FAILURE);
}
int main(void) {
    FILE *f = file_open("aa.t", "w" "r");
    fprintf(f, "Salut!\n");
    printf("OK");
}
 
fopen: Invalid argument
File: 'aa.t', access: 'wr'

-
Edité par PierrotLeFou 18 avril 2023 à 4:25:48

Le code que tu fournis ne compile pas

prog.c: Dans la fonction « euler »:
prog.c:85:21: erreur: « test » non déclaré (première utilisation dans cette fonction)
   85 |             fprintf(test, "bonjour\n");
      |      

Donc ce n'est pas lui qui montre le comportement dont tu nous parles.

x x x

Si je remplace la ligne par une écriture sur stdout (que je redirige vers texte.txt), il a l'air de boucler.   Je l'interromps brutalement après quelques dizaines de secondes, et je vois qu'il a produit des gigas de texte.

$ ls -sh
total 5,8G
   0 data1_euler3.txt  2,9G data_euler3.txt   24K prog
8,0K data2_euler3.txt  4,0K Makefile         4,0K prog.c
   0 data3_euler3.txt     0 out_euler3.txt   2,9G texte.txt

Est-ce bien normal ?  En tout cas j'ai pas envie d'attendre 3 jours qu'il ait rempli mon disque.  Pour la mise au point, il faut travailler sur des petits exemples.

x x x

Comme j'interromps le programme avant la fin, il est possible que des données  écrites dans le tampon de data1 n'aient pas été mises dans le fichier.  Il n'y a eu que 128 écritures, c'est pas énorme

$ grep NOUVELL data_euler3.txt | wc
    128     512    4897

EDIT : je confirme le problème de tampon !!!

Si j'arrête le programme après la découverte de la première particule

if(r1 < extension_spatiale){
     fprintf(data, "NOUVELLE PARTICULE %lf %lf\n", x_0, y_0);
     fprintf(data1, "%lf %lf\n", x_0, y_0);

     // STOP NOW 

     fclose(data1);
     exit(0);
}

On trouve des données dans data1_euler3

billaud@sims:~/Essais/bugs$ rm *.txt

billaud@sims:~/Essais/bugs$ ls
Makefile  prog  prog.c

billaud@sims:~/Essais/bugs$ ./prog >texte.txt

billaud@sims:~/Essais/bugs$ ls -l
total 2576
-rw-r--r-- 1 billaud billaud      18 18 avril 09:35 data1_euler3.txt
-rw-r--r-- 1 billaud billaud       0 18 avril 09:35 data2_euler3.txt
-rw-r--r-- 1 billaud billaud       0 18 avril 09:35 data3_euler3.txt
-rw-r--r-- 1 billaud billaud 1313245 18 avril 09:35 data_euler3.txt
-rw-r--r-- 1 billaud billaud     326 18 avril 07:59 Makefile
-rw-r--r-- 1 billaud billaud       0 18 avril 09:35 out_euler3.txt
-rwxr-xr-x 1 billaud billaud   20872 18 avril 09:28 prog
-rw-r--r-- 1 billaud billaud    3659 18 avril 09:27 prog.c
-rw-r--r-- 1 billaud billaud 1284668 18 avril 09:35 texte.txt

billaud@sims:~/Essais/bugs$ more data1_euler3.txt 
0.000000 0.000000

x x x

Il y a peut être un problème à l'exploitation de la sortie de la boucle

             
            } while(r1 > extension_spatiale &&(r2 > extension_spatiale) &&(r3 > extension_spatiale)); //&&(CdtExit));
             
            fprintf(test, "bonjour\n");
             
            if(r1 < extension_spatiale){
                fprintf(data, "NOUVELLE PARTICULE %lf %lf\n", x_0, y_0);
                fprintf(data1, "%lf %lf\n", x_0, y_0);
            }
 
            if(r2 < extension_spatiale)
                fprintf(data2, "%lf %lf\n", x_0, y_0);
            }
 
            if(r3 < extension_spatiale){
                fprintf(data3, "%lf %lf\n", x_0, y_0); 
            }      
     

La négation de  l'inégalilté stricte  r1 > extension_spatiale (qui mériterait des parenthèses pour ressembler à ses copines),  c'est  r1 <= extension_spatiale, une inégalité large.

-
Edité par michelbillaud 18 avril 2023 à 9:38:40

PierrotLeFou a écrit:

Je n'ai pas trouvé non plus.
Je te suggère d'écrire une petite fonction qui ferait les fopen(). Tu lui donne le nom du fichier et le mode d'accès.
Dans la fonction, tu appelles perror et tu affiches le nom du fichier en cas d'erreur entre ' ... '
ça va simplifier un peu ton code.
Pour les fprintf(), cette fonction retourne le nombre de caractères écrits (du moins formatés).
C'est peut-être une indication pour t'aider.
Tu sembles dire que l'erreur est récente. Sais-tu ce que tu as changé depuis le moment où ça marchait?

Sur la ligne suivante:
    FILE *data = fopen("data_euler3.txt", "w" "r");
Si je fais un petit test, c'est bloquant. "w" "r" donne "wr"
et je suppose que le "r" est pris en compte plutôt que le "w".

Autre test:
 
#include <stdio.h>
#include <stdlib.h>
FILE *file_open(char *name, char *access) {
    FILE *file = fopen(name, access);
    if(file) return file;
    perror("fopen");
    fprintf(stderr, "File: '%s', access: '%s'\n", name, access);
    exit(EXIT_FAILURE);
}
int main(void) {
    FILE *f = file_open("aa.t", "w" "r");
    fprintf(f, "Salut!\n");
    printf("OK");
}
 
fopen: Invalid argument
File: 'aa.t', access: 'wr'

-
Edité par PierrotLeFou il y a environ 5 heures

Malheuresement, je n'ai rien modifié de ce que je sache. C'est bien pour cela que ça m'intrigue...

michelbillaud a écrit:

Le code que tu fournis ne compile pas

prog.c: Dans la fonction « euler »:
prog.c:85:21: erreur: « test » non déclaré (première utilisation dans cette fonction)
   85 |             fprintf(test, "bonjour\n");
      |      

Donc ce n'est pas lui qui montre le comportement dont tu nous parles.

-
Edité par michelbillaud il y a 13 minutes

En effet, je me suis trompé, j'ai oublié de supprimer la ligne quand j'ai fais le copier coller, mais il ne faut pas tenir compte de ce fprintf.

michelbillaud a écrit:

EDIT : je confirme le problème de tampon !!!

Si j'arrête le programme après la découverte de la première particule

if(r1 < extension_spatiale){
     fprintf(data, "NOUVELLE PARTICULE %lf %lf\n", x_0, y_0);
     fprintf(data1, "%lf %lf\n", x_0, y_0);

     // STOP NOW 

     fclose(data1);
     exit(0);
}

On trouve des données dans data1_euler3

billaud@sims:~/Essais/bugs$ rm *.txt

billaud@sims:~/Essais/bugs$ ls
Makefile  prog  prog.c

billaud@sims:~/Essais/bugs$ ./prog >texte.txt

billaud@sims:~/Essais/bugs$ ls -l
total 2576
-rw-r--r-- 1 billaud billaud      18 18 avril 09:35 data1_euler3.txt
-rw-r--r-- 1 billaud billaud       0 18 avril 09:35 data2_euler3.txt
-rw-r--r-- 1 billaud billaud       0 18 avril 09:35 data3_euler3.txt
-rw-r--r-- 1 billaud billaud 1313245 18 avril 09:35 data_euler3.txt
-rw-r--r-- 1 billaud billaud     326 18 avril 07:59 Makefile
-rw-r--r-- 1 billaud billaud       0 18 avril 09:35 out_euler3.txt
-rwxr-xr-x 1 billaud billaud   20872 18 avril 09:28 prog
-rw-r--r-- 1 billaud billaud    3659 18 avril 09:27 prog.c
-rw-r--r-- 1 billaud billaud 1284668 18 avril 09:35 texte.txt

billaud@sims:~/Essais/bugs$ more data1_euler3.txt 
0.000000 0.000000

x x x

Il y a peut être un problème à l'exploitation de la sortie de la boucle

             
            } while(r1 > extension_spatiale &&(r2 > extension_spatiale) &&(r3 > extension_spatiale)); //&&(CdtExit));
             
            fprintf(test, "bonjour\n");
             
            if(r1 < extension_spatiale){
                fprintf(data, "NOUVELLE PARTICULE %lf %lf\n", x_0, y_0);
                fprintf(data1, "%lf %lf\n", x_0, y_0);
            }
 
            if(r2 < extension_spatiale)
                fprintf(data2, "%lf %lf\n", x_0, y_0);
            }
 
            if(r3 < extension_spatiale){
                fprintf(data3, "%lf %lf\n", x_0, y_0); 
            }      
     

La négation de  l'inégalilté stricte  r1 > extension_spatiale (qui mériterait des parenthèses pour ressembler à ses copines),  c'est  r1 <= extension_spatiale, une inégalité large.

-
Edité par michelbillaud il y a 13 minutes

Je ne comprends pas pourquoi moi je n'ai rien dans "data1". Alors que je devrais lorsque la première particule finit.

En ce qui concerne la condition : c'est bien r1 > extension_spatiale, je suis sûr de moi sur cette conditon.
Mon problèle vient juste du fichier data1, data2 et data3 où je n'ai aucune données écrites dedans. Visiblement pour toi ce n'est pas le cas.

EDIT !!!!

Si je stop mon programme avec un exit(0) à la fin de la particule comme a fait michelbillaud, j'ai des données dans data1. Mais pas quand je stop brutalement le programme avec un CTRL+C..

-
Edité par Lowloooww 18 avril 2023 à 10:24:35

Quand on fait un printf, le texte à écrire est placé dans un tampon - pour des raisons d'efficacité - qui sera envoyé effectivement  dans le fichier quand

• Le tampon est plein
• Le fichier est fermé par fclose
•  on a fait un fflush.

Si on interrompt le déroulement du programme, il y a un risque qu'une partie des données ne se retrouve pas dans le fichier.

Le tampon doit être de quelques kilo-octets, la taille d'un bloc du disque  au moins.

Tu aurais du nous dire que tu interrompais le programme, c'est un élément pertinent de l'exécution...

Si c'est son mode normal d'utilisation, pense à faire des fflush de temps en temps. Ça ralentira le programme, mais les résultats seront dans le fichier.

Ps préférer  r1*r1*r1  à pow(r1,3.0),  qui risque de passer par des calculs de logarithme et d'exponentielle, là où le job se fait en 2 multiplications. A moins de s'être assuré que le compilateur fait l'optimisation.

Sur du gros calcul qui prend des heures, ça peut avoir son importance.

-
Edité par michelbillaud 18 avril 2023 à 10:57:15

michelbillaud a écrit:

Quand on fait un printf, le texte à écrire est placé dans un tampon - pour des raisons d'efficacité - qui sera envoyé effectivement  dans le fichier quand

• Le tampon est plein
• Le fichier est fermé par fclose
•  on a fait un fflush.

Si on interrompt le déroulement du programme, il y a un risque qu'une partie des données ne se retrouve pas dans le fichier.

Le tampon doit être de quelques kilo-octets, la taille d'un bloc du disque  au moins.

Tu aurais du nous dire que tu interrompais le programme, c'est un élément pertinent de l'exécution...

Si c'est son mode normal d'utilisation, pense à faire des fflush de temps en temps. Ça ralentira le programme, mais les résultats seront dans le fichier.

Ps préférer  r1*r1*r1  à pow(r1,3.0),  qui risque de passer par des calculs de logarithme et d'exponentielle, là où le job se fait en 2 multiplications. A moins de s'être assuré que le compilateur fait l'optimisation.

Sur du gros calcul qui prend des heures, ça peut avoir son importance.

-

Edité par michelbillaud il y a environ 1 heure

Je viens d'essayer en laissant le programme tourner jusqu'à la fin, et tout marche comme il faut. Mais ma question est donc la suivante :
Sachant que je faisais déjà auparavant des arrêts brutals du programme et que les données étaient quand même écrit dans mon fichier, pourquoi maintenant cela ne marche plus ?

Tu as raison, je vais privilégier le r1*r1*r1.

-
Edité par Lowloooww 18 avril 2023 à 12:50:16

Lowloooww a écrit:

michelbillaud a écrit:

Quand on fait un printf, le texte à écrire est placé dans un tampon - pour des raisons d'efficacité - qui sera envoyé effectivement  dans le fichier quand

• Le tampon est plein
• Le fichier est fermé par fclose
•  on a fait un fflush.

Si on interrompt le déroulement du programme, il y a un risque qu'une partie des données ne se retrouve pas dans le fichier.

-

Edité par michelbillaud il y a environ 1 heure

Je viens d'essayer en laissant le programme tourner jusqu'à la fin, et tout marche comme il faut. Mais ma question est donc la suivante :
Sachant que je faisais déjà auparavant des arrêts brutals du programme et que les données étaient quand même écrit dans mon fichier, pourquoi maintenant cela ne marche plus ?

Tu as raison, je vais privilégier le r1*r1*r1.

-
Edité par Lowloooww il y a 14 minutes

Les données étaient partiellement écrites.   Pas ce qui restait en transit dans le tampon au moment de l'interruption.

Pour pow, validation expérimentale.  On compile

#include <math.h>

double cube_avec_pow(double d) {
	return pow(d, 3.0);
}

double cube_avec_multiplication(double d) {
	return d * d * d;
}

avec l'option -O9 (gcc) pour optimiser à donf, et -S pour voir le code généré

billaud@sims:/tmp$ gcc -O9 -S f.c 
billaud@sims:/tmp$ more f.s
	.file	"f.c"
	.text
	.p2align 4
	.globl	cube_avec_pow
	.type	cube_avec_pow, @function
cube_avec_pow:
.LFB0:
	.cfi_startproc
	movsd	.LC0(%rip), %xmm1
	jmp	pow@PLT
	.cfi_endproc
.LFE0:
	.size	cube_avec_pow, .-cube_avec_pow
	.p2align 4
	.globl	cube_avec_multiplication
	.type	cube_avec_multiplication, @function
cube_avec_multiplication:
.LFB1:
	.cfi_startproc
	movapd	%xmm0, %xmm1
	mulsd	%xmm0, %xmm0
	mulsd	%xmm1, %xmm0
	ret
	.cfi_endproc
.LFE1:
	.size	cube_avec_multiplication, .-cube_avec_multiplication
	.section	.rodata.cst8,"aM",@progbits,8
	.align 8
.LC0:
	.long	0
	.long	1074266112
	.ident	"GCC: (Debian 10.2.1-6) 10.2.1 20210110"
	.section	.note.GNU-stack,"",@progbits

Y a pas photo, même si on cause pas assembleur x86 couramment (*)   Dans le premier cas un appel à la fonction de bibliothèque ligne 12 (**), dans l'autre deux multiplications (lignes 23-24).

La même chose s'applique à   pow(x, 0.5) vs.  sqrt(x)

EDIT pendant qu'on y est : il y a une particularité sur tampon de stdout (la sortie standard) : il est aussi expédié quand on lui met un saut de ligne '\n"'. 

(*) il y a de moins en moins de gens qui ont connu Napoléon
(**) avec un "jrst hack" classique, qui consiste à remplacer call + return par  jump. Le return de l'appelé fera revenir au bon endroit directement.

-
Edité par michelbillaud 20 avril 2023 à 12:06:22

michelbillaud a écrit:

(*) il y a de moins en moins de gens qui ont connu Napoléon

On le voit énormément chez les jeunes, sous prétexte qu'il ne faut pas "réinventer la roue" (je déteste ce proverbe), ils ne savent plus du tout comment une roue fonctionne, ça devient une formule magique, sans comprendre ce qu'il se passe en arrière plan au niveau des performances. 

Je suis entièrement d'accord avec toutes les explications concernant ce faux-ami de "pow" qui est plus un piège qu'autre chose

Il y a aussi le problème inverse, ceux qui apprennent avec un prof genre electronique/automatisme qui faisait de l'assembleur sur micro-contrôleur.

Résultat, quand ils se mettent au C, ils se polarisent sur des micro-optimisations souvent douteuses, genre décider de coller des nombres dans des  unsigned char, avant de savoir ce qu'ils vont en faire.  Et ne parlons pas de découper le code en fonctions....

-
Edité par michelbillaud 22 avril 2023 à 10:55:36

@michelbillaud:
Tu as connu ce genre de codeurs en assembleur?
Quand je codais en assembleur, j'étais déjà fainéant ...
J'avais beaucoup de fonctions avec des conventions bien établies sur les registres et de la doc dans le code lui-même.

PierrotLeFou a écrit:

@michelbillaud:
Tu as connu ce genre de codeurs en assembleur?

Pas personnellement, mais je suis tombé sur des polycops clairement rédigés par des gens qui suivaient cette voie et qui n'enseignaient le C que contraints et forcés à devoir suivre la voie du progrès (?), alors qu'avant leur fierté c'était d'arriver à faire rentrer leur prog d'info industrielle dans une rom de 256 octets parce que la 512 coûtait plus cher.

Bref des contraintes dures qu'on peut comprendre, mais ce n'est pas une raison de déformer les débutants avec ça.  Programmer rationnellement d'abord, optimiser ensuite.

-
Edité par michelbillaud 22 avril 2023 à 23:47:57