Discussion :

[Merel]

Bonjour à tous,

suite au sujet de youni, je me pose quelques questions sur l'intérêt des fonctions dans MATLAB. Ce sont des questions d'ordres générales.

Première question :

Est-il plus intéressant de coder un programme uniquement avec des fonctions ? (Gain de temps, identification de variables etc) Ou est ce que ca n'est pas plus rentable qu'avec un mixe de scripts et de fonction ?

Je trouve que travailler qu'avec des fonctions enlève des fonctionnalités à Matlab, notamment au niveau de l'affichage des variables dans le workspace. Avec un script, on peut le faire tourner et avoir directement accès aux dimensions, valeurs, types, etc... Mais ca n'est peut être qu'une question d'habitude...

Deuxième question :

Dans le cas où on développe à partir de fonction, vaut-il mieux passer par des fonctions indépendantes (avec un grand nombre de fichier .m), par des fonctions contenues dans seulement quelques fichiers ? Dans ce dernier cas, vaut-il mieux utiliser des nested fonctions ou les enchainer sans lien les unes à la suite des autres.

A vos claviers pour m'éclairer sur ces différents points !

[airballman]

JE dirais que ca depend de tes preferences et de ce que tu fais


JE fais de la recherche.
JE commence donc en général par ecrire un script qui s'allong au fur et a mesure que je teste des trucs.
Une fois que j'ai trouvé j'en fait une fonction pour que ca soit tout propre et pouvoir le reutiliser simplement. J'ajoute ensuite cette fonction au travail precedemment effectué.

En fait je rajoute des briques les unes aux autres, ca permet de segmenter le travail efficacement pour savoir ou on est exactement .
Ca simplifie aussi la lecture si tes noms de fonction sont bien choisis.
SI tu lis la rubrique conseils de programmation tu trouveras d'autres points positifs intéressants.

Pour ce qui est des multiples fonctions ou des inclusions la encore ca depend.
Si tu partages souvent ton travail avec dautres, il vaut peut etre mieux inclure tout dans un seul fichier afin deviter davoir des dependances dans tout les sens.

Par contre si tu travailles pour toi ou avec un repertoire partage il est peut etre plus simple de creer un certain nombre de fonctions simples qui seront reutilisables simplement en ajoutant un dossier dependances a ton path.

Je suis assez fan des fonctiontres simples qui rendent le code plus lisible (jai par exemple une fonction normalize qui me sert a normaliser mes matrices. Pourtant elle ne contien que deux lignes de code...)

Apres la encore ca depend des gouts de chacun.

A toi de voir

[Merel]

Réponse intéressante airballman, merci ^_^

C'est vrai que ca dépend des préférences de chacun. Je suis également chercheur et pourtant, je travaille quasiement qu'avec des scripts.

J'ai eu l'occasion de développer intégralement un "logiciel" sous matlab et il n'y a que très peu de fonctions. Les seules fonctions que j'utilise, ce sont des calculs liés à des tâches de fonds qui n'ont pas de rapport direct avec les résultats que je peux avoir.

En gros, quand le résultat est sans intérêt pour mon étude, ou quand il est intermédiaire, j'utilise des fonctions. Par contre, quand il est pertinent, j'utilise des scripts. Ca me permet de suivre l'évolution des variables dans le workspace pour vérifier à la fin de chaque script les données. Ces sorties sont surtout intéressantes en phase de développement pour tout vérifier. Une fois que tout fonctionne bien, c'est sur que ca n'a plus trop d'intérêt. Sauf peut être pour une personne étrangère qui utilise ton programme/logiciel. Ca lui permet d'avoir de visu les sorties des routines en plus des annotations dans le code.

Je trouve également que les scripts permettent de segmenter le travail plus facilement que les fonctions. Si tu as un gros logiciel/programme à developper, ca permet de faire tourner des parties de code facilement. Tu n'as pas à commenter des lignes ou à recommencer un programme dès le début.

Ce que je n'aime pas dans les fonctions, c'est que tu ne peux pas facilement les tester. Je me souviens d'une fonction qui faisait des calculs avec en paramètres d'entrées des longitudes et des latitudes. Quand j'ai du tester cette fonction, soit il fallait que je modifie cette fonction en script pour lui rentrer manuellement les longitudes/latitudes, soit je devais faire tourner le programme précédent pour avoir ces données... C'est un peu pénible à la longue.

Après, la remarque au niveau de la portabilité est pertinante. Mais à chaque fois que j'ai eu à donner mon logiciel, un petit .zip permet d'envoyer toutes les fonctions en un seul fichier. Je ne vois donc pas trop l'intérêt d'avoir un seul fichier .m
D'autant plus que ca ne facilite pas la lecture des commentaires. Ca rebute plus de voir un code de 10 000 lignes plutôt que 10 fichiers de 1 000 lignes.

Après, je ne sais pas si c'est plus efficace niveau temps de calcul ou si ca n'apporte pas grand chose. Je vais regarder ton lien !

[airballman]

Sauf peut être pour une personne étrangère qui utilise ton programme/logiciel. Ca lui permet d'avoir de visu les sorties des routines en plus des annotations dans le code.

Pour ça j'utilise un keyboard bien placé , ca permet de rester propre tout en voyant en temps réèl les variables se créer. (enfin c'est un solution que j'aime bien, je dis pas que c'est la seule ni la meilleure hein)

Après, la remarque au niveau de la portabilité est pertinante. Mais à chaque fois que j'ai eu à donner mon logiciel, un petit .zip permet d'envoyer toutes les fonctions en un seul fichier. Je ne vois donc pas trop l'intérêt d'avoir un seul fichier .m
D'autant plus que ca ne facilite pas la lecture des commentaires. Ca rebute plus de voir un code de 10 000 lignes plutôt que 10 fichiers de 1 000 lignes.

Je fais a peu pres comme toi, je deteste avoir des fichiers trop long je n'arrive pas à les lire. Je pense que c'est juste intéressant dans le cas ou tu veux juste une fonction qui tourne d'un coup sans rien lire et qu'il y ades sous fonctions dedans (c'est toujours simplement mon opinion). Des qu'il faut "rentrer dedans" je prefere utiliser des sous-focntions separees

Le lien est intéressant. J'ai commencé mon stage de fin d'études il y a deux mois. J'ai voulu passer un ou deux jours à bien piger les concepts du lien que je t'ai filé plutot que de foncer avec des scripts.
Ca aide beaucoup des que tu fais des choses qui se recoupent les unes avec les autres et qui sont dans la continuité

[Caro-Line]

Cela dépend pour qui tu codes.

Si c'est pour toi même tu es censé savoir ce que tu fais (quoique )

Mais si c'est pour d'autres il faut tenir compte de tous ce que tes utilisateurs peuvent faire et qui risque d'interagir avec ton programme.
Dans ce cas avoir des fonctions avec leur propre environnement est nécessaire.

Mixer des scripts et des fonctions : JAMAIS. Quelle drole d'idée

Je trouve que travailler qu'avec des fonctions enlève des fonctionnalités à Matlab, notamment au niveau de l'affichage des variables dans le workspace.

C'est à ton programme d'afficher ce qu'il faut quand il faut.

Dans le cas où on développe à partir de fonction, vaut-il mieux passer par des fonctions indépendantes (avec un grand nombre de fichier .m), par des fonctions contenues dans seulement quelques fichiers ?

A priori une fonction sert pour une ... fonction précise.
Si elle ne sert que dans le cadre d'une autre fonction pourquoi la sortir et multiplier les fichiers ?

L'éditeur de MATLAB, qui est de plus en plus évolué, te permet de faire de très longues fonctions avec une multitude de sous-fonctions et de t'y retrouver facilement.

Dans ce dernier cas, vaut-il mieux utiliser des nested fonctions ou les enchainer sans lien les unes à la suite des autres.

Comme pour tout cela dépend de ce que tu fais.
Etant une "ancienne", j'avoue ne pas être très à l'aise avec ces nested functions qui m'empêchent justement de savoir quelles sont les variables connues dans l'environnement de ma fonction.
Par contre "les enchainer sans lien" non. Quand je code mes sous-fonctions sont dans un ordre déterminé ( même si cela ne change rien au final), ont des noms qui donnent leur fonction.


Enfin une dernière chose contre les scripts : on ne peut pas les compiler (forcément puisqu'ils interagissent avec le workspace qui n'existe plus dans le cas d'un programme compilé).

[airballman]

Enfin une dernière chose contre les scripts : on ne peut pas les compiler (forcément puisqu'ils interagissent avec le workspace qui n'existe plus dans le cas d'un programme compilé).

C'est pas idiot ca, j'y avais pas pensé

[Merel]

Cela dépend pour qui tu codes.

Si c'est pour toi même tu es censé savoir ce que tu fais (quoique )

Mais si c'est pour d'autres il faut tenir compte de tous ce que tes utilisateurs peuvent faire et qui risque d'interagir avec ton programme.

Là, je suis d'accord avec toi. Tant que c'est pour moi et que je m'y retrouve, je peux coder comme je le souhaite (en respectant quand même les "règles de l'art").

C'est vrai que si une tierce personne doit utiliser les fichiers créés, il est préférable qu'il ne puisse pas interragir avec le code en créant malencontreusement des variables dans le workspace.

Mixer des scripts et des fonctions : JAMAIS. Quelle drole d'idée

^_^ Bha, c'est pas une drôle d'idée. par exemple tu as plein d'angles en degré que tu veux passer en radian, tu peux faire une petite fonction deg2rad ou rad2deg qui te permet de faire ca. Et tu l'appelles dans un script. Je ne vois pas trop ou est le problème.

C'est à ton programme d'afficher ce qu'il faut quand il faut.

Je suis d'accord mais en phase de développement, c'est quand même pas mal d'avoir toutes les variables sous les yeux dans le workspace. Mais une fois qu'il tourne, rien n'empêche en effet de le passer en fonction.

Enfin une dernière chose contre les scripts : on ne peut pas les compiler (forcément puisqu'ils interagissent avec le workspace qui n'existe plus dans le cas d'un programme compilé).

Effectivement, ca c'est un argument de poids. Après, faut voir si on doit compiler le truc ou pas.

Merci de la réponse en tout cas.

Ce que j'en retire pour le moment:

C'est que la manière de programmer est propre à chacun. On a tous des manières différentes d'appréhender un problème.
Pour un travail personnel ou un prog en développement le script peut être intéressant.
Pour un travail à échanger, privilégier les fonctions.
Les fonctions peuvent être complilées (gros avantage)
Le gros avantage des fonctions c'est qu'on peut les compiler.