A supposer qu'une entreprise veuille mettre son parc sous Linux.
Et qu'elle reçoive des documents venant d'Access, Excel,... peut-elle
les lire , les travailler et les renvoyer de manière que le
destinantaire sur produits Microsoft puisse les lire, etc...
?
Et que fait le langage en interne ? Il n'alloue pas de mémoire pour strdata ? Il n'a pas besoin de connaître la longueur de library pour lui concaténer idstr ? La différence c'est que le comportement ici est opaque, tandis qu'en C, il est explicite.
En Pascal, d'aprés ce que j'avais vu sous le débogueur sur SUN (ça ne me rajeunit pas) la chaîne de caractères est stockée comme un nombre (sa longeur) plus les caractères, et non pas comme les caractères, suivis de . Ca permet à tout moment de savoir quelle est la longueur sans avoir besoin de compter les caractères, mais je pense que ça ne change pas grand chose de plus.
Les vrais programmes de la vraie vie sont écrit en C, pas en Pascal.
C'est bien vrai, sauf qu'il y en a en ada, en java etc. donc on ne peut pas être catégorique.
--
Michel TALON
Richard Delorme <abulmo@nospam.fr> wrote:
Et que fait le langage en interne ? Il n'alloue pas de mémoire pour
strdata ? Il n'a pas besoin de connaître la longueur de library pour lui
concaténer idstr ?
La différence c'est que le comportement ici est opaque, tandis qu'en C,
il est explicite.
En Pascal, d'aprés ce que j'avais vu sous le débogueur sur SUN (ça ne
me rajeunit pas) la chaîne de caractères est stockée comme un nombre
(sa longeur) plus les caractères, et non pas comme les caractères,
suivis de . Ca permet à tout moment de savoir quelle est la longueur
sans avoir besoin de compter les caractères, mais je pense que ça ne
change pas grand chose de plus.
Les vrais programmes de la vraie vie sont écrit en C, pas en Pascal.
C'est bien vrai, sauf qu'il y en a en ada, en java etc. donc on ne peut
pas être catégorique.
Et que fait le langage en interne ? Il n'alloue pas de mémoire pour strdata ? Il n'a pas besoin de connaître la longueur de library pour lui concaténer idstr ? La différence c'est que le comportement ici est opaque, tandis qu'en C, il est explicite.
En Pascal, d'aprés ce que j'avais vu sous le débogueur sur SUN (ça ne me rajeunit pas) la chaîne de caractères est stockée comme un nombre (sa longeur) plus les caractères, et non pas comme les caractères, suivis de . Ca permet à tout moment de savoir quelle est la longueur sans avoir besoin de compter les caractères, mais je pense que ça ne change pas grand chose de plus.
Les vrais programmes de la vraie vie sont écrit en C, pas en Pascal.
C'est bien vrai, sauf qu'il y en a en ada, en java etc. donc on ne peut pas être catégorique.
--
Michel TALON
Michel BILLAUD
j writes:
Le Tue, 29 Jun 2004 11:21:28 +0000 (UTC) après l'an de grâce, inspiré(e) (Nicolas George) écrivait la plume légère :
Dissonnance cognitive.
Ouahou ! À défaut d'être compréhensible, ça en jette. je suppose que c'est un argumentum ad jetatum scientatum a la figurum.
A toute fins utiles je rappelle que la notation algébrique standard n'est qu'une convention de même que notre façon de poser les mutliplications, et que ce n'est pas scientifiquement la meilleure, mais juste la plus choisie.
Je serais même pas étonné d'apprendre que la notation polonaise date d'avant les ordinateurs (1920) est justement dans le but d'éviter les parenthèses par un certain Jan Lukasiewicz.
Il me semble que le susnommé n'a pas introduit la notation en question dans le but d'écrire des expressions "pour de vrai".
Quand on lit les bouquins d'algebre ou de logique "debut du XXieme", il y a tres souvent une partie qui définit les expressions formelles (ou les termes) bien-formées comme étant des machins formés de parenthèses, de virgules de symboles etc. C'est ininteressant au possible, c'est de la description purement syntaxique pour dire qu'on a le doit d'écrire f(x,y) mais pas ,x)f(y. Et je vous passe les priorités d'opérateurs.
On peut comprendre que d'éminents logiciens aient essayé de couper à la corvée du couplet obligé sur ce sujet, éventuellement en introduisant des notations qui permettent de se débarasser de ces conneries de faux problèmes de termes syntaxiquement bien formés.
MB
-- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
j <constern@tiOn.net> writes:
Le Tue, 29 Jun 2004 11:21:28 +0000 (UTC) après l'an de grâce,
inspiré(e) george@clipper.ens.fr (Nicolas George) écrivait la plume
légère :
Dissonnance cognitive.
Ouahou ! À défaut d'être compréhensible, ça en jette. je suppose que
c'est un argumentum ad jetatum scientatum a la figurum.
A toute fins utiles je rappelle que la notation algébrique standard
n'est qu'une convention de même que notre façon de poser les
mutliplications, et que ce n'est pas scientifiquement la meilleure,
mais juste la plus choisie.
Je serais même pas étonné d'apprendre que la notation polonaise date
d'avant les ordinateurs (1920) est justement dans le but d'éviter les
parenthèses par un certain Jan Lukasiewicz.
Il me semble que le susnommé n'a pas introduit la notation en question
dans le but d'écrire des expressions "pour de vrai".
Quand on lit les bouquins d'algebre ou de logique "debut du XXieme",
il y a tres souvent une partie qui définit les expressions formelles
(ou les termes) bien-formées comme étant des machins formés de
parenthèses, de virgules de symboles etc. C'est ininteressant au
possible, c'est de la description purement syntaxique pour dire qu'on
a le doit d'écrire f(x,y) mais pas ,x)f(y. Et je vous passe les
priorités d'opérateurs.
On peut comprendre que d'éminents logiciens aient essayé de couper à
la corvée du couplet obligé sur ce sujet, éventuellement en
introduisant des notations qui permettent de se débarasser de ces
conneries de faux problèmes de termes syntaxiquement bien formés.
MB
--
Michel BILLAUD billaud@labri.fr
LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792
351, cours de la Libération http://www.labri.fr/~billaud
33405 Talence (FRANCE)
Le Tue, 29 Jun 2004 11:21:28 +0000 (UTC) après l'an de grâce, inspiré(e) (Nicolas George) écrivait la plume légère :
Dissonnance cognitive.
Ouahou ! À défaut d'être compréhensible, ça en jette. je suppose que c'est un argumentum ad jetatum scientatum a la figurum.
A toute fins utiles je rappelle que la notation algébrique standard n'est qu'une convention de même que notre façon de poser les mutliplications, et que ce n'est pas scientifiquement la meilleure, mais juste la plus choisie.
Je serais même pas étonné d'apprendre que la notation polonaise date d'avant les ordinateurs (1920) est justement dans le but d'éviter les parenthèses par un certain Jan Lukasiewicz.
Il me semble que le susnommé n'a pas introduit la notation en question dans le but d'écrire des expressions "pour de vrai".
Quand on lit les bouquins d'algebre ou de logique "debut du XXieme", il y a tres souvent une partie qui définit les expressions formelles (ou les termes) bien-formées comme étant des machins formés de parenthèses, de virgules de symboles etc. C'est ininteressant au possible, c'est de la description purement syntaxique pour dire qu'on a le doit d'écrire f(x,y) mais pas ,x)f(y. Et je vous passe les priorités d'opérateurs.
On peut comprendre que d'éminents logiciens aient essayé de couper à la corvée du couplet obligé sur ce sujet, éventuellement en introduisant des notations qui permettent de se débarasser de ces conneries de faux problèmes de termes syntaxiquement bien formés.
MB
-- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
Michel BILLAUD
j writes:
En math ce qui doit primer c'est la capacité à manipuler les outils pour obtenir un résultat où la capacité à montrer que l'on est capable de manipuler le formalisme?
La capacité d'élaborer des concepts, des outils et des formalismes utilisables pour résoudre les problèmes qu'on a sous la main ?
MB -- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
j <constern@tiOn.net> writes:
En math ce qui doit primer c'est la capacité à manipuler les outils pour
obtenir un résultat où la capacité à montrer que l'on est capable de
manipuler le formalisme?
La capacité d'élaborer des concepts, des outils et des formalismes
utilisables pour résoudre les problèmes qu'on a sous la main ?
MB
--
Michel BILLAUD billaud@labri.fr
LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792
351, cours de la Libération http://www.labri.fr/~billaud
33405 Talence (FRANCE)
En math ce qui doit primer c'est la capacité à manipuler les outils pour obtenir un résultat où la capacité à montrer que l'on est capable de manipuler le formalisme?
La capacité d'élaborer des concepts, des outils et des formalismes utilisables pour résoudre les problèmes qu'on a sous la main ?
MB -- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
Richard Delorme
Richard Delorme wrote:
Et que fait le langage en interne ? Il n'alloue pas de mémoire pour strdata ? Il n'a pas besoin de connaître la longueur de library pour lui concaténer idstr ? La différence c'est que le comportement ici est opaque, tandis qu'en C, il est explicite.
En Pascal, d'aprés ce que j'avais vu sous le débogueur sur SUN (ça ne me rajeunit pas) la chaîne de caractères est stockée comme un nombre (sa longeur) plus les caractères, et non pas comme les caractères, suivis de . Ca permet à tout moment de savoir quelle est la longueur sans avoir besoin de compter les caractères, mais je pense que ça ne change pas grand chose de plus.
Je savais. C'est aussi le cas en Basic, en Java, ... Même si la longueur de la chaîne est stockée, il a bien fallu la calculer à un moment : lors de la compilation pour les chaines littérales (faisable en C aussi d'ailleurs), ou à l'exécution pour les chaînes lues depuis le clavier ou un fichier. L'avantage de cette méthode est que les utilisations répétées de la longueur de la chaîne sont plus rapides que des appels répétées (évitables en stockant la longueur dans une variable) à strlen() en C, et le défaut de cette méthode est de calculer inutilement la longueur de la chaine si l'on en a pas besoin.
-- Richard
Richard Delorme <abulmo@nospam.fr> wrote:
Et que fait le langage en interne ? Il n'alloue pas de mémoire pour
strdata ? Il n'a pas besoin de connaître la longueur de library pour lui
concaténer idstr ?
La différence c'est que le comportement ici est opaque, tandis qu'en C,
il est explicite.
En Pascal, d'aprés ce que j'avais vu sous le débogueur sur SUN (ça ne
me rajeunit pas) la chaîne de caractères est stockée comme un nombre
(sa longeur) plus les caractères, et non pas comme les caractères,
suivis de . Ca permet à tout moment de savoir quelle est la longueur
sans avoir besoin de compter les caractères, mais je pense que ça ne
change pas grand chose de plus.
Je savais. C'est aussi le cas en Basic, en Java, ...
Même si la longueur de la chaîne est stockée, il a bien fallu la
calculer à un moment : lors de la compilation pour les chaines
littérales (faisable en C aussi d'ailleurs), ou à l'exécution pour les
chaînes lues depuis le clavier ou un fichier. L'avantage de cette
méthode est que les utilisations répétées de la longueur de la chaîne
sont plus rapides que des appels répétées (évitables en stockant la
longueur dans une variable) à strlen() en C, et le défaut de cette
méthode est de calculer inutilement la longueur de la chaine si l'on en
a pas besoin.
Et que fait le langage en interne ? Il n'alloue pas de mémoire pour strdata ? Il n'a pas besoin de connaître la longueur de library pour lui concaténer idstr ? La différence c'est que le comportement ici est opaque, tandis qu'en C, il est explicite.
En Pascal, d'aprés ce que j'avais vu sous le débogueur sur SUN (ça ne me rajeunit pas) la chaîne de caractères est stockée comme un nombre (sa longeur) plus les caractères, et non pas comme les caractères, suivis de . Ca permet à tout moment de savoir quelle est la longueur sans avoir besoin de compter les caractères, mais je pense que ça ne change pas grand chose de plus.
Je savais. C'est aussi le cas en Basic, en Java, ... Même si la longueur de la chaîne est stockée, il a bien fallu la calculer à un moment : lors de la compilation pour les chaines littérales (faisable en C aussi d'ailleurs), ou à l'exécution pour les chaînes lues depuis le clavier ou un fichier. L'avantage de cette méthode est que les utilisations répétées de la longueur de la chaîne sont plus rapides que des appels répétées (évitables en stockant la longueur dans une variable) à strlen() en C, et le défaut de cette méthode est de calculer inutilement la longueur de la chaine si l'on en a pas besoin.
-- Richard
Shmurtz
Le Mon, 28 Jun 2004 09:50:35 +0000, costaclt s'exprimait:
j wrote:
Et perso je trouve que du fortran 77 de physicien encore en vie, est plus une preuve de professionnalisme que du camel ou du lisp d'informaticien univiersitaire qui est à la poubelle.
Et le Forth. Pourquoi il est en rade ce langage ?
Je ne sais pas s'il est en rade, mais il sert pas mal pour de l'embarqué d'après ce que j'ai vu.
Le Mon, 28 Jun 2004 09:50:35 +0000, costaclt s'exprimait:
j wrote:
Et perso je trouve que du fortran 77 de physicien encore en
vie, est plus une preuve de professionnalisme que du camel ou du lisp
d'informaticien univiersitaire qui est à la poubelle.
Et le Forth. Pourquoi il est en rade ce langage ?
Je ne sais pas s'il est en rade, mais il sert pas mal pour de l'embarqué
d'après ce que j'ai vu.
Le Mon, 28 Jun 2004 09:50:35 +0000, costaclt s'exprimait:
j wrote:
Et perso je trouve que du fortran 77 de physicien encore en vie, est plus une preuve de professionnalisme que du camel ou du lisp d'informaticien univiersitaire qui est à la poubelle.
Et le Forth. Pourquoi il est en rade ce langage ?
Je ne sais pas s'il est en rade, mais il sert pas mal pour de l'embarqué d'après ce que j'ai vu.
george
"remy" , dans le message <cbs04o$pe4$, a écrit :
tu propose quoi comme autre solution en java
Moi, je ne connais pas java : je l'enseigne. Tout ce que je peux te dire, c'est que ta solution est quadratique en le nombre d'éléments à concaténer, alors que le même truc en C serait trivialement linéaire. Après, je vois dans l'API java un truc qui s'appelle StringBuffer qui a l'air de faire à peu près ce qu'il faut -- la doc ne précise pas la complexité, mais on espère quand même que c'est linéaire -- mais ça reste sous-optimal (la mémoire sera quand même réallouée plusieurs fois).
"remy" , dans le message <cbs04o$pe4$1@news-reader3.wanadoo.fr>, a
écrit :
tu propose quoi comme autre solution en java
Moi, je ne connais pas java : je l'enseigne. Tout ce que je peux te
dire, c'est que ta solution est quadratique en le nombre d'éléments à
concaténer, alors que le même truc en C serait trivialement linéaire.
Après, je vois dans l'API java un truc qui s'appelle StringBuffer qui a
l'air de faire à peu près ce qu'il faut -- la doc ne précise pas la
complexité, mais on espère quand même que c'est linéaire -- mais ça
reste sous-optimal (la mémoire sera quand même réallouée plusieurs
fois).
Moi, je ne connais pas java : je l'enseigne. Tout ce que je peux te dire, c'est que ta solution est quadratique en le nombre d'éléments à concaténer, alors que le même truc en C serait trivialement linéaire. Après, je vois dans l'API java un truc qui s'appelle StringBuffer qui a l'air de faire à peu près ce qu'il faut -- la doc ne précise pas la complexité, mais on espère quand même que c'est linéaire -- mais ça reste sous-optimal (la mémoire sera quand même réallouée plusieurs fois).
george
JKB , dans le message , a écrit :
Votre question n'a aucun sens.
Précisément ce que je veux souligner : la distinction entre compilé et interprétée n'est pas pertinente.
Printf est géré par le C, donc interprété ou compilé selon l'implantation du langage (il existe des interpréteurs C)...
Mais même si le programme est compilé, la chaîne de format de printf est interprétée par la fonction printf elle-même. Sauf si le compilateur est très malin et optimise certains cas évidents. Etc.
Révisez vos définitions. L'assembleur n'est pas un compilateur, de même que la compilation ne se réduit pas à l'assemblage.
Et alors ?
JKB , dans le message <slrnce2v3g.te.bertrand@grossebaf.systella.fr>, a
écrit :
Votre question n'a aucun sens.
Précisément ce que je veux souligner : la distinction entre compilé et
interprétée n'est pas pertinente.
Printf est géré par le C, donc interprété ou compilé
selon l'implantation du langage (il existe des interpréteurs C)...
Mais même si le programme est compilé, la chaîne de format de printf est
interprétée par la fonction printf elle-même. Sauf si le compilateur est
très malin et optimise certains cas évidents. Etc.
Révisez vos définitions. L'assembleur n'est pas un compilateur, de
même que la compilation ne se réduit pas à l'assemblage.
Précisément ce que je veux souligner : la distinction entre compilé et interprétée n'est pas pertinente.
Printf est géré par le C, donc interprété ou compilé selon l'implantation du langage (il existe des interpréteurs C)...
Mais même si le programme est compilé, la chaîne de format de printf est interprétée par la fonction printf elle-même. Sauf si le compilateur est très malin et optimise certains cas évidents. Etc.
Révisez vos définitions. L'assembleur n'est pas un compilateur, de même que la compilation ne se réduit pas à l'assemblage.
Et alors ?
george
Est-ce que c'est vraiment indispensable, le quoted-printable ?
j , dans le message , a écrit :
C'est aussi la raison pour laquelle Bourbaki a décidé de shunter la géométrie comme manière d'apprendre les maths et remplacer cela par l'apprentissage des théories ensemblistes : raison officielle :
Pour mémoire, Bourbaki était initialement un canular.
En math ce qui doit primer c'est la capacité à manipuler les outils pour obtenir un résultat où la capacité à montrer que l'on est capable de manipuler le formalisme?
Le plus important, en maths, c'est la rigueur. Sans la rigueur, on ne peut aller nulle part. S'il faut utiliser une notation plus restrictive pour forcer les élèves débutants à être rigoureux, c'est dommage, mais c'est comme ça.
Tu es contre le RPN qui est plus simple (car moins trompeur que les parenthèses)
Tu avances cet argument, mais il n'y a rien derrière. Prenons un cas trivial :
2 × (x + y)
2 x y + ×
Il me semble que la différence de lisibilité saute aux yeux. Tiens, dis-moi, comment parses-tu :
x y z f g
Faut-il le lire « g(x, f(y, z)) », ou bien « g(x, y, f(z)) » ? Ou peut-être « g(f(x, y, z)) » ? À moins que ce ne soit « g(f(z), y(x) » ?
mais contre-intuitif, et et tu es pour la notation de Leibnitz parce qu'elle est inuitive (donc soit-disant trompeuse) ?
Je suis favorable à l'utilisation de cette notation _pour des élèves n'ayant pas encore acquis la rigueur et la maîtrise des concepts nécessaire à ne pas se prendre les pieds dans le tapie_. Nuance. Quand il s'agit de vrais calculs, ce n'est pas pareil.
Soit dit en passant, le professeur Gleick (épistémologue) écorne la raison officielle de l'utilisation de la théorie des ensembles pour l'apprentissage.
Il faudrait remettre tes pendules à l'haure, on n'utilise pas la théorie des ensembles pour l'apprentissage.
Selon lui, l'école mathématique française bien représentée à normale aurait été un peu énervée par Poincaré (le dernier grand mathématicien français)
Ce troll minable ne mérite même pas d'être relevé.
Est-ce que c'est vraiment indispensable, le quoted-printable ?
j , dans le message <20040629164856.2744ead6@osmonda.prive.jul>, a
écrit :
C'est aussi la raison pour laquelle Bourbaki a décidé de shunter la
géométrie comme manière d'apprendre les maths et remplacer cela par
l'apprentissage des théories ensemblistes : raison officielle :
Pour mémoire, Bourbaki était initialement un canular.
En math ce qui doit primer c'est la capacité à manipuler les outils pour
obtenir un résultat où la capacité à montrer que l'on est capable de
manipuler le formalisme?
Le plus important, en maths, c'est la rigueur. Sans la rigueur, on ne
peut aller nulle part. S'il faut utiliser une notation plus restrictive
pour forcer les élèves débutants à être rigoureux, c'est dommage, mais
c'est comme ça.
Tu es contre le RPN qui est plus simple (car moins trompeur que les
parenthèses)
Tu avances cet argument, mais il n'y a rien derrière. Prenons un cas
trivial :
2 × (x + y)
2 x y + ×
Il me semble que la différence de lisibilité saute aux yeux. Tiens,
dis-moi, comment parses-tu :
x y z f g
Faut-il le lire « g(x, f(y, z)) », ou bien « g(x, y, f(z)) » ? Ou
peut-être « g(f(x, y, z)) » ? À moins que ce ne soit « g(f(z), y(x) » ?
mais contre-intuitif, et et tu es pour la notation de
Leibnitz parce qu'elle est inuitive (donc soit-disant trompeuse) ?
Je suis favorable à l'utilisation de cette notation _pour des élèves
n'ayant pas encore acquis la rigueur et la maîtrise des concepts
nécessaire à ne pas se prendre les pieds dans le tapie_. Nuance. Quand
il s'agit de vrais calculs, ce n'est pas pareil.
Soit dit en passant, le professeur Gleick (épistémologue) écorne la
raison officielle de l'utilisation de la théorie des ensembles pour
l'apprentissage.
Il faudrait remettre tes pendules à l'haure, on n'utilise pas la théorie
des ensembles pour l'apprentissage.
Selon lui, l'école mathématique française bien
représentée à normale aurait été un peu énervée par Poincaré (le dernier
grand mathématicien français)
Ce troll minable ne mérite même pas d'être relevé.
Est-ce que c'est vraiment indispensable, le quoted-printable ?
j , dans le message , a écrit :
C'est aussi la raison pour laquelle Bourbaki a décidé de shunter la géométrie comme manière d'apprendre les maths et remplacer cela par l'apprentissage des théories ensemblistes : raison officielle :
Pour mémoire, Bourbaki était initialement un canular.
En math ce qui doit primer c'est la capacité à manipuler les outils pour obtenir un résultat où la capacité à montrer que l'on est capable de manipuler le formalisme?
Le plus important, en maths, c'est la rigueur. Sans la rigueur, on ne peut aller nulle part. S'il faut utiliser une notation plus restrictive pour forcer les élèves débutants à être rigoureux, c'est dommage, mais c'est comme ça.
Tu es contre le RPN qui est plus simple (car moins trompeur que les parenthèses)
Tu avances cet argument, mais il n'y a rien derrière. Prenons un cas trivial :
2 × (x + y)
2 x y + ×
Il me semble que la différence de lisibilité saute aux yeux. Tiens, dis-moi, comment parses-tu :
x y z f g
Faut-il le lire « g(x, f(y, z)) », ou bien « g(x, y, f(z)) » ? Ou peut-être « g(f(x, y, z)) » ? À moins que ce ne soit « g(f(z), y(x) » ?
mais contre-intuitif, et et tu es pour la notation de Leibnitz parce qu'elle est inuitive (donc soit-disant trompeuse) ?
Je suis favorable à l'utilisation de cette notation _pour des élèves n'ayant pas encore acquis la rigueur et la maîtrise des concepts nécessaire à ne pas se prendre les pieds dans le tapie_. Nuance. Quand il s'agit de vrais calculs, ce n'est pas pareil.
Soit dit en passant, le professeur Gleick (épistémologue) écorne la raison officielle de l'utilisation de la théorie des ensembles pour l'apprentissage.
Il faudrait remettre tes pendules à l'haure, on n'utilise pas la théorie des ensembles pour l'apprentissage.
Selon lui, l'école mathématique française bien représentée à normale aurait été un peu énervée par Poincaré (le dernier grand mathématicien français)
Ce troll minable ne mérite même pas d'être relevé.
talon
Nicolas George wrote:
Le plus important, en maths, c'est la rigueur. Sans la rigueur, on ne peut aller nulle part. S'il faut utiliser une notation plus restrictive pour forcer les élèves débutants à être rigoureux, c'est dommage, mais c'est comme ça.
Ce que tu dis là est absolument inepte. La rigueur n'a aucun intérêt sauf pour les débutants et les pédants. Le coeur des mathématiques c'est l'imagination et l'invention.
--
Michel TALON
Nicolas George <george@clipper.ens.fr> wrote:
Le plus important, en maths, c'est la rigueur. Sans la rigueur, on ne
peut aller nulle part. S'il faut utiliser une notation plus restrictive
pour forcer les élèves débutants à être rigoureux, c'est dommage, mais
c'est comme ça.
Ce que tu dis là est absolument inepte. La rigueur n'a aucun intérêt
sauf pour les débutants et les pédants. Le coeur des mathématiques c'est
l'imagination et l'invention.
Le plus important, en maths, c'est la rigueur. Sans la rigueur, on ne peut aller nulle part. S'il faut utiliser une notation plus restrictive pour forcer les élèves débutants à être rigoureux, c'est dommage, mais c'est comme ça.
Ce que tu dis là est absolument inepte. La rigueur n'a aucun intérêt sauf pour les débutants et les pédants. Le coeur des mathématiques c'est l'imagination et l'invention.
--
Michel TALON
george
Michel Talon, dans le message <cbsbe1$bff$, a écrit :
Ce que tu dis là est absolument inepte. La rigueur n'a aucun intérêt sauf pour les débutants et les pédants.
Et, oh surprise, c'est de débutants qu'il est question.
Michel Talon, dans le message <cbsbe1$bff$1@asmodee.lpthe.jussieu.fr>, a
écrit :
Ce que tu dis là est absolument inepte. La rigueur n'a aucun intérêt
sauf pour les débutants et les pédants.
Et, oh surprise, c'est de débutants qu'il est question.
