Page 32 sur 77

Re: Problèmes de probabilités et statistiques

Publié : jeu. juil. 18, 2019 7:56 am
par Pilgrim
Vorghyrn a écrit : mar. juil. 16, 2019 9:03 am L’opérateur = pour l’affectation en R c’est le Mal 😈

Ca c'est de la religion : les seuls arguments que j'ai pu lire en faveur du "<-" à la place du "=" sont soit de rendre la lecture d'un code plus "facile" (argument subjectif) et des cas exotiques ou le "=" et "<-" ne sont pas interchangeables, par exemple lorsque l'on veut assigner à une variable au sein d'une fonction... or si l'on veut éviter tout risque d'erreur et/ou faciliter la lecture du code, justement, c'est une bonne pratique de ne pas faire ce genre de choses...

Le "<-" est un héritage du clavier APL, qui se maintient pour des raisons de compatibilité (et de religion ;) ), mais l'opérateur "=" est non seulement plus simple (1 seul caractère) mais aussi le plus universel (on le retrouve en C++, Python etc...). Quand il n'y a aucune valeur ajoutée à faire complexe, faisons simple ;)

Re: Problèmes de probabilités et statistiques

Publié : jeu. juil. 18, 2019 8:44 am
par Vorghyrn
Pilgrim a écrit : jeu. juil. 18, 2019 7:56 am
Vorghyrn a écrit : mar. juil. 16, 2019 9:03 am L’opérateur = pour l’affectation en R c’est le Mal 😈

Ca c'est de la religion : les seuls arguments que j'ai pu lire en faveur du "<-" à la place du "=" sont soit de rendre la lecture d'un code plus "facile" (argument subjectif) et des cas exotiques ou le "=" et "<-" ne sont pas interchangeables, par exemple lorsque l'on veut assigner à une variable au sein d'une fonction... or si l'on veut éviter tout risque d'erreur et/ou faciliter la lecture du code, justement, c'est une bonne pratique de ne pas faire ce genre de choses...

Le "<-" est un héritage du clavier APL, qui se maintient pour des raisons de compatibilité (et de religion ;) ), mais l'opérateur "=" est non seulement plus simple (1 seul caractère) mais aussi le plus universel (on le retrouve en C++, Python etc...). Quand il n'y a aucune valeur ajoutée à faire complexe, faisons simple ;)
Je comprend tout à fait tes arguments et, pour être franc, je disais surtout ça pour te charrier (gentiment). J'aurais dû mettre un  ;) pour être bien clair.

A titre perso et purement subjectif, je trouve quand même que ça améliore la lisibilité à cause du fait que assigner une valeur par défaut à une variable dans la définition d'une fonction se fait déjà avec "=" (c'est peut être là, l'erreur de conception).

Mais R, bien que ce soit mon langage préféré, est quand même plein de bizarrerie, comme le fait de compter les indice à partir de 1 et non de 0 comme partout ailleurs... :runaway
 

Re: Problèmes de probabilités et statistiques

Publié : jeu. juil. 18, 2019 9:03 am
par XO de Vorcen
Objection votre honneur !
Ce sont les autres qui sont bizarres.
Que le 1er caractère d'une chaîne ou le premier poste d'un tableau soit en position 1 et non 0, c'est vachement plus naturel (du poi t de vue humain)

XO, qui bosse sur AS400 où les indices commencent à 1.

Re: Problèmes de probabilités et statistiques

Publié : jeu. juil. 18, 2019 9:12 am
par Vorghyrn
XO de Vorcen a écrit : jeu. juil. 18, 2019 9:03 am Objection votre honneur !
Ce sont les autres qui sont bizarres.
Que le 1er caractère d'une chaîne ou le premier poste d'un tableau soit en position 1 et non 0, c'est vachement plus naturel (du poi t de vue humain)

XO, qui bosse sur AS400 où les indices commencent à 1.
Dans un sujet sur les stats, je suis tenté de te répondre que ce qui définie la norme est statistique :mrgreen:
 

Re: Problèmes de probabilités et statistiques

Publié : jeu. juil. 18, 2019 12:38 pm
par XO de Vorcen
7 milliards d'êtres humains désigne le premier élément d'une série par le numéro 1. :charmeur

Bon, ok c'est péremptoire mais je ne dois pas être loin du compte.

Re: Problèmes de probabilités et statistiques

Publié : jeu. juil. 18, 2019 12:44 pm
par Vorghyrn
oui, mais sur ces milliards de gens, la majorité de ceux qui font de la prog commence par 0. Or c'est à eux que tu parle quand tu écrit un langage de programmation.
ça serait comme écrire "lancez un dé pour savoir si votre perso réussi ou pas son action" dans un supplément de JDR. Les rôlistes vont logiquement de demander "quel dé ? 1D4,1D6, 1D8 ... ?" là où la majorité des humains assimilent "un dé" à 1D6.

Conclusion, ce qui compte, c'est public auquel tu t'adresse, pas l'ensemble de l'humanité :mrgreen:

Re: Problèmes de probabilités et statistiques

Publié : jeu. juil. 18, 2019 1:03 pm
par XO de Vorcen
Mais pourquoi ce choix initial ? Et pourquoi est il considéré comme sacro-saint ?
Et non, mes collègues commencent à 1 sauf le java-liste. Et nous faisons aussi partie du milieu IT. Donc l'effet loupe...

:bierre:

Re: Problèmes de probabilités et statistiques

Publié : jeu. juil. 18, 2019 1:06 pm
par Yusei
XO de Vorcen a écrit : jeu. juil. 18, 2019 1:03 pm Mais pourquoi ce choix initial ? Et pourquoi est il considéré comme sacro-saint ?
Je pense qu'une des raisons historiques, ce sont les pointeurs mémoire. Si ton pointeur dit que ta liste commence à la position 10 et que chaque élément fait une taille 2, alors le premier élément est à la position 10+0*2, le deuxième à la position 10+1*2, etc.

(Edit) et Dijkstra donne une raison pour laquelle c'est bien ainsi:
- quand on fait un encadrement (x < i < y), c'est pratique que y-x donne la longueur de l'intervalle
- ça nous oblige à avoir un des deux signes qui est un inférieur ou égal (x <= i < y ou x < i <= y)
- 0 <= i < N est plus joli que 1 <= i < N+1

Re: Problèmes de probabilités et statistiques

Publié : jeu. juil. 18, 2019 3:10 pm
par Mugen
Yusei a écrit : jeu. juil. 18, 2019 1:06 pm
XO de Vorcen a écrit : jeu. juil. 18, 2019 1:03 pm Mais pourquoi ce choix initial ? Et pourquoi est il considéré comme sacro-saint ?
Je pense qu'une des raisons historiques, ce sont les pointeurs mémoire. Si ton pointeur dit que ta liste commence à la position 10 et que chaque élément fait une taille 2, alors le premier élément est à la position 10+0*2, le deuxième à la position 10+1*2, etc.

Oui. En C, un tableau est indissociable du pointeur sur sa première case mémoire.
Et sa popularité a fait que beaucoup de langages plus modernes ont utilisé ses conventions, y compris celle-ci.
Cela permet entre autre de considérer chaque case du tableau comme le début d'un tableau, et donc de ne pas avoir à se trimbaler un offset.
Dans des systèmes très limités en ressources (comme une carte à puces), c'est très intéressant.

Re: Problèmes de probabilités et statistiques

Publié : jeu. juil. 18, 2019 5:06 pm
par Vorghyrn
XO de Vorcen a écrit : jeu. juil. 18, 2019 1:03 pm Et non, mes collègues commencent à 1 sauf le java-liste. Et nous faisons aussi partie du milieu IT. Donc l'effet loupe...

:bierre:
Oui, mais comme les langages de programmations s'adressent à la communautés des programmeurs en général, il n'est pas stupide d'adopter les normes de cette communauté et pas de l'humanité (dont la majorité ne programme pas) ou toi, ton équipe et moi (qui ne sommes pas majoritaires dans la communauté visée). C'est un choix de positionnement. Je ferais le même si j'avais à difuser (et encore plus, à commercialiser) un langage de programmation, sauf si bien sûr on me démontre que ce choix est sous-optimal en terme d'efficacité du langage, ce qui ne semble pas être le cas, vu les arguments mentionnés juste au dessus...
 

Re: Problèmes de probabilités et statistiques

Publié : jeu. juil. 18, 2019 5:30 pm
par Mugen
Vorghyrn a écrit : jeu. juil. 18, 2019 5:06 pm
XO de Vorcen a écrit : jeu. juil. 18, 2019 1:03 pm Et non, mes collègues commencent à 1 sauf le java-liste. Et nous faisons aussi partie du milieu IT. Donc l'effet loupe...

:bierre:
Oui, mais comme les langages de programmations s'adressent à la communautés des programmeurs en général, il n'est pas stupide d'adopter les normes de cette communauté et pas de l'humanité (dont la majorité ne programme pas) ou toi, ton équipe et moi (qui ne sommes pas majoritaires dans la communauté visée). C'est un choix de positionnement. Je ferais le même si j'avais à difuser (et encore plus, à commercialiser) un langage de programmation, sauf si bien sûr on me démontre que ce choix est sous-optimal en terme d'efficacité du langage, ce qui ne semble pas être le cas, vu les arguments mentionnés juste au dessus...

Après, dans le cas qui nous intéresse il s'agit vraiment d'une convention qui a été gardée.
Ce que j'explique pour le C n'a par exemple pas de réalité pour le java, qui aurait pu choisir une autre convention.
Mais changer impliquerait une confusion...

Re: Problèmes de probabilités et statistiques

Publié : jeu. juil. 18, 2019 5:41 pm
par Vorghyrn
oui, en réalité, 0 ou 1 n'affecte pas (plus ?) réellement les performances du langage et reste la norme majoritaire des programmeurs.
Je conçois très bien qu'on ait envie de changer parce que ce n'est pas intuitif pour un humain en général, et que ça ne demanderait pas un gros effort de le faire, mais l'argument de la convention majoritaire se tient tout autant

Re: Problèmes de probabilités et statistiques

Publié : jeu. juil. 18, 2019 5:50 pm
par Yusei
Je trouve que l'argument de Dijkstra se tient, pour confirmer que la convention est bonne.

Boucle de N itérations:

- i=0; while (i < n) { print(a(i)); i = i+1 }
- i=1; while (i < n+1) { print(a(i)); i = i+1 }
- i=1; while (i <= n) { print(a(i)); i = i+1 }

La première ligne est plus courte et garde la propriété sympa que fin-début = longueur (contrairement à la troisième ligne).

Re: Problèmes de probabilités et statistiques

Publié : jeu. juil. 18, 2019 6:04 pm
par Mugen
Yusei a écrit : jeu. juil. 18, 2019 5:50 pm Je trouve que l'argument de Dijkstra se tient, pour confirmer que la convention est bonne.

Boucle de N itérations:

- i=0; while (i < n) { print(a(i)); i = i+1 }
- i=1; while (i < n+1) { print(a(i)); i = i+1 }
- i=1; while (i <= n) { print(a(i)); i = i+1 }

La première ligne est plus courte et garde la propriété sympa que fin-début = longueur (contrairement à la troisième ligne).

Plus courte en nombre de signes ?
Ça n'est pas très significatif, vu que ce qui compte c'est le code machine généré et le nombre d'instructions effectuées.
Si les deux instructions "inférieur" et "inférieur ou égal" existent, tu auras une efficacité identique pour les lignes 1 et 3.

Bon, si tu as "inférieur à 0", en effet la ligne 1 sera de loin la meilleure. :D

Re: Problèmes de probabilités et statistiques

Publié : jeu. juil. 18, 2019 6:08 pm
par Yusei
Mugen a écrit : jeu. juil. 18, 2019 6:04 pm Ça n'est pas très significatif, vu que ce qui compte c'est le code machine généré et le nombre d'instructions effectuées.
Ça dépend du contexte, mais pour mon usage perso ce qui importe c'est l'optimisation du programmeur, pas du code. Je laisse ça au compilateur :) Je parlais donc de longueur du code et de facilité de lecture.