DM : Création d'un algorithme 1èreS

[Anonyme]

Oui en fait la condition 0 uniquement).

d'accord très bien comme xA >= 0 ET xA = 0 ET yA = XA^2 et yA 0 ET xA 0 ET yA XA^2 et yA = pour garder

[maths0]

d'accord très bien comme xA >= 0 ET xA = 0 ET yA = XA^2 et yA 0 ET xA 0 ET yA XA^2 et yA = pour garder

Ton choix sera le miens :zen: Maintenant tu peux écrire x et y plutôt que xA, Ya on y verra mieux.
C'est comme dis plus haut, ça va au delà de ton algorithme.
Si tu comprends l’ambiguïté c'est encore mieux.

PS: Merci pour les compliments, la pédagogie n'a pas de prix.

[Anonyme]

Ton choix sera le miens :zen:
C'est comme dis plus haut, ça va au delà de ton algorithme.
Si tu comprends l’ambiguïté c'est encore mieux.

PS: Merci pour les compliments, la pédagogie n'a pas de prix.

D'accord je te remercie vraiment BEAUCOUP pour ton aide elle m'a été très précieuse !!

[Dlzlogic]

Bonsoir,
Je crois qu'il y a deux notions différentes qui ont été évoquées
1- la question des limites, c'est à dire point SUR la limite ou pas. En matière de réels, la comparaison "égal" n'a pas vraiment de sens, que ce soit en informatique ou pas, mais c'est encore plus vrai en informatique. La seule solution est d'adopter une valeur "très petite", donc les comparaisons se feront toujours par rapport à cette tolérance.
2- la question de l'ordre des tests. Lorsque l'on teste des valeurs, il faut toujours commencer par les tests les plus "faciles". C'est à dire qu'il faut tester YA par rapport à 0 et par rapport à 1 AVANT de le tester par rapport à un carré ou par rapport à une racine carrée.

En d'autres termes, il aurait été bien de tester d'abord x et y par rapport à 0 et 1 et ensuite, si le test est positif, on test y par rapport à x² et racine(s). Ce genre de chose devrait apparaitre dans un algorithme. Il faut s'imaginer qu'un algorithme est fait pour être donné à quelqu'un qui ne comprend rien mais qui pourra exécuter les tâches telles que décrites.

[Anonyme]

Bonsoir,
Je crois qu'il y a deux notions différentes qui ont été évoquées
1- la question des limites, c'est à dire point SUR la limite ou pas. En matière de réels, la comparaison "égal" n'a pas vraiment de sens, que ce soit en informatique ou pas, mais c'est encore plus vrai en informatique. La seule solution est d'adopter une valeur "très petite", donc les comparaisons se feront toujours par rapport à cette tolérance.
2- la question de l'ordre des tests. Lorsque l'on teste des valeurs, il faut toujours commencer par les tests les plus "faciles". C'est à dire qu'il faut tester YA par rapport à 0 et par rapport à 1 AVANT de le tester par rapport à un carré ou par rapport à une racine carrée.

En d'autres termes, il aurait été bien de tester d'abord x et y par rapport à 0 et 1 et ensuite, si le test est positif, on test y par rapport à x² et racine(s). Ce genre de chose devrait apparaitre dans un algorithme. Il faut s'imaginer qu'un algorithme est fait pour être donné à quelqu'un qui ne comprend rien mais qui pourra exécuter les tâches telles que décrites.

donc, en gros d'après ce qui est écrit "En matière de réels, la comparaison "égal" n'a pas vraiment de sens, que ce soit en informatique ou pas, mais c'est encore plus vrai en informatique." je ne dois casi jamais mettre de => ou <= dans un algorithme ?

[Dlzlogic]

"je ne dois quasi jamais mettre de => ou <= dans un algorithme ?"
C'est absolument vrai. Il y a tout de même des exceptions. Supposons que pour une raison quelconque vous vouliez repérer des valeurs, par exemple qui ne sont pas renseignées. Vous aurez pris soin de les initialiser avec une valeur que vous connaissez, comme un code, ce qui permettra de tester avec le signe "=". Mais en gros "<=" et "<" quand il s'agit de réel, c'est pareil, puisque la condition "=" n'est vraie que dans des cas particuliers.
Le epsilon utilisé pour savoir si on est "strictement intérieur" s'écrira pas exemple
si x < 1-epsilon.
Je sais bien que ce sujet provoque des discussions, mais je ne pouvais pas éviter d'en parler, puisqu'il a été évoqué.

[fatal_error]

"je ne dois quasi jamais mettre de => ou <= dans un algorithme ?"

si tu peux. Tu te préoccuperas de la précision plus tard, si on a définit <= c'est pas pour faire joli. C'est juste que Dlzlogic croit encore qu'en informatique on est au bit près, ce qui est foncièrement faux.

et concernant ca :

En matière de réels, la comparaison "égal" n'a pas vraiment de sens, que ce soit en informatique ou pas, mais c'est encore plus vrai en informatique

je dirais pas que c'est faux, parce qu'on va encore s'embourber. J'interpelle donc le lecteur à faire ses propres recherches.

[Dlzlogic]

@Fatal_error
Soyons clair, prends 2 segments connus par les coordonnées de leurs extrémités.
Calcule l'intersection Xi,Yi des deux segments.
Calcule les deux distances D1 et D2 de I aux 2 segments et compare les à 0.00.
Ca peut marcher comme ça peut ne pas marcher.

[fatal_error]

ca marche à tous les coup pour 0.00 (la distance valant elle même 0....)

[Dlzlogic]

T'as essayé ou tu l'affirmes ?

[fatal_error]

je l'affirme.

Testes 0 avec 0 toi même. Si tu arrives à trouver une différence, je te montrerai ce que tu fais de mal.

edit: ca n'a rien à voir avec

si on a définit <= c'est pas pour faire joli. C'est juste que Dlzlogic croit encore qu'en informatique on est au bit près, ce qui est foncièrement faux.

Quand tu testes une convergence d'algorithme on s'en contrefout que la valeur égale ou pas est atteinte, rien n'interdit d'écrire <=, maintenant si tu es au bit près, ce qui n'est pas la totalité des cas et loin de là, alors ptet bien que faudrait te documenter sur la facon dont sont représentés les nombres que tu manipules.

[Dlzlogic]

Aies au moins l'honnêteté intellectuelle de le tester.
Demain, je fais une simulation, et on verra la probabilité de réussite.
Monte-Carlo, tu connais ?

[fatal_error]

tu dis n'importe quoi.
monte carlo n'a rien à voir avec ca et je sais même pas pourquoi tu veux foutre de la proba la dedans.

C'est pas une question d'honneteté intellectuelle mais de connaissance du langage.

J'y peux rien si tu sais pas faire la différence entre un vulgaire float et un double, mais évites de prêcher à tout va des inepties telles que jamais écrire l'opérateur <=.

edit : je pense que les intervenants sauront au moins douter de nos propos, c'est suffisant pour ma part dans la mesure ou la question en jeu ne concerne que peu l'auteur de cette discussion.
J'ai proposé ci dessus de dire ou ton code est ...mal codé, il va sans dire que si je vois quelque chose qui ressemble à une simulation, je ne daignerai pas répondre...

[maths0]

Oune demi, avec un café :marteau:
Si il faut que tu discernes le cas où l'on veut que se soit égal ou non.....
Les points sur la courbe ne semblent pas être gris donc ils semblent ne pas appartenir à la zone grise.
Maintenant tout ce qui est de ton algorithme on ne pourra rien te dire.
Et il ne faut pas rentrer dans le débat de l'interprétation de ton langage sur les différents processeurs qui pourront faire exécuter ton programme, selon le compilateur, l’interpréteur ou ton langage de programmation.
Dans ton algorithme tu considères que le = veut dire identique. :lol3:

[Anonyme]

Oune demi, avec un café :marteau:
Si il faut que tu discernes le cas où l'on veut que se soit égal ou non.....
Les points sur la courbe ne semblent pas être gris donc ils semblent ne pas appartenir à la zone grise.
Maintenant tout ce qui est de ton algorithme on ne pourra rien te dire.
Et il ne faut pas rentrer dans le débat de l'interprétation de ton langage sur les différents processeurs qui pourront faire exécuter ton programme, selon le compilateur, l’interpréteur ou ton langage de programmation.
Dans ton algorithme tu considères que le = veut dire identique. :lol3:

Oui je comprends ^^ je n'ai pas mis de = :lol3:
Encore merci pour toute l'aide fournie :we:

[Dlzlogic]

tu dis n'importe quoi.
monte carlo n'a rien à voir avec ca et je sais même pas pourquoi tu veux foutre de la proba la dedans.

C'est pas une question d'honneteté intellectuelle mais de connaissance du langage.

J'y peux rien si tu sais pas faire la différence entre un vulgaire float et un double, mais évites de prêcher à tout va des inepties telles que jamais écrire l'opérateur <=.

edit : je pense que les intervenants sauront au moins douter de nos propos, c'est suffisant pour ma part dans la mesure ou la question en jeu ne concerne que peu l'auteur de cette discussion.
J'ai proposé ci dessus de dire ou ton code est ...mal codé, il va sans dire que si je vois quelque chose qui ressemble à une simulation, je ne daignerai pas répondre...

Tu as certainement raison d'affirmer que je dis n'importe quoi.
Pour ton information, la méthode de Monte-Carlo est destinée à évaluer le résultat numérique de quelque-chose qu'on n'arrive pas à formaliser algébriquement.
Ce problème de comparaison entre réels n'a rien à voir avec le langage utilisé.
Contrairement à ce que tu penses, je sais très bien faire la différence entre un vulgaire float et un noble double, le second est sur 64 bits, alors que le premier n'est que sur 32 bits. Ils ont aussi des différences sur les possibilités de caractéristiques.
J'ai dis qu'il ne fallait utiliser l'opérateur "=" pour tester des réels que dans des cas particuliers.
Il n'est pas utile que tu t'étendes plus sur ce sujet.

[fatal_error]

ouais il aura fallu que je cherche les méandres du forum...genre ca
poste de 21/07/2012, 17h56

et j'appuie.

J'y peux rien si tu sais pas faire la différence entre un vulgaire float et un double, mais évites de prêcher à tout va des inepties telles que jamais écrire l'opérateur <=.

J'ai dis qu'il ne fallait utiliser l'opérateur "=" pour tester des réels que dans des cas particuliers.

ce qui reste...faux . C'est le contraire. Eventuellement on peut s'entendre sur : ca dépend des cas, mais ca reste faux de restreindre l'opérateur = aux "cas particuliers".

ps :

Pour ton information

Au risque de paraitre hautain, tu m'apprends rien. Je doute pas que tu aies un grand nombre de choses à m'apprendre, mais pour le coup, non.

[Dlzlogic]

Au risque de paraitre hautain, tu m'apprends rien. Je doute pas que tu aies un grand nombre de choses à m'apprendre, mais pour le coup, non.

Tu sais, quand on travaille avec des triangles que l'on divise que l'on compare etc., ça n'a rien à voir avec une somme de valeur égales à 0.3.
Ce point est d'ailleurs particulièrement important et difficile avec le traitement de zones. Et justement il s'agit de la question posée.