« Sans compter qu'il me semble que le symbole pour les produit vectoriel, un X rigolo, pas une etoile?
Reste toujours que le * ne donne aucune information sur ce qu'a voulu faire le mec qui a ecrit le code. »
Je regarde si le résultat est un scalaire, si c’est un vecteur ou s’il applique le même opérateur à des matrices ou seulement à des vecteurs. Ça permet de savoir l’opérateur qui a été choisi d’assigner au signe « * ». Bien sûr l’opérateur n’a pas la même signification en fonction des opérandes, ce n’est pas un problème en soit. En cas de méfiance envers celui qui a écrit le code il faudra aller lire la doc. voir le source. De toute façon il y a toujours ambiguïté sur les opérateurs matriciels, il faut les définir si le contexte n’aide pas, une fois ceci fait, on ne s’amuse pas à les redéfinir à toutes les lignes parce que ça n’aide pas la lecture (on l’écrit même pas, l’écriture ABC pour A, B, C des matrices n×ばつn n’a jamais choqué aucun mathématicien...). Pourquoi en serait-il autrement dans un code informatique ?
« Quand je lit list.add(list) ou list.addAll(list), je sais tres exactement ce que le mec qui a ecrit le code a voulu faire. »
Pas moi. Typiquement le cas foireux ; le texte n’apporte pas plus d’information qu’un « + ».
— add c’est pour ajouter des éléments à la fin d’une liste ?
— addAll c’est pour faire une réduction, c’est-à-dire la somme des éléments de mes listes ?
— Ou alors add fait l’addition élément par élément ;
— à moins que ce soit le addAll, le All étant là pour bien préciser qu’on travaille sur tous les éléments.
— Plus fou : c’est pour ajouter une dimension à une liste pour en faire un tableau 2d ?
Bref : tu sais ce que le mec qui a écrit le code a voulu faire. Espère juste que ça ne sera jamais moi, car je risque de ne pas attacher la même signification à ces méthodes. Loupé : pour savoir ce que fait la méthode il faut aller lire sa doc. comme pour la surcharge du « + ».
« Quand je lit list + list, j'en sais trop rien. »
Pas moi, je regarde les opérandes, si je manipule des nombres ce sera l’addition élément par élément mathématique, sinon la concaténation. Mais ce n’est que ma convention. En tout cas tu n’en sais ni plus ni moins que dans le cas précédent.
« Pour ne pas avoir a ecrire equals? »
Et pour ne pas avoir à le lire, perso., quelqu’un qui ne fait pas de Java, j’ai halluciné sur l’histoire des Integer simplement parce que je code pour du calcul et que j’ai été formé pour du C.
« C'est une operation faite par un objet sur un autre objet. Pas une operation mathematique. »
Oui je suis d’accord, alors donnons aux signes mathématiques la sémantique qu’ils ont toujours eu : la mathématique, pas la signification informatique, par exemple == de deux entiers compare par valeur, ; les histoires de références, et donc d’adresse en mémoire, ne concernent que l’informatique bas-niveau : méthodes adaptées pour.
Je dirai que tout ceci n’est qu’une histoire de convention, et que tu dis que la tienne vaut mieux, c’est totalement faux. Pour quelqu’un qui n’a pas de formation poussée à Java mais qui connaît un peu les maths je t’ai montré que c’est tout le contraire. Le coup du « add(All) » me semble même très dangereux, car tu fais l’hypothèse que le mec qui a écrit ça a suivi ta convention, par contre quand c’est un « + » tu n’acceptes pas que le mec ait pu suivre ta convention : ton raisonnement est biaisé car au final ton argument est identique dans un cas comme dans l’autre. Il faut absolument vérifier que la méthode fasse ce qu’on lui demande.
Le Java interdit de redéfinir + & co, très bien, du coup on va définir des méthodes qui vont bien, mais ça ne fait que déplacer le problème sans le résoudre, car les noms des méthodes suffisent rarement à décrire ce qu’elle font : sinon pourquoi on les documenterait ?
PS : c’est quoi le problème avec les parenthèse ? De toute manière la multiplication matricielle est associative.
[^] # Re: Utiliser les tty
Posté par nicolas . En réponse à la dépêche Patch pour le noyau Linux améliorant l'interactivité entre les applications console et Xorg. Évalué à 6.
Reste toujours que le * ne donne aucune information sur ce qu'a voulu faire le mec qui a ecrit le code. »
Je regarde si le résultat est un scalaire, si c’est un vecteur ou s’il applique le même opérateur à des matrices ou seulement à des vecteurs. Ça permet de savoir l’opérateur qui a été choisi d’assigner au signe « * ». Bien sûr l’opérateur n’a pas la même signification en fonction des opérandes, ce n’est pas un problème en soit. En cas de méfiance envers celui qui a écrit le code il faudra aller lire la doc. voir le source. De toute façon il y a toujours ambiguïté sur les opérateurs matriciels, il faut les définir si le contexte n’aide pas, une fois ceci fait, on ne s’amuse pas à les redéfinir à toutes les lignes parce que ça n’aide pas la lecture (on l’écrit même pas, l’écriture ABC pour A, B, C des matrices n×ばつn n’a jamais choqué aucun mathématicien...). Pourquoi en serait-il autrement dans un code informatique ?
« Quand je lit list.add(list) ou list.addAll(list), je sais tres exactement ce que le mec qui a ecrit le code a voulu faire. »
Pas moi. Typiquement le cas foireux ; le texte n’apporte pas plus d’information qu’un « + ».
— add c’est pour ajouter des éléments à la fin d’une liste ?
— addAll c’est pour faire une réduction, c’est-à-dire la somme des éléments de mes listes ?
— Ou alors add fait l’addition élément par élément ;
— à moins que ce soit le addAll, le All étant là pour bien préciser qu’on travaille sur tous les éléments.
— Plus fou : c’est pour ajouter une dimension à une liste pour en faire un tableau 2d ?
Bref : tu sais ce que le mec qui a écrit le code a voulu faire. Espère juste que ça ne sera jamais moi, car je risque de ne pas attacher la même signification à ces méthodes. Loupé : pour savoir ce que fait la méthode il faut aller lire sa doc. comme pour la surcharge du « + ».
« Quand je lit list + list, j'en sais trop rien. »
Pas moi, je regarde les opérandes, si je manipule des nombres ce sera l’addition élément par élément mathématique, sinon la concaténation. Mais ce n’est que ma convention. En tout cas tu n’en sais ni plus ni moins que dans le cas précédent.
« Pour ne pas avoir a ecrire equals? »
Et pour ne pas avoir à le lire, perso., quelqu’un qui ne fait pas de Java, j’ai halluciné sur l’histoire des Integer simplement parce que je code pour du calcul et que j’ai été formé pour du C.
« C'est une operation faite par un objet sur un autre objet. Pas une operation mathematique. »
Oui je suis d’accord, alors donnons aux signes mathématiques la sémantique qu’ils ont toujours eu : la mathématique, pas la signification informatique, par exemple == de deux entiers compare par valeur, ; les histoires de références, et donc d’adresse en mémoire, ne concernent que l’informatique bas-niveau : méthodes adaptées pour.
Je dirai que tout ceci n’est qu’une histoire de convention, et que tu dis que la tienne vaut mieux, c’est totalement faux. Pour quelqu’un qui n’a pas de formation poussée à Java mais qui connaît un peu les maths je t’ai montré que c’est tout le contraire. Le coup du « add(All) » me semble même très dangereux, car tu fais l’hypothèse que le mec qui a écrit ça a suivi ta convention, par contre quand c’est un « + » tu n’acceptes pas que le mec ait pu suivre ta convention : ton raisonnement est biaisé car au final ton argument est identique dans un cas comme dans l’autre. Il faut absolument vérifier que la méthode fasse ce qu’on lui demande.
Le Java interdit de redéfinir + & co, très bien, du coup on va définir des méthodes qui vont bien, mais ça ne fait que déplacer le problème sans le résoudre, car les noms des méthodes suffisent rarement à décrire ce qu’elle font : sinon pourquoi on les documenterait ?
PS : c’est quoi le problème avec les parenthèse ? De toute manière la multiplication matricielle est associative.