Un résultat vraiment étonnant ! !! - page 7
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
Eh bien, j'étais plus ou moins d'accord sur la deuxième page que si c'est le cas, nous ne devrions pas parler d'un bug dans le compilateur, mais d'un bug dans le cerveau des développeurs. Sans vouloir vous offenser, j'ai fait ce fil de discussion plutôt pour rire.
Ce que je ne comprends pas maintenant, c'est ceci.
Sur quoi le compilateur MQL est-il développé ? S'il est développé dans un langage normal, les programmeurs ont dû être rendus fous par le fait que les opérations de multiplication et d'addition ont la même priorité. Comment ont-ils pu le manquer ? Est-ce que tout le monde met vraiment des parenthèses où il veut et où il ne veut pas ? D'ailleurs, trop de parenthèses rendent le code plus clair. Et lorsque vos programmeurs écrivent des opérations arithmétiques comme 2+3*4, ils écrivent également 2+(3*4), ou Dieu nous en préserve, un bug peut se glisser dans un compilateur C++ et l'imbrication de 100 parenthèses dans une expression est comptée manuellement :)
Il s'agit d'un bug dans les cerveaux des développeurs C, Java, Fortran, MathCad etc. etc.
Comment tu ne comprends toujours pas !
ZS
Bien que, je l'admets, il m'a fallu un certain temps pour le réaliser aussi.
Même si, je l'admets, il m'a fallu du temps pour m'en rendre compte aussi.
Ce n'est que maintenant que nous avons compris pourquoi certaines combinaisons logiques ne voulaient pas fonctionner correctement. J'ai dû ajouter des parenthèses artificielles.
Je ne pouvais pas l'expliquer avant. Mais je n'ai pas non plus abordé le sujet. J'ai réussi à trouver la bonne solution en fouillant un peu. Mais combien de fois ai-je dû fouiller pour tout changer ?
Ce n'est que maintenant que nous avons compris pourquoi certaines combinaisons logiques ne voulaient pas fonctionner correctement. J'ai dû ajouter des parenthèses artificielles.
Il n'y avait rien pour l'expliquer plus tôt. Mais je n'en ai pas parlé non plus. J'ai réussi à trouver la bonne solution en fouillant un peu. Mais combien de fois ai-je dû fouiller pour tout trouver ?
RTFM
*rofl*
Pas tous à la suite, bien sûr, mais je le fais toujours. Et par pure habitude, je les ai mis bien avant de découvrir ce "bug dans la tête des développeurs". Et pourquoi dois-je me plonger dans l'aide une fois de plus pour déterminer les priorités, si je peux m'en passer, en mettant des parenthèses ? Pour moi, ce "bug" n'a donc pas été une catastrophe, même si cela m'a amusé.
Et avant, quand j'écrivais quelque chose de booléen en C, je les mettais aussi, même si je ne doutais pas des priorités. Pour être honnête, je pense qu'une expression booléenne complexe sans parenthèses n'est pas très lisible.
P.S. N'utilisez pas un exemple aussi stupide que 2+3*4. Si un tel mouvement intelligent avec les priorités s'était produit pour les opérations arithmétiques, je n'aurais absolument aucun scrupule à le qualifier de véritable bogue.
Au fait :
x 1 ou (x 2 et x 3 ) = (x 1 ou x 2 ) et (x 1 ou x 3 )
x 1 et (x 2 ou x 3 ) = (x 1 et x 2 ) ou (x 1 et x 3 )
Il s'ensuit que du point de vue de l'algèbre booléenne, les opérations et ont la même priorité.
Andrei, qu'est-ce qui vous a donné l'idée que les priorités de ces opérations dans l'algèbre de Boole sont égales ? Contre-exemple :
à a=1, b=0, c=0
(a ou b) et c = (1 ou 0) et 0 = 0
a ou (b et c) = 1 ou (0 et 0) = 1
Dans quel langage le compilateur MQL est-il développé ? Après tout, s'il est développé dans un langage normal, les programmeurs auraient dû être tout d'abord choqués par le fait que leurs opérations de multiplication et d'addition ont une priorité égale. Comment ont-ils pu le manquer ?
Eh bien, voici un autre exemple de dépassement. Et pourtant, l'auteur du sujet rapporte qu'il a lancé le fil de discussion pour plaisanter, et qu'il avait lu la documentation à ce stade après tout.
Eh bien, voici un autre exemple de dépassement. Et pourtant, l'initiateur dit qu'il a lancé le sujet pour plaisanter et qu'il a lu la documentation à ce stade.
Je l'ai :-) Il est peut-être vrai que les grandes découvertes se font à l'aise avec des objectifs très différents.
J'en ai assez :-). Il est peut-être vrai que les grandes découvertes sont faites à l'aise, dans des buts bien différents.
Cette "découverte" peut difficilement être qualifiée de grande découverte. Il vaut mieux se contenter de constater le fait et l'oublier. En général, le sujet de la priorité des opérations booléennes est farfelu : il serait plus économique pour les développeurs d'interdire simplement la construction d'expressions booléennes avec différentes opérations sans parenthèses et de considérer ces constructions comme invalides.
Andrew, de quoi déduisez-vous réellement que les priorités de ces opérations dans l'algèbre de Boole sont égales ? Contre-exemple :
à a=1, b=0, c=0
(a ou b) et c = (1 ou 0) et 0 = 0
a ou (b et c) = 1 ou (0 et 0) = 1
a = beau
b = intelligent
c = riche
x = a && b && c ;
y = a || b || c ;
Je me demande ce que tu préfères, Andrei : x = 1 ou y = 1 ?
Andrew, de quoi, en fait, avez-vous déduit que les priorités de ces opérations dans l'algèbre de Boole sont égales ?
De la symétrie des opérations. Et la symétrie des opérations découle directement des formules attribuées.
Une opération symétrique ne peut pas avoir la priorité sur une autre.
Je me demande ce qu'Andrey préférerait : x = 1 ou y = 1 ?
Je préférerais, Eric, discuter sans devenir personnel et sans ricaner.
___________________________________
Bref, ce que je veux dire, c'est que
Le résultat de l'expression A && B || C est indéfini en termes d'algèbre de Boole.