Discussion :

[Invité]

Perso, des même points de vues
:
d'un point de vue mathématique, c'est dit très simplement et c'est très juste (on peut avoir 0 paramètres d'entrée), sachant qu'une fonction peut comme en ? retourner un ensemble de valeur comme une matrice voire une autre fonction. il y a donc cohérence entre math et prog, ce qui est naturel et logique. en algorithmique on appelle ça les entrée et les sorties.


Ah ben non hein, j'aurais pas gardé ma vision, parce que l'axiome premier est sans ambigüité lui c'est le titre de l'article,

Y a-t-il une raison pour laquelle les fonctions ne retournent qu'une seule valeur ?

Cherchons une astuce pour discuter quand même.

[Invité]

Si non, perso après, puisque j'ai le clavier, je pense que le principe de van neuman c'est d'ordonner avant tout.

Et donc dans la cas de retour de plusieurs résultat, donc un traitement pour moi qui affecterais plusieurs système distinct engendrerais plusieurs résultats ainsi de suite. Ce serait une complexification ou simplification selon le point de vue.

Vous poser la question pour faire l'inverse.

[ijk-ref]

Mon dieu le match contre Jovalise !

Je vote pour HFR :o

[Invité]

maintenant que j'ai pu définir mon avatar, on peut continuer de m'enlever des points même si je dis rien, je m'en fiche...

puisque je peux poster des articles de prog C# notamment sur les génériques.

Mon dieu le match contre Jovalise !

Je vote pour HFR :o

tu crois ?

c'est vraiment bien le poker.

[Sve@r]

Pour moi, une fonction c'est un traitement et pas deux donc ça ne doit retourné qu'un seul résultat.

Tu ne peux pas être aussi restrictif. Il existe des traitements qui produisent plusieurs résultats. Par exemple une division euclidienne, telle qu'on l'apprend au primaire, fournit 2 nombres en sortie: un quotient et un reste. C'est donc un traitement qui produit deux résultats.
Autre exemple: résoudre une équation du second degré à une inconnue est aussi un traitement qui produit lui aussi deux résultats.
C'est d'ailleurs parce qu'il existe des traitements de ce type que les mathématiciens donnent aux traitements qui ne produisent qu'au maximum un résultat (pour pouvoir y inclure aussi les traitements qui n'en produisent pas) le nom d'"application". Afin justement de les distinguer des autres. Et ils vont même jusqu'à subdiviser les applications en deux sous-ensembles: les bijections (applications qui, pour un résultat donné, ne peut avoir qu'une valeur en entrée qui amènera à ce résultat) et les autres (applications qui, pour un résultat donné, peut avoir plusieurs valeurs).
Ainsi f(x)=1/x est une application (pour tout nombre x je n'ai au maximum qu'un seul inverse) et aussi une bijection (tout inverse n'a qu'un seul antécédent)
En revanche, f(x)=x² est aussi une application (pour tout nombre x je n'ai au maximum qu'un seul carré) mais ce n'est pas une bijection (parmis tous les carrés possibles, certains pourront avoir jusqu'à 2 antécédents)
Et enfin f(a,b,c)=solution de l'équation ax²+bx+c=0 n'est pas une application puisque cette fonction pourra sortir jusqu'à 2 nombres. Et n'étant pas une application, elle ne peut pas être une bijection...

[Invité]

Oui certe.


Mais pour que le titre soit ce qu'il est c'est pas pour rien donc.

Soit ce sujet ne porte pas le bon titre soit les fonction retourne effectivement un unique résultat.

Mis à par ce que je dis sur la ligne suivante et les matière misent en oeuvre dans le traitement.


Oulà.

[Sve@r]

Soit ce sujet ne porte pas le bon titre soit les fonction retourne effectivement un unique résultat.

Une bonne remarque a été faite sur ce qu'on nomme "résultat".
Un tuple, par exemple (comme on le voit en Python) emporte avec lui plusieurs valeurs mais il reste considéré comme un seul et unique résultat.

PS: on voit d'ailleurs qu'on commence à mieux nommer les choses. En effet, le titre parle de "une seule valeur" alors qu'on commence ici à distinguer "valeur" et "résultat"...

[Invité]

Oui alors non, ne jouons pas avec le jeu mot.

Déjà il y a une négation inverse opposé au sens sous- tendu par l'auteur car chacun de nous à bien connaissance le la réalité des choses.


Y- a- t- il un intérêt à répondre à la question ?

[ijk-ref]

Une bonne remarque a été faite sur ce qu'on nomme "résultat".
Un tuple, par exemple (comme on le voit en Python) emporte avec lui plusieurs valeurs mais il reste considéré comme un seul et unique résultat.

PS: on voit d'ailleurs qu'on commence à mieux nommer les choses. En effet, le titre parle de "une seule valeur" alors qu'on commence ici à distinguer "valeur" et "résultat"...

Donc la question aurait dû être :
"Y a-t-il une raison à toujours nommer le type de retour des fonctions ?"

[Sve@r]

Y a-t-il une raison à toujours nommer le type de retour des fonctions ?

En Python tu ne nommes pas le type retour. Voire même tu peux écrire et utiliser une fonction qui pourra renvoyer plusieurs types différents selon son choix.

Maintenant pour les langages plus bas niveau (style C), c'est probablement pour que le compilo sache comment se comporter s'il voit un truc de ce genre: res=fonction() + 2. Ce ne sera pas la même façon de faire selon que fonction() aura été déclarée comme int ou comme float...

[ijk-ref]

En Python tu ne nommes pas le type retour. Voire même tu peux écrire et utiliser une fonction qui pourra renvoyer plusieurs types différents selon son choix.

Maintenant pour les langages plus bas niveau (style C), c'est probablement pour que le compilo sache comment se comporter s'il voit un truc de ce genre: res=fonction() + 2. Ce ne sera pas la même façon de faire selon que fonction() aura été déclarée comme int ou comme float...

Oui on ne parle pas du tout de la même chose

En Python le typage n'est pas vérifié à la compilation, même s'il est fortement typé.

Je pense qu'il est assez implicite que l'on parle ici surtout du "vrai typage fort" à la compilation comme font c\c++\c#\java.

[MABROUKI]

Re

Tout langage évolué est traduit dans ce langage.
donc historiquement, une fonction de langage évolué ne retourne qu'une valeur parce qu'une proc ne retourne rien et ne prend aucun paramètre.

Ton probleme c'est que tu devies de la question posee...
Les instructions CPU sont la base du code , mais sur laquelle un programmeur de code machine n'as aucune influence(contrainte technologique)...
Quant j'ai parle de taille memoire de la pile j'ai effleure un autre contrainte materielle: le probleme d'economie de memoire en general (autre contrainte technologique) auquel etait confrontee les programmeurs de code machine:

1/Historiquement comme tu dis ,le meme code machine machine (tel traitement de function) etait repete un peu partout ce qui etait inefficient car on consomme de la memoire abusivement (le code executable helas occupe lui aussi de l'espace memoire)...
2/ D'ou l'idee de le "factoriser" en un seul endroit dans une fonction ...
Et du meme coup ,on gagnait un autre avantage ,economie d'ecriture de code asm par le programmeur....

Ce sont essentiellement ces causes -au niveau code machine - qui ont donne naissance aux compilateurs optimisateurs qui nous contraignent à utiliser les fonctions ou procedures telles que nous les connaissons dans les langages evolues....
Et la necessite de toujours factoriser le code en language evolue est toujours d'actualite !!!...

Quant aux fonctions renvoyant plusieurs valeurs ,cela ne peut signifier qu'une chose, c'est qu'on veut exposer des details de calcul interne à la fonction à l'exterieur de celle-ci(des etats internes si tu veux ,comme les flags en asm) ,et que suivant la valeur des flags, on orientera le deroulement de l'Appelant...
Mais cette fonctionnalite existe avec les parametres d'entrees par references (ou pointeurs)....

Maintenant si on examine ces diverses causes elles n'ont rien à voir ni avec le code machine ni avec le language evolue utilise... et ne sont pas theoriques (algorithmie)...
Ce qui explique la propagation de l'utilisation des fonctions et procs - à tout les languages evolues ...
C'est en me basant sur ces constations courantes que j'ai parle de memoire de pile et de factorisation ....
bon code....

[MABROUKI]

Bonjour

Sve@r
En revanche, si tu veux une question analogue à celle du topic, alors tu pourrais demander pourquoi les premières voitures faisaient tourner les roues arrière alors qu'il est prouvé que la voiture a une meilleure tenue de route quand ce sont les roues avant qui la font avancer...

C'est bien vu là,j'aime cette comparaison.....
Probablement que les essieux rigides à pivot ne s'y pretaient pas (ecart de vitesse entre les 2 roues avant dans les virages) ,ce qui fut un pis-aller jusqu'à l'ivention de la cremaillere de direction....!!!

bon code...

[nostAlgo]

Go renvoie plusieurs valeurs

[Sve@r]

Go renvoie plusieurs valeurs

Tu ne voudrais pas développer ? Surtout pour ceux qui (comme moi) ne connaissent pas Go.
Par exemple renvoie-t-il réellement "plusieurs" valeurs ou bien plutôt (comme cela a été dit pour d'autres langages) ne renvoie-t-il pas un "truc" unique englobant lui, n valeurs ???

[Ehonn]

De plus un passage par copie de référence (Java) ou référence (C++) suffit largement pour avoir une fonction qui modifie plusieurs variables.

Remarque : En C++, la bibliothèque standard retourne plusieurs valeurs comme dans std::mismatch ou std::minmax en utilisant std::pair. Depuis C++11, on peut "retourner" autant "d'objets" que voulu grâce à std::tuple et std::tie (comme dit par Aurelien.Regat-Barrel).

[NBBIZOU]

Les langages comme C , Pascal sont compilés et traduits en Assembleur contrairement à Python , PHP...

En Assembleur la valeur de retour des fonctions se fait par une valeur ou un pointeur sur la variable ou une structure ( record, etc ) stockée dans EAX.

Essayez de désassembler avec WIN32DASM ou OLLYDBG un ( très ) petit exécutable écrit avec en C contenant une fonction qui retourne une valeur.

[sgmsg]

La fonction est cas particulier de la procédure.

Au lieu d'avoir le résultat (result) dans les variables, on le retrouve à la fin. D'ailleurs en turbo pascal les premières versions ne toléraient les variables qu'en fin de déclaration des procédures. Les paramètres eux étaient en début de déclaration.

En considérant que

function MaFonction(a:integer):boolean;

est équivalent à

procedure MaProcedure(a:integer;resultat:boolean);

On se rend rapidement compte que ce n'est que question de lisibilité et d'allégement du code;

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
var resultat:boolean;
...
MaProcedure(a,resultat);
if resultat then...

On obtient à la place avec la procédure

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
...
if MaFonction(a) then...

On voit donc une économie de deux lignes dont une déclaration de variable...

[el_slapper]

La fonction est cas particulier de la procédure.

Au lieu d'avoir le résultat (result) dans les variables, on le retrouve à la fin. D'ailleurs en turbo pascal les premières versions ne toléraient les variables qu'en fin de déclaration des procédures. Les paramètres eux étaient en début de déclaration.

En considérant que

function MaFonction(a:integer):boolean;

est équivalent à

procedure MaProcedure(a:integer;resultat:boolean);

On se rend rapidement compte que ce n'est que question de lisibilité et d'allégement du code;

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
var resultat:boolean;
...
MaProcedure(a,resultat);
if resultat then...

On obtient à la place avec la procédure

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
...
if MaFonction(a) then...

On voit donc une économie de deux lignes dont une déclaration de variable...

+1

J'en use et j'en abuse quand je code des scripts de tests d'interface. Toutes mes "procédures" d'action renvoient un booléen qui me dit si ça s'est bien passé. Ca permet de gérer finement le flux d'informations.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

If PrescriptionMedicament("ASPRO 500MG", 1, "CP") Then..... ' alors on peut continuer, la prescription s'est bien passée.

[DonQuiche]

Tu ne voudrais pas développer ? Surtout pour ceux qui (comme moi) ne connaissent pas Go.
Par exemple renvoie-t-il réellement "plusieurs" valeurs ou bien plutôt (comme cela a été dit pour d'autres langages) ne renvoie-t-il pas un "truc" unique englobant lui, n valeurs ???

Sur le plan sémantique il renvoie bien plusieurs valeurs et non pas un tuple. a, b, c := daFunk(). L'implémentation en revanche...

Les langages comme C , Pascal sont compilés et traduits en Assembleur contrairement à Python , PHP...

Peu importe : compilé ou non, le rôle d'un langage est d'exposer des abstractions de plus haut niveau que le matériel.

Il serait tout à fait possible à un langage compilé d'offrir des valeurs de retour multiples. En fait il ne serait même pas nécessaire de sacrifier les performances dans les cas de valeurs de retours uniques.