Optimisation avec DelVar

Je voulais savoir si cette chose s'optimisait encore plus où si c'était maximal :

Code:

:DelVar ADelVar BDelVar CDelVar DDelVar EDelVar FDelVar GDelVar HDelVar IDelVar JDelVar KDelVar LDelVar MDelVar NDelVar ODelVar PDelVar QDelVar RDelVar SDelVar TDelVar UDelVar VDelVar WDelVar XDelVar YDelVar ZDelVar θDelVar [A]DelVar [B]DelVar [C]DelVar [D]DelVar [E]DelVar [F]DelVar [G]DelVar [H]DelVar [I]DelVar [J]DelVar L₁DelVar L₂DelVar L₃DelVar L₄DelVar L₅DelVar L₆DelVar Str1DelVar Str2DelVar Str3DelVar Str4DelVar Str5DelVar Str6DelVar Str9DelVar Str0

Merci d'avance !   

Hey!

Tu peux utiliser (à la fin du coup):
ClrAllLists ([2nd][+][4])
Par contre ça ne supprime pas vraiment les listes (ça leur donne une dimension 0 mais elles existent toujours), et ça affecte aussi les listes perso...

Sinon je ne vois pas quoi te dire

Ok merci ! Donc je vais laisser tel quel je pense.

Oui c'est le mieux

Par contre je ne suis pas sur de l'utilité de ça:

Code:

DelVar ADelVar BDelVar CDelVar DDelVar EDelVar FDelVar GDelVar HDelVar IDelVar JDelVar KDelVar LDelVar MDelVar NDelVar ODelVar PDelVar QDelVar RDelVar SDelVar TDelVar UDelVar VDelVar WDelVar XDelVar YDelVar ZDelVar θ

Ca libère de la place certes, mais de là place pour quoi? Pour des programmes? Ces programmes vont devoir utiliser ces variables, donc en fait la place en mémoire que tu gagnes est illusoire :/

Je montrais un truc à un pote quand à la place occupée inutilement sur la calcu, donc tant qu'à faire un programme pour ça, autant qu'il soit lui même optimisé   ! Mais c'est vrai que c'est pas super utile...

Le reste peut être utile par contre
Ca permet de vraiment libérer la mémoire.

J'ai un petit programme qui nettoie votre TI avec des tas de Delvar si vous voulez ;-)

Sa rajoute vraiment beaucoup de ram

Ben c'est la même chose que là nan?

Je pense qu'il veut juste confirmer qu'on est beaucoup à avoir fait ça. Le mien permet de choisir quelle catégorie nettoyer, dont des initialisations de la fenêtre, table, modes, etc.

Ah bah dans ce cas je l'ai aussi fait bien sûr

Et j'ai aussi fait un prgm pour initialiser le graphe mode jeux (avec différent BDG selon le zoom voulu), et pour restaurer ensuite.

Linkakro a écrit:Je pense qu'il veut juste confirmer qu'on est beaucoup à avoir fait ça. ;)Le mien permet de choisir quelle catégorie nettoyer, dont des initialisations de la fenêtre, table, modes, etc.

Pareil :p

Ah bon ba je suis pas seul alors !   

J'ai moi même intégré une unité semblable dans mon pokémon, qui permet d'effacer toutes les variables utilisées par le jeu dont les chaînes et les listes. Il supprime également la sauvegarde en appuyant 15 fois sur seconde.
@Matthieu: tiens ta signature a disparu sur un de tes msgs, même en actualisant

[HS]Rectifié, j'ai du faire une fausse manip'...[/HS]

Inutile de supprimer les variables de A à Z. Pour chacune d'elles, tu perds 3 octets pour la supprimer (et elle en prend 12 en mémoire) sachant qu'elle sera forcément à nouveau créée par d'autres programmes.

Pour les listes, tu peux optimiser en :

Code:

ClrList L1,L2,L3,L4,L5,L6

Ne jamais utiliser ClrAllLists : cela détruit les listes personnalisées et par conséquent les données (tels les scores) stockées par d'autres programmes.

m@thieu41 a écrit:Ca libère de la place certes, mais de là place pour quoi? Pour des programmes? Ces programmes vont devoir utiliser ces variables, donc en fait la place en mémoire que tu gagnes est illusoire :/

C'est bien ce que j'ai dit

Par contre, même après ClrList, la liste occupe 9octets en mémoire: elle n'est pas supprimée, juste mise à la dimension 0.

m@thieu41 a écrit:Par contre, même après ClrList, la liste occupe 9octets en mémoire: elle n'est pas supprimée, juste mise à la dimension 0.

On se moque éperdument de ces 9 octets multipliés par 6. Les listes seront forcément à nouveau utilisées par un programme donc tu gagnes ces quelques octets uniquement de manière temporaire c'est-à-dire lorsque tu n'exécutes pas de programme et donc que tu n'en as pas besoin.

Tandis que quelques octets économisés dans un programme forment une réelle économie puisqu'elle est permanente.

Un programme n'utilise pas forcément les 6 listes...
Pour 6 octet de plus dans le prgm, tu libère 9*6 = 54 octets...
Certes un programme peut les réutiliser, mais à moins que ce soit un gros programme, il n'utilisera que quelques listes.

On gagne donc 48 octet tant qu'elles ne sont pas utilisées.
De toute façon, tout programme qui les utilisera leur donnera une dimension plus grande, donc elles occuperont plus de place en mémoire.

Donc selon moi, contrairement aux variables de A à Z (plus théta), il est utile de les supprimer complètement. Après c'est selon les programmes utilisés, mais il y a quand même une économie.

Je ne comprends pas ce que tu trouves de contraire aux variables réelles. Comme tu le dis si bien pour celles-ci, la place gagnée est illusoire. Alors pourquoi faire exception de 54 octets pour les listes face à 324 octets pour les variables réelles ?

Les listes ne sont pas forcément toutes utilisées mais les variables réelles non plus (de même, sauf si c'est un gros programme).

Bah un programme qui n'utilise pas de variable je n'en ait jamais vu (ou sinon hello world mais bon ).
Tandis que les listes c'est vraiment pas obligatoire.

De plus, ça "coute" moins pour les listes que pour les variables "réelles", puisqu'il y a déjà le ClrList.

Pour moi il y a quand même un gain ici...

Au pire tu fais ça manuellement et puis effvar fait aussi bien mieux que clrlist l'économie est identique plus importante alors que effvar l'efface complètement !!!
J'ai toujours fait ca manuellement puisque comme tu utilises ces octets lors de l'exécution, ça ne te permets pas de continuer un projet en cours sinon tu ne peux qu'exécuter hello world
Arrivé a 500 octets de RAM libre tu ne peux plus faire que des calculs, les programmes a peine lancés sont de suite stoppés par "erreur: mémoire".

rpfcreator a écrit:effvar fait aussi bien que clrlist l'économie est identique alors que effvar l'efface complètement

Heu... Tu te contredis pas là?
EffVar et Clrlist ne font pas la même chose (cf nos post ci dessus).

Heu... Oui enfin le faire manuellement c'est bien mais c'est pas dans l'esprit de programmation

Ca dépend du prgm et des variables qu'il nécessite...

Oui, honte a moi, je me suis trompé
Effvar fait MIEUX que clrlist et la place utilisée est moindre dans le programme
Je ne vois même pas l'utilité de clrlist...

Quand tu supprimes une liste elle disparaît de l'éditeur de liste dans le menu stat. C'est pénible de le réinitialiser si on veut garder des listes au nom personnalisé dans l'éditeur ou qu'on ne veut pas le chambouler.
Je ne voie que cette explication à l'existence de ClrList comparée à DelVar.
Néanmoins à partir de la ti83plus la mesure de la dimension nulle d'une liste est supportée, donc une liste vide peut alors être détectée contrairement à une liste absente.

Effvar fait MIEUX que clrlist et la place utilisée est moindre dans le programme

Mieux je suis d'accord avec toi (ça ne me dérange pas de devoir les rentrer à nouveau dans l'éditeur ultérieurement, mais d'un autre côté je l'utilise peu, pour ceux qui l'utilisent plus ça peut gêner...).
Mais que la place utilisée soit moindre dans le prgm ce n'est pas forcément vrai.

ClrList L1 [+ retour à la ligne obligatoire (on omet le cas de fin de prgm)]
ClrList = 1 octet
L1 = 2 octet (je viens de découvrir ça...)
Retour à la ligne = 1octet
Donc total = 4 octet

DelVar L1 (sans retour à la ligne) = 4 octet également (puisque DelVar fait 2 octet)

Donc pour une liste, la taille est équivalente.
Pour plusieurs listes, on est obligé, avec DelVar, de rajouter 4 octet par liste, alors qu'on en rajoute que 3 avec ClrList (virgule+liste).

Donc au final, ClrList est plus économique à ce niveau

Rectification: le saut de ligne ne prend qu'un octet (et le double point aussi)

En fait je sais que le retour à la ligne ne prend qu'un octet
Mais j'ai zappé une ligne en fait je voulais mettre total = 4 octet, mais je me suis planté x)

Bref ça ne change rien à ce que je dis sinon

Nope ces trucs la c'est très bizzare