[TUTO]Les variables dans des fonctions programmables

[Levak]

Bonjour,
Alors certains l'on peut-être déjà remarqué mais moi je viens seulement de le découvrir.
En effet je bossais sur Make3D quand j'ai été confronté à un problème : le tableur ne répondait pas à mes demandes... Il fallait donc programmer une fonction ( attention, une fonction n'est pas un programme)

Habituellement, on appelle fonction quelque chose du type f(x)=x²
en gros, en prog Nspire :

Code: Select all

Define f(x)=
Func
Return x²
EndFunc


Pour moi, l'utilité des fonctions s'arrêtait là car à chaque fois que je faisais quelque chose du type

Code: Select all

Define f(x)=
Func
temp := x*x
Return temp
EndFunc


je recevais une erreur du type : "Invalide dans une fonction ou expression courante"

J'ai donc depuis 1 an et demi abandonné l'idée de programmer avec les fonctions...

Changeons d'horizon, en C par exemple.
En C, une fonction s'analogue à un programme sur Nspire. Mais en fait, une fonction en C EST une fonction Nspire. Sauf qu'en fait, en C, le compilateur va définir tout seul les variables utilisées dans le programme en tant que variables locales. Variables locales voulant dire, qu'une fois la sorti de la fonction, la variable n'existe plus, elle est supprimée.

Et bien figurez vous que c'est avec cette remarque personnelle que j'ai testé ça :

Code: Select all

Define f(x)=
Func
Local temp
temp := x*x
Return temp
EndFunc


...et bien figurez vous que ça marche

Des fois, je me demande pourquoi les erreurs Nspire sont si mal rédigée... Ils auraient pas pu mettre "Impossible de créer une variable globale dans une fonction ou expression régulière" ?
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Bilan :
Pour utiliser des variables temporaires servant d'intermédiaire aux calculs dans une fonction définie tel que :

Code: Select all

Define f(x)=
Func

EndFunc


...il suffit de définir cette variable en tant que variable locale, tel que :

Code: Select all

Local a, b, c, d, toto, tata


Exemple :

Code: Select all

Define f(x)=
Func
Local temp
temp :=x*x
Return temp
EndFunc


_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _


@+

[Bisam]

A vrai dire, c'est vrai de plusieurs langages (en particulier le Pascal, qui est très proche du TI-Basic).
Dans une fonction, on ne peut pas créer de variables globales mais uniquement des variables locales.... et à vrai dire, c'est tant mieux.

Ce qui est moins courant et qui est vrai sur TI-68k et sans doute sur N'Spire, c'est que les paramètres peuvent être utilisés comme variable... mais les changements effectués dans la fonction ne seront pas répercutés sur la variable de départ.
Cela permet d'économiser des variables temporaires.

[JayTe]

En effet, c'est bien ça. Les fonctions peuvent lire les valeurs des variables globales mais pas les modifier.

Mais l'avantage des fonctions est que contrairement aux programmes, celles ci peuvent retourner une valeur.

De plus, un programme peut appeler un autre programme ou une fonction; mais une fonction ne peut appeler qu'une fonction.

Le problème intervient donc quand un élément doit à la fois retourner une valeur et modifier des variables globales, il faut alors repenser l'architecture du classeur, soit en transformant la fonction en programme et en stockant la valeur de retour dans une variables globale, soit en s'arrangeant pour que la modification soit faite à l'exterieur de la fonction. Mais ce n'est pas toujours si facile à régler comme problème

On peut aussi s'arranger avec l'indirection : #"nomdelavariable", qui correspond grosso modo à un pointeur ou une référence dans d'autres langages. Mais on retrouve les mêmes limitations qu'avec les vraies variables, à savoir impossible de modifier une variable globale avec cette méthode à partir d'une fonction, et ça ne marche pas avec les variables locales...

Par contre, Bisam, je ne vois pas trop pourquoi tu dis que c'est tant mieux comme ça... au contraire je trouve ça assez limitant comme restriction... qu'on ne puisse pas créer de variables globales, encore pourquoi pas, mais ne pas pouvoir les modifier...

[Levak]

On peut aussi s'arranger avec l'indirection : #"nomdelavariable", qui correspond grosso modo à un pointeur ou une référence dans d'autres langages. Mais on retrouve les mêmes limitations qu'avec les vraies variables, à savoir impossible de modifier une variable globale avec cette méthode à partir d'une fonction, et ça ne marche pas avec les variables locales...

"Impossible", je n'irais pas jusque là. On peut touours bidouille avec l'application tableur qui stocke dans une variable la valeur du return que retourne la fonction, et là la variable globale est modifiée.
De même si le return est une liste, je suis prêt à parier que
toto:=mafunc(x[])[1]
tata:=mafunc(x[])[2]

...fonctionne

C'est de la bidouille certes, mais il y a un autre logiciel qui commence seulement avec la version 2.50 à se professionnaliser, il s'appelle Blender, et avec il fallait toujours bidouiller pour arriver à faire quelque chose qu'on faisait peut être en 2 clics avec un autre logiciel. L'avantage c'est que ça développe un esprit McGyver qui permet de faire 10 milles choses que ne font pas les autres logiciels pro. Ça reste de la bidouille, mais ça fonctionne bien

@+

[JayTe]

Oui, d'accord ça ne serait pas drôle si il ne fallait pas bidouiller

Mais pour ton exemple, oui ça marche mais c'est parce que tu n'est plus dans le corps de la fonction mais dans l'application calculs ou dans un programme. C'est en plus précis ce que je disais à la fin de mon 4e paragraphe du post précédant

[Bisam]

En fait, je ne vois pas ce qui vous pose problème.

Je trouve que vous expliquez très bien ce qui peut se faire et ce qui ne peut pas se faire... mais je ne vois pas en quoi ça gêne.

A priori, il est quasiment toujours inutile de créer des variables globales :
- si on veut les transmettre à une fonction, on les met en paramètres
- si on veut les modifier via une fonction, un simple := utilisant le retour de la fonction convient.

Le seul cas où ce n'est pas pratique, c'est lorsque l'on veut modifier un petit bout d'une TRES grosse variable (en taille mémoire) et que pour cela on a besoin de presque toute la variable.
En effet, transmettre la variable oblige la calculette à en faire une copie temporaire... ce qui prend du temps.
Mais ceci n'arrive qu'à Levak... et encore, je pense qu'il va bientôt réussir à simplifier encore son programme pour qu'il n'y ait plus besoin de manipuler des listes archi lourdes mais seulement des petites listes.

La plupart des programmes que l'on crée devraient contenir
- 1 programme principal
- 0 à 3 sous-programmes
- 0 à 10 fonctions essentiellement calculatoires
- 0 variable globale.

[Levak]

Le seul cas où ce n'est pas pratique, c'est lorsque l'on veut modifier un petit bout d'une TRES grosse variable (en taille mémoire) et que pour cela on a besoin de presque toute la variable.
En effet, transmettre la variable oblige la calculette à en faire une copie temporaire... ce qui prend du temps.
Mais ceci n'arrive qu'à Levak... et encore, je pense qu'il va bientôt réussir à simplifier encore son programme pour qu'il n'y ait plus besoin de manipuler des listes archi lourdes mais seulement des petites listes.

Ouïlle, j'ai mal
Je sais pas comment on pourrait optimiser deux listes qui contiennent les coordonnées respectivement x et y de chaque points projetés...à moins de les sectionner, mais du coup, le programme devient limité car on ne pourra pas prévoir le nombre nécessaire de nuages de points afin d'afficher le modèle au complet.

Le problème essentiel qu'on reproche à une fonction c'est qu'elle ne peut pas modifier des variables globales directement (voir bidouille 2 posts au dessus pour la solution), or, l'application tableur permet d'entrer comme argument une fonction, mais pas un programme...Et l'avantage d'utiliser l'application tableur, c'est qu'elle est dynamique...Donc effectivement, il faut migrer et faire des sacrifices mais pour un programme graphique, on n'est obligé d'avoir des variables globales de part la structure logicielle de la Nspire. Chaque variable peut dépendre d'une autre qui peut dépendre d'une fonction etc... mais ces variables doivent être stockées quelque part...

Donc je ne réfute pas ton post, Bisam, qui est plein de bon sens, mais il faut voir la vérité en face : la Nspire a des gros atouts qu'elle ne sait pas forcément bien gérer (sans revenir sur la question des fonctions)

[JayTe]

Je plussoie Levak, il a très bien exprimé le problème

Par contre pour la copie des listes lors du passage à une fonction ce n'est pas ce qui prend le plus de temps: j'ai testé sur des listes de 300 et + éléments; et la différence entre l'indirection et la copie n'est pas sensible. J'ai l'impression que la simple modification ou l'insertion d'éléments sont des opérations plus longues qu'une copie...