Kamoulox!

Le peu que je connais en programmation me dit que "oui", un programme est composé d'algorithmes.... Après, peut-être voulais tu dire que selon ton prof: "il n'existe que des langages algorithmiques", ce qui est effectivement faux si on compare avec le "langage orienté Objet"... Mais l'Objet j'y ai jamais rien piné alors pour le moment, je me retiens de voter jusqu'à clarification.

Euh ... techniquement un programme est un algorithme non ?

Tout repose sur un algorithme. Même aller chercher son pain le matin à la boulangerie.

L'algorithme repose sur des opération non ambiguës. Je répondrais pas pour tout le monde ;)

Nan, certainement pas. Un programme, c'est une implémentation.
Si un programme est un algorithme, une maison est un plan. (Ce qui ferait certainement baisser le coût de la construction immobilière, réjouissons-nous.)

Je prends ta définition (et la baisse qui va avec)!!! En ce moment, ça m'arrange.....

@Link : Être et reposer sur, c'est pas la même chose. Entre l'algo et le prog, y a pas la fonction identité, y a la fonction implémentation. Et Dieu et la NSA savent que la seconde inclut beaucoup plus de rhâââ, mutin de mortelle de Berthe que la première.

"Il n'y a que des algos dans un prgm". Ben, tu veux qu'il y ait quoi d'autres ? Un café chaud et un mars ?

Ce n'est qu'une question de langage pour la description de l'algorithme. Un programme est une suite finie d'instructions exécutable par un ordinateur. Un algorithme est une suite finie d'instructions et non ambiguë permettant la résolution d'un problème.

Sachant que l'ordinateur ne sait lire qu'un ensemble fini non ambiguë d'instructions. On peut en déduire qu'un programme est un algorithme.

Par contre un algorithme n'est pas forcement un programme.

CQFD.

En suivant l'explication de Geist, c'est bien un PEBKAC, non ?

Un programme peut contenir autre chose que de l'algo. Il peut par exemple contenir des données, je me trompe ? Ne serait-ce que des constantes ou des strings (maintenant, si même les strings sont considérés comme de l'algo, alors on l'a dans le ...)

En gros, tu es en train de dire que la carte n'est pas le territoire. Hop, référence obligée sur Van Vogt :

http://en.wikipedia.org/wiki/The_World_of_Null-A

Qui se lance dans une dissertation de philo ? :-)

En même temps, un string, tu l'as forcément un peu dans le...

Dans un programme, il n'y a que des algorithmes. Ta string n'est qu'une variable en faisant partie. Et dans le cas d'un jeu vidéo, tu pourras avoir des données à coté (textures ou je sais pas quoi), qui ne font pas partie à proprement dit du programme.

Après c'est une question de point de vue, et tout le monde aura le sien, sans avoir spécialement tort.

[...] "il n'existe que des langages algorithmiques", ce qui est effectivement faux si on compare avec...
Jusque là, tout a fait d'accord. "vote +1 dans la foulée"
...avec le langage orienté Objet
WAT

Je crois que vois ce que tu veux dire, cependant le terme "programme" peut aussi bien désigner le "code source" (le plan, et par conséquent l'algorithme) que le "produit finis" (la maison)...

Remarque, ce serait cool. :3

Expérience vécue?

J'ai déjà expliqué de nombreuse fois que mon "niveau" de programmation s'arrêtait à "séquence de création de code: erreur critique! BSOD! Reboot de cerveau nécessaire!".

C'est pas vraiment un hasard....

Ceci dit, j'essaye aussi de trouver une justification à l'OP, mais je suis pas l'Avocat du Diable moi! Il est déjà sur une autre affaire, il m'a demandé de meubler le temps qu'il arrive...

C'est toi l'algorithme.

Mais même tes textures, elle sont composées, au sein du programme final, d'algorithmes, puisqu'il y en a besoin d'un pour calculer ton affichage.
Tout dans un programme repose sur des algorithmes. Même l'affichage d'un "Hello World", puisque si toi tu n'utilise que printf, derrière cet appel de fonction il y a de nombreux calculs déclenchés, dans un ordre spécifique afin d'éviter des erreurs : un algorithme :)
Et les variables font parties de l'algorithme.

Oh non! Du pognon nous suffirait....

@Geist : Je pense que d'un point de vue technique :
- Le programme est le plan
- L'ordinateur est le maçon
- Le résultat de l'exécution du programme est la maison

Tout ce que va changer la POO c'est que dans ton programme qui consiste en l'implémentation d'un algorithme additionnant 3 pommes avec deux bananes, tu va pouvoir définir que les pommes et les bananes sont des fruits et que les fruits s'additionnent très bien dans un mixer avec un peu de lait.

@Noname : On passe de la réalité à la métaphore, jamais l'inverse, sinon ça fait des conneries. en l'occurence, ma métaphore {algo=>plan; prog=>maison} s'entend dans le sens suivant : On peut implémenter un algo de plein de manières différentes dans plein de langages différents, comme on peut construire plein de maisons différentes, dans plein d'endroits différents, suivant un plan donné. (Quand j'étais gosse, ma nourrice et un de mes meilleurs copains habitaient des maisons visiblement construites sur le même plan : exactement mêmes dimensions, arrangement des pièces, etc.)
Ta métaphore n'a rien à voir avec la mienne, si ce n'est qu'elle utilise les mêmes éléments.

@but2ene : Imaginons un algorithme quelconque (A) et son implémentation dans deux langagues, disons C++ (B) et Java (C).
Si on considère le prog comme étant l'exécutable, il est évident qu'il n'y a pas d'identité entre le prog C++ et le Java (exécution « directe » vs. JRE, gestion de la mémoire manuelle vs. ramasse-miette, etc). Or, on ne peut pas avoir A=B, A=C mais B!=C. Ergo, il n'y a pas d'identité entre l'algo et l'exécutable.
Si on considère le programme comme étant le code source, c'est encore plus facile.

En relisant attentivement, un autre problème saute aux yeux : Pour moi, être dénote une relation d'identité ; pour toi, une relation d'inclusion (« On peut en déduire qu'un programme est un algorithme. Par contre un algorithme n'est pas forcement un programme. »)
Mais même dit comme ça, ça n'a pas de sens.

Intermède comique.
*C'est un mathématicien qui rentre à la maison, et son fils lui demande de l'aide pour un problème de maths.
- C'est un problème très difficile : Deux canards nagent dans la mare, et quatre autres canards les rejoignent. Combien y a-t-il de canards dans la mare ?
Le père est estomaqué :
- Enfin, mon fils, tu sais bien que 2 + 2 = 4 ?
- Tu me prends pour un débile ? Bien sûr que je le sais. Mais quel est le rapport avec les canards ?*
Baque tou zeuh biznaisse.


La relation entre l'algo et le prog, c'est la même qu'entre l'égalité et les canards, c'est une relation de modélisation. On considère que l'algo rend compte de ce qui se passe à l'exécution du programme sans avoir besoin de savoir comment il a été implémenté ni par qui ni sur quelle machine il s'exécute ni quand, tout comme l'égalité rend compte des bains de canards, et qu'on sait qu'il y a six canards dans la mare sans avoir besoin de les compter, ni même de savoir dans quelle mare ni quel jour ni si les deux premiers étaient B et François ou Catherine et Pierre. (La relation de modélisation, contrairement à l'identité, laisse place à l'erreur, par excemple un bug, ou bien une cane en cloques.)
Et de la même manière qu'il est plus simple de calculer la somme de deux et de quatre que d'aller voir ce qui se passe dans la mare, il est plus simple de concevoir un algo et de le transposer en code que l'on compilera que d'essayer de construire un programme comme une suite de comparaison de potentiels électriques et de trifouillage de transistors.

@but2ene : En relisant, je me rends compte que je n'ai pas répondu à ton assimilation fondamentales des instructions d'un algo et de celles d'un programme.

Un algo, c'est une créature d'un monde ou les instructions sont exécutées parfaitement dans tous les cas. Un programme, ça vit dans un endroit où les compilos peuvent être mal interprétés, où les développeurs peuvent se planter dans la gestion de la mémoire, et où un rayonnement électromagnétique peut te flipper un bit alors que tu n'as rien demandé (sans parler du plus réaliste hardware kaputt).
L'instruction du programme est ambigüe, parce que tout ce bordel fait que tu ne sais jamais à 100% ce qui va se passer. (Genre, si la situation en Ukraine dégénère et que les bombes atomiques se mettent à voler, tu risques d'avoir des EMP qui te foutent le zouk dans tes programmes, mais aucun algo ne sera jamais perturbé.)

Ne pas analyser!
Ne pas analyser!
Ne pas analyser!
Ne pas analyser!
Ne pas analyser!
[...]

On ne trouve pas de pognon a l'intérieur du programme, mais dans le compte en banque des pigeons qui veulent bien vous l'acheter.

@but2ene : Il me sembe qu'il existe des algorithmes non déterministes, non ? Est-ce qu'on peut dire du coup qu'ils reposent sur des opérations non ambiguës ?

Suivant l'explication de Geist, c'est un PEBKAC de dire qu'un programme *contient* un algo, basta.

Un algo modélise plus ou moins précisément un programme ; ou, en le prenant dans l'autre sens, un programme est une application plus ou moins correcte d'un algo. Y a pas de relation contenant-contenu, pas même au sens ensembliste, l'algo c'est un outil.

Pour faire un parallèle matériel, un algo, c'est une clé à douille. Tu te ferais sacrément chier à faire des trucs sans (va dévisser une roue de bagnole à la main, sachant que les quatre / conq boulons ont été serrés en force avec un bras de levier de ~50 cm), mais ça n'est pas contenu dans le produit de tes efforts.

Personne ici n'irait dire qu'un zinc contient `P = 1/2 * Cz * rho * V² * S`, j'espère ? (Expression de la portance d'un aérodyne en fonction de, dans l'ordre, son coefficient de portance, la densité du milieu dans lequel il évolue, sa vitesse par rapport audit milieu, et la surface.) On s'en sert pour dessiner le zinc, mais c'est pas mis dedans.

Oui et non, le doute se base sur le "QUE".
Si on chipote, il n'y a pas que des algos, il y a les sockets, les accès fichiers et SGBD, des foncitons purement fonctionnelles et potentiellement des équations mathématiques (et plein d'autres...).

Au final j'ai l'impression de pas avoir compris la programmation,code,etc
Ce qu'on fait pour l'instant c'est des programmes de calcul(on prend un nombre,on fait un certain nombre d'opération et voilà).Donc du coup c'est différent d'un jv par exemple non ?Et le prof avait dit que sur papier c'était une algorithme mais sur un Pc ca s'appelait un programme
Vu que je sais pas trop je veux bien des explications

Pas de soucis, sur ce site tu peux apprendre. Profite tant qu'il n'est pas renommé DTCB ou autre billevesée.

Omg. Ca doit être la meilleure description de la POO que je n'ai jamais lue ô.o'

(on prend un nombre,on fait un certain nombre d'opération et voilà).Donc du coup c'est différent d'un jv par exemple non ?
En fait, non, ce n'est pas différent. Un jeu video fait la même chose, il manipule juste plus de nombres et fait plus d'opérations, c'est tout.

Les points de vie du joueur ? C'est un nombre.
Son stock de munitions ? C'est un nombre.
Sa position sur la carte ? C'est plusieurs nombres.
Sa vitesse ? C'est plusieurs nombres.
La couleur du troisième pixel sur la droite ? C'est plusieurs nombres.
Sur quelle touche du clavier le joueur vient d'appuyer ? C'est encore un nombre.

Il est certain que pour créer un jeu vidéo, on n'a pas besoin que de programmation. C'est peut-être de là que vient ta confusion?

Mais un programme, qu'il s'agisse d'un jeu vidéo, d'un de tes "programmes de calcul" ou de... n'importe quoi d'autre... n'est finalement qu'un ensemble structuré d'instructions. Bref, un algorithme.

En fait ma confusion vient du fait que dans mon cours c'était juste présenté ... comme quelque chose où il y a un nombre d'arrivé et puis c'est tout
Mais merci pour l'explication

Ca, c'est mis en favori, juste pour le débat sur "est-ce que la poule viens de l'oeuf, ou est-ce que l'oeuf viens de la poule ?" (qui marche aussi avec les canards dans la mare).
Au fait, à propos de poules (ou de canard, même si dans ce cas en fait c'est des pigeons... bref, à propos de volatiles) et d'algos, il y a ce film : http://fr.wikipedia.org/wiki/Un_homme_d%27exception

Fox, n'aurais-tu pas confondu langage fonctionnel et langage algorithmique ?

@Fade : forcément, vous commencez par les choses simples...

Après c'est sûr qu'entre un programme qui calcul une racine carrée et GTA, on voit pas trop le rapport tout de suite (même si c'est certain qu'il y a des racines carrées dans GTA, et pas que ça).

Seulement je trouve ça sympa, même si mal fait, de la part du prof de vous donner un exemple concret de ce qu'on peut faire en programmant.
Les profs de maths sont souvent très forts pour donner des exercices sans queue ni tête, ni relation avec aucune réalité physique.

Pour reprendre ton exemple du jeu vidéo, non il n'y a pas QUE des algorithmes, il y a aussi toute la partie "visible" de l'iceberg qui elle est réalisée par des infographistes, des scénaristes, game designers etc. ; mais pour afficher tout ça tout en le faisant bouger correctement, c'est du code qu'il faut (en plus de tous les autres calculs de points de vie etc. dont a parlé Shirluban)

Ainsi les 90% d'un jeu (c'est un chiffre au pif, de toute façon sur quoi se baser ? nombre de fichiers, "poids", temps de travail ? ) sont bien des "algorithmes", et d'ailleurs, les 10% restants ne font pas à proprement parler partie du "programme" mais sont plutôt des "ressources".

C'est un mathématicien qui rentre à la maison, et son fils lui demande de l'aide pour un problème de maths.
 - C'est un problème très difficile : Deux canards nagent dans la mare, et quatre autres canards les rejoignent. Combien y a-t-il de canards dans la mare ?
 Le père est estomaqué :
 - Enfin, mon fils, tu sais bien que 2 + 2 = 4 ?
 - Tu me prends pour un débile ? Bien sûr que je le sais. Mais quel est le rapport avec les canards ?

On sait qu'un certain nombre de canards nagent, mais pas combien de ces oiseaux sont initialement dans la mare.