Salut, je recher un algo d’inversion de matrices 44 en C,
sinon au pire est ce que quelqu’un qui a fait des maths plus recemment que moi peut me redonner la formule por calculer l’inverse d’une matrice.
PS: comment on calcule la matrice des cofacteurs d’une matrice???
Merci d’avance
Jim
[quote]En passant, je viens de retrouver la norme du langage C : ISO/IEC 9899:1999
et pour notre ami le C++ : ISO/IEC 14882:1998
Valà, valà…
PS: Si quelqu’un avait les PDF ou bien les url gratuites, ça m’intéresse BEAUCOUP !!!
[Edité le 26/12/2002 par xentyr][/quote]
Ce ne sont pas les références dont je me souvenais et après avoir un peu cherché j’ai retrouvé la référence du document que j’avais “écorché” : ANSI X3-159 (pour ce qui est du C). M’enfin, en fouillant un peu plus on s’aperçoit que Xentyr a tout bon aussi :pleure: . Voici un tout petit historique :
1987 début de la normalisation du langage par l’IEEE avec constitution d’un comité appelé : X3 J-11.
1989 sortie du premier document normalisé appelé norme ANSI X3-159.
1990 réalisation du document final normalisé auprès de l’ISO : ISO/IEC 9899
On trouve d’autres parts quelques informations intéressantes :
Les spécifications de la norme NCTTI-8 concernant le langage de programmation C sont les mêmes que celles qui sont énoncées dans la norme ISO 9899:1990 qui est identique à la norme ANSI X3.159-1987.
Cette norme entre en vigueur le 6 février 1991.
Je pense qu’il est bon de connaître les deux références, ça fait partie de la culture. Vous aurez noté que cette norme est vraiment très récente.
EDIT : Nighty :tusors:
[Edité le 26/12/2002 par Moktar]
tient, bizarre, personne ne m’a pourri sur mon code???,
voila du code tres tres sale, fait par moi même, dans lotus designer, je vous rassure, dans flash, je programme mieux, avec la méthode de moktar 
@If(Technicien = Null;@Prompt([OK];« erreur »;« le champ 'Par’n’a pas été remplie » );Technicien1 = Null;@Prompt([OK];« erreur »;« le champ ‹ transmis à › na pas été remplie » );Nom = Null;@Prompt([OK];« erreur »;« le champ ‹ Nom › n’a pas été remplie » );TypeReclamation = Null;@Prompt([OK];« erreur »;« le champ ‹ Type de réclamation › n’a pas été remplie » );Services = Null;@Prompt([OK];« erreur »;« le champ ‹ Service concerné › n’a pas été remplie » );Urgency = Null;@Prompt([OK];« erreur »;« le champ ‹ Importance › n’a pas été remplie » );Ville = Null;@Prompt([OK];« erreur »;« le champ ‹ Ville › n’a pas été remplie » );
@Do(
@Command([FileSave]);
@If (@Prompt( [YESNO] ; « Envoi d’un mémo » ; « Voulez-vous envoyer un Mail à « +Technicien1+ » pour le prévenir de la plainte »);
@If(Techniciencpi = Null;@MailSend(Technicien1;"";"";« Nouvelle réclamation transmise par " + Technicien+ » pour « +Technicien1; »";" cliquer sur le lien pour accéder à la réclamation « ;[IncludeDoclink]);
@Do(
@MailSend(Technicien1; »";"";« Nouvelle réclamation transmise par " + Technicien+ » pour « +Technicien1; »";" cliquer sur le lien pour accéder à la réclamation « ;[IncludeDoclink]);
@MailSend(Techniciencpi; »";"";« copie pour info transmise par " + Technicien+ » pour « +Techniciencpi; »";" ATTENTION, vous ne devez pas gérer cette réclamation, il s’agit simplement d’une copie pour info. Cliquer sur le lien pour accéder à la réclamation ";[IncludeDoclink]) & @Prompt( [OK] ; « Information » ; « La réclamation a été transmise »)));
@Prompt( [OK] ; « Information » ; « La réclamation n’a pas été transmise »));
@Command([FileCloseWindow])))
En passant, je viens de retrouver la norme du langage C : ISO/IEC 9899:1999
et pour notre ami le C++ : ISO/IEC 14882:1998
Valà, valà…
PS: Si quelqu’un avait les PDF ou bien les url gratuites, ça m’intéresse BEAUCOUP !!!
[Edité le 26/12/2002 par xentyr]
héhé bon, on fait bien dériver ce thread… mmmfff SAIMAL, pourtant c’est intéressant.
Je suis d’accord que dans les gros projets on n’impose jamais une écriture d’accolade sur une ligne mais on ne dit pas de les mettre après les instructions, non plus. 
Pour ce qui est de la convention d’écriture, elle n’ait pas décrite par la norme C ni C++, d’ailleurs les éditions du Kernighan & Ritchie ou du Stroustrup ne sont pas la norme :). La norme est décrite dans un document X.?? (je ne me souviens plus du n° désolé) et il n’y a aucune convention d’écriture dans les éditions sus-cités, seuls les exemples dans le K&R (par exemple) montre une syntaxe. Certaines éditions de documents décrivant une implémentation de langage propose des recommandations mais ce n’est pas la norme. Par exemple des bouquins aux éditions Microsoft Press recommandent des syntaxes de nommages et d’écritures mais cela reste des recommandations propres à chaque éditeur. On y trouve d’ailleurs, entre-autres, les deux façons de faire. La lisibilité est clairement subjective mais dès lors qu’on écrit du code en ayant cette lisibilité à l’esprit, c’est déjà très bien. Ensuite c’est une affaire de goût.
J’ai déjà vu des trucs qui m’apparaissent horrible mais pour d’autres qui semblent être très bien. Par exemple :
for(i=0; i
[quote]le fait que son for ait pas de {} parceque if /else dedans est un peu douteux[/quote]Héhé, tu connais mon goût pour la provocation… C’était un exemple extrême pour montrer ce que permettait ma convention mais effectivement dans ce cas, l’omission des accolades est facultative et ne me choque donc pas… J’aurais normalement écrit :
[quote] for ( i = 0 ; i < 2 ; i++ ) {
if ( i ) {
printf( "
j’ai pas vu le temps passé!!!
" ) ;
} else {
printf( “Je suis en vacances depuis une semaine et” ) ;
}
}[/quote]Voilà :pleure:
PS : Snifff, j’ai pas retrouvé le doc, mais puisque tu dis qu’en fait, c’est une partie d’une vraie convention…
Pareil que Xentyr. Sa convention de codage est la plus lisible. Il prend un peu des libertes et le fait que son for ait pas de {} parceque if /else dedans est un peu douteux. mais mettre “} else {” sur une seule ligne est indispensable a mon avis… La convention est un peu plus complexe a mettre en place et a respecter puisque qu’a a quelque regles particulieres mais c’est celle qui est recommandee par ANSI C et l’inventeur de C++. Cf le bouquin de Stroustrup.
La plupart des gros projets que je vois sont codes en respectant des conventions precises et pas un seul ne demande a mettre les crochets seul sur une ligne pour les cas comme le if {} else {}…
M’enfin… chacun sa merde hein…
[Edité le 21/12/2002 par GloP]
[quote]Le principal toi, Xentyr (cf argument le plus fort) c’est de voir suffisamment de lignes à l’écran pour pouvoir avoir le maximum d’infos « visible ». AHHAM. Quand tu as un bouquin entre les mains, tu ne te souviens pas de ce que tu as lu sur la page précédente ? impossible de te souvenir du context ? sachant qu’en dev, l’indentation aide au contexte, hein ;). Alors que si un bouquin ou une documentation technique (pour rester dans le context) est très condensée, on ne « voit » rien trouvais-je… il est moins important d’avoir un ensemble d’infos condensées que de les avoir lisibles et aérées (bien mises en page).[/quote]Rhhhhho tu lis du code comme tu lis un bouquin ! C’est bizarre, mais moi, c’est la doc que je lis comme je lis un bouquin… Argument irrecevable sauf si tu n’as pas de doc. Mais dans ce cas, la convention ne t’aidera pas. Je n’ai pas dit qu’il ne fallait pas aérer, hein. Tu peux, voire tu DOIS sauter des lignes entre tes étapes d’algo d’une fonction… Pour reprendre ta comparaison, je préfère un bouquin avec des interlignes simples séparant des paragraphes plutôt qu’un bouquin avec plein de petits paragraphes qui perdront la structure du programme… Mais je le répète, je changerai peut-être d’avis une fois au travail (c’est-à-dire le 13 janvier yeahhhhhh :))
[quote]Contrairement à ce que tu dis, un bloc peut être déclaré comme ça en plein milieu du code, sans intructions (au-dessus pour moi et à gauche pour toi :P). Bah oui c’est le moyen de faire un traitement très local et d’y déclarer des variables qui ne seront locale qu’à ce bloc (empilement en début de bloc et dépilement en fin de bloc). Tu mettrais où cette accolade ouvrante ? ;)[/quote]Dans ce cas, j’applique le même traitement qu’aux fonctions car si traitement local il y a, on devra mettre un petit comment expliquant pourquoi, de plus ce bloc est plus important qu’un if donc je l’espace plus Au fait, je vais peut-être t’étonner mais oui, je le savais qu’on pouvait mettre un bloc n’importe où 
[quote]Aller, une dernière remarque. J’ai fait parti de très grosses équipes de dev avec des projets multi-sites et internatinaux (France*2, Allemagne, Inde et Angleterre) inutile de dénombrer le nombre de lignes de code …/… et l’expérience que j’en ai n’est pas celle que tu décris… AHAAMM… mais peut-être pouvons-nous avoir une perception des choses différente. Je dois d’ailleurs reconnaître qu’on pouvait trouver des gens qui codaient comme toi dans ces équipes. Malheureusement, plus je développe et plus je trouve que les gens codent comme des porcs. Je ne parle pas de ta façon de coder hein, mais du manque de sensibilité à la lisibilité que je rencontre de plus en plus. C’est pour ça que je suis attaché à la syntaxe. Quand tu as 1 million de ligne de code (même plus, c’est clair) ce n’est pas le tassement qui va t’aider à maîtriser des sous-ensembles…[/quote]Alors que tu aères TOUT, je tasse ce qui ne mérite pas d’être développé, nuance (cf + haut).
J’ai aussi eu droit à des projets honnêtes (de 900 000 lignes). Bon, je n’ai pas ton XP, c’est clair, mais honnêtement, peut-être était-il bien écrit, mais je n’ai jamais eu à jongler qu’avec au grand max 10 000 lignes à la fois… Et si le bonhomme ne code pas comme un porc, je ne vois pas en quoi ma méthode est - lisible que la tienne, sans qu’il y ait de combat d’arrière-garde, hein (j’ai 22 balais et ça fait que 10 ans que je code, donc je ne suis pas un vieux ;)). Au contraire, quand tu as 40 lignes à l’écran dont 10 servent à l’aération avec ma méthode, alors que la tienne en met 15 (au jugé ;)), je trouve que ma méthode, si le mec est scrupuleux, c’est-à-dire qu’il met des commentaires judicieux, qu’il saute une ligne entre les étapes,… est plus efficace que la tienne. Bien sûr si le mec code comme un porc, il code comme un porc, hein, qu’il utilise ta convention ou bien la mienne… On ne se convaincra pas mutuellement alors héhé
(Vive les dérives intéressantes tiens)
Arff l’argument fatal ou plutôt les arguments, je croyais les avoir donné . Je connais les tiens, « les vieux » ont souvent ceux-là mais je n’y adhère pas 
. Remarque, je ne cherchais pas à te convaincre, l’expérience m’a montré que c’est quasiment impossible de faire changer les gens en dev, j’ai dit quasiment hein :).
Le principal pour toi, Xentyr (cf argument le plus fort) c’est de voir suffisamment de lignes à l’écran pour pouvoir avoir le maximum d’infos « visible ». AHHAM. Quand tu as un bouquin entre les mains, tu ne te souviens pas de ce que tu as lu sur la page précédente ? impossible de te souvenir du context ? sachant qu’en dev, l’indentation aide au contexte, hein :). Alors que si un bouquin ou une documentation technique (pour rester dans le context) est très condensée, on ne « voit » rien trouvais-je… il est moins important d’avoir un ensemble d’infos condensées que de les avoir lisibles et aérées (bien mises en page).
Contrairement à ce que tu dis, un bloc peut être déclaré comme ça en plein milieu du code, sans intructions (au-dessus pour moi et à gauche pour toi ;)). Bah oui c’est le moyen de faire un traitement très local et d’y déclarer des variables qui ne seront locale qu’à ce bloc (empilement en début de bloc et dépilement en fin de bloc). Tu mettrais où cette accolade ouvrante ?
Non non, c’est mieux comme je l’ai dit AHHAMM et chacun sait « qu’un bon développeur, c’est quelqu’un qui code comme moi » .
Aller, une dernière remarque. J’ai fait parti de très grosses équipes de dev avec des projets multi-sites et internatinaux (France*2, Allemagne, Inde et Angleterre) inutile de dénombrer le nombre de lignes de code …/… et l’expérience que j’en ai n’est pas celle que tu décris… AHAAMM… mais peut-être pouvons-nous avoir une perception des choses différente. Je dois d’ailleurs reconnaître qu’on pouvait trouver des gens qui codaient comme toi dans ces équipes. Malheureusement, plus je développe et plus je trouve que les gens codent comme des porcs. Je ne parle pas de ta façon de coder hein, mais du manque de sensibilité à la lisibilité que je rencontre de plus en plus. C’est pour ça que je suis attaché à la syntaxe. Quand tu as 1 million de ligne de code (même plus, c’est clair) ce n’est pas le tassement qui va t’aider à maîtriser des sous-ensembles…
[Edité le 20/12/2002 par Moktar]
[quote]Xentyr, pour l’indentation utilise ALT 255… c’est très lourd mais au moins ça permet d’avoir du code lisible :)[/quote]Merkkkii, j’avais oublié
[quote]En parlant de code lisible… t’ainnn les ‹ { › en fin de ligne c’est nul, bon ok c’est un avis mais pour argumenter :
je note que la définition de l’opérateur ne respecte pas cette règle (accolade ouvrante en regard de l’accolade fermante… c’est beauuu )
que les accolades définissent des blocs donc ce sont elles qui doivent être en regard et non pas l’accolade fermante en regard du if ou du for …
les environnements de développements et même les éditeurs rudimentaires (Vi, …) offrent des services de correspondances d’accolade ouvrante accolade fermante et non pas accolade fermante ‹ if › ou ‹ for › ou …[/quote]
Alors alors, je ne suis pas le seul à coder de cette manière. Un certain Linus aussi ;). Bon moi aussi, je vais argumenter mais tout d’abord ma version :
int main ()
{
int i;
for( i = 0 ; i
[quote]oula moi aussi, moi aussi
cout
oula moi aussi, moi aussi
cout
Xentyr, pour l’indentation utilise ALT 255… c’est très lourd mais au moins ça permet d’avoir du code lisible
En parlant de code lisible… t’ainnn les ‹ { › en fin de ligne c’est nul, bon ok c’est un avis mais pour argumenter :
je note que la définition de l’opérateur ne respecte pas cette règle (accolade ouvrante en regard de l’accolade fermante… c’est beauuu )
que les accolades définissent des blocs donc ce sont elles qui doivent être en regard et non pas l’accolade fermante en regard du if ou du for …
les environnements de développements et même les éditeurs rudimentaires (Vi, …) offrent des services de correspondances d’accolade ouvrante accolade fermante et non pas accolade fermante ‹ if › ou ‹ for › ou …
PS :
dans le code de « init permutation vect and solution matrix » on voit un « for » incluant un « if then else » mais sans ‹ { › ‹ } ›… mhhhhh ok c’est correct mais non lisible, il faut privilégier la lisibilité…
voilààà mes remarques sur la forme
[Edité le 20/12/2002 par Moktar]
Si vous pouviez arrêter de vous battre pour des variantes du même algorithme… Ca en est ridicule
PS: Pour que mon post ne serve pas à rien…
inline Matrix Matrix::operator! () const
{
int ipivot, isave ;
int jrow, krow, kcol ;
int i, j ;
int perm[4] ;
double a ;
Matrix sol ;
Matrix p( *this ) ;
// --- init permutation vect and solution matrix ---
for ( i=0; ibonjour les intellos ;), whaou des matrices
bon je sais faire a la main avec le pivot de gauss, et puis aussi les aplications entre 2 bases differents, et puis les matrice de passages… en ce qui concerne l’algo pour calculer l’inverse d’une matrice avec le pivot ben sa doit pas etre super compliqué, vu qu’a la main c’est super simple…
bon pas la peine de me demander, je HAIS les math
EXCEPTION ON
La belotte coinchée ?? heuu tu veux dire la manille alors ? avec le 10 maître puis l’as (le manillon), le roi … etc ?
EXCEPTION OFF
Je suis bien incapable de répondre aux interrogations sur les matrices… et ça m’énerve 
ça me donne envie de relire mes cours (les ai-je encore ?) en tous cas mes bouquins de maths. Plutôt que de lire un bouquin cul cul la praline je préfère très nettement une doc technique (un bouquin de math faisant partie de cet ensemble).
Amusez-vous bien :mad:
[quote][quote]aahh je viens de relire son truc, oui ok mais de toute maniere il utilise le det de la totomatrice alors pourquoi ne pas directement parler de co-facteur ?[/quote]parcequ’il fallait bien que j’introduise la totomatrice pour expliquer mon calcul du det de co-facteur…
[/quote]
s’il connassait le co-facteur c’etait pas indispensable, mais bon on détaille jamais trop …
[quote]aahh je viens de relire son truc, oui ok mais de toute maniere il utilise le det de la totomatrice alors pourquoi ne pas directement parler de co-facteur ?[/quote]parcequ’il fallait bien que j’introduise la totomatrice pour expliquer mon calcul du det de co-facteur…
non le cofacteur est le déterminant de la totomatrice. 
[/quote]
aahh je viens de relire son truc, oui ok mais de toute maniere il utilise le det de la totomatrice alors pourquoi ne pas directement parler de co-facteur ?
[Edité le 19/12/2002 par jul]