100 Strings sur votre TI : C'est POSSIBLE !! - Page 1

La TI est limité à 10 strings... C'est pas énorme, si on veut stoquer pleins de chaines de charctères...
Mais on peut aussi sauver les str dans les y1, y2, ...y0 avec String>Equ(, puis enregistrer les 10 equations dans unes des GBD avec StoreGBD.
Ce qui fait donc 10 GBD * 10 équations = 100 equations que on peut stocker en même temps sur la calto, donc 100 string (on peut passer de l'equation à la String par Equ>String(.
Bien sûr, on pourrais faire 110 avec les 10 Str, mais je ne les compte pas, car il faut toujours ne rien sauver dedan, vu que après, c'est elles que on manipule dans les progs...

Je fait un exemple de prog possible :

// début du prog, il faut charger toutes les Str...
RecalGBD 0
Equ>String(y0,Str0)
...                   // on est obligé de mettre les 10 a la suite, même si c'est un peut lourd...
Equ>String(y9,Str9)


//ici, le prog, où on manipule les différentes Str...

//fin du prog, on sauve toutes les Str...
String>Equ(Str0,y0)
...                  //idem, il faut écrire les 10 ; ça ne se simplifie pas avec une boucle
String>Equ(Str9,y9)
StoreGBD 0   // on enregistre bien sûr dans la m^me GBD que celle du début

Et voila...
A la limite, ça pourrait même constituer un sous-porgramme
Remarque: mais on ne peut pas faire StoreGBD A, ou RecalGBD A où A serais le numéro de la GBD...

Et en plus, on peut en profiter pour sauver différentes variables numériques dans las valeurs de Window ! (elles sont toutes dans [vars], [1:window]) (soit 7*10=70 !)

Marrant ^^.

Mais bien pratique


Et prend aussi pas mal de place XD

Bof. Je trouve que les 10 sont largement suffisantes.

oui, mais après faut voir de l'utilisation que tu peut en faire, si tu les utilises pour sauvegarder des chaines de caractères pour des progs... Ca peut alors s'avèrer utile

Oué mais on peut mettre 2 chaînes dans une seule.

ou plus aussi, et ça devient vite dure à gérer, et puis si tu as deux progs (ou plus) qui utilisent les mêmes strings...
Enfin, c'est vrai que pour une "consomation " normale, les 10 strings suffisent, mais si on veut plus, c'était juste pour dire que y a moyen

Ca peut etre marrant si on créait un systeme de sauvegarde de maps dans des strings par exemple. Plus facile a gérer d'avoir une map par string, surtout si celle ci sont de tailles variables. Mais les strings peuvent le faire aussi. Pas mal.

Hum, sinon, ça marche assez bien aussi avec une liste qui gère les index, et instring. Bon, c'est pas la joie à modifier, c'est vrai.

Mais sinon, tu peux vraiment faire 255 strings.
Il suffit de prendre un petit prog, du genre: http://www.ticalc.org/archives/files/fileinfo/391/39138.html

Et puis en plus, t'as pas besoin d'avoir le programme en question à l'exécution.

Ah, zut, ce prog là marche, mais j'en avais un en basic, attendez que je le retrouve^^

Ca pourrait être vraiment utile, si on pouvait accéder à une chaîne de caractères comme ceci : Str A, où A est une variable naturelle.

Oui, c'est clair.
Mais bon, en basic, y'a vraiment pas mal de fonctionnalités qui manquent.

(Par contre, à l'accès, on peut résoudre ce pb avec un Expr(Sub(...,A,1)); mais tu peux pas pour la modification...)

oui, et c'est pas bête, ça allége un peut un programme...

Une rapide remarque: solution intéressante, mais les GDB prennent beaucoup de place (vers 800 octets ?)

Une autre solution parfois plus adapté: stocker n strings dans un string de la calculette en concaténant (mettant suite à suite) et se souvenir des emplacement de chaque 'vrai' string ( 1 caractère à 24 = premier, du 25 à 42 second, ..)
il suffit ensuite d'enregistrer cette suite ( 1,25,43,..) dans une liste, et de procéder à l'extraction en temps voulu et le stocker dans une (ou plusieurs) 'vraie' variable string qui sert de tempon temporaire si besoin. (genre str1 sert à stocker le vrai string à afficher couramment, et string2 contient les 142 strings du jeu )


Possibilité: théoriquement infinie, en pratique limité par la taille max de chaque string (une idée ?). Vitesse de l'extraction: Plus rapide que de rappeler un GDB (si l'OS n'est pas trop mal codé, pour ce que j'en connais )

Yep, il est toujours plus facile de manipuler des nombres.

very (./15) :
Possibilité: théoriquement infinie, en pratique limité par la taille max de chaque string (une idée ?)

Tu devrais suivre mon lien parce que tu trouveras pas de solution plus rapide... http://www.ticalc.org/archives/files/fileinfo/265/26546.html

Sinon, pour accéder à une chaine en fonction d'un nombre (variable)... Eh ben, pour la modification des données, ça fait une vitesse pourrie, donc sur Ti, à part avec une librairie Asm, je vois pas...

gon33 (./17) :
Tu devrais suivre mon lien parce que tu trouveras pas de solution plus rapide... http://www.ticalc.org/archives/files/fileinfo/265/26546.html

trop gros, ( 5000 octets !! ) et .. revient à utiliser une lib asm. (j'ai regardé très rapidement ). donc autant utiliser une lib asm qui fait ça proprement, ça fera 150 octets..
Ou alors hardcoder dans une variable d'un autre type à la main..

gon33 (./17) :
Sinon, pour accéder à une chaine en fonction d'un nombre (variable)... Eh ben, pour la modification des données, ça fait une vitesse pourrie, donc sur Ti, à part avec une librairie Asm, je vois pas...

Ben c'est une solution souvent utile quand tu connais déjà *au début* du programme la grande majorité des strings que tu va afficher.. ( mais bon en général si on peut c'est plus simple de mettre directement les chaines de cratères sur l'instruction qui va les sortir, c'est certain ), en tout cas lorsque à un moment donné tu le a à peu près tous.. clair que pour modifier c'est pas ça.

Mais bon ça c'est un peu de la faute à Ti: chez tous les gens normaux un string, c'est codé comme un tableau, c'est trivial (temps constant) de modifier un élément ( on connait direct la case mémoire à accéder ). Chez Ti, un string, bon au début y'a la taille prise en octets, le nom, puis c'est juste une suite de tokens consécutifs en mémoire. Le problème, c'est que certains tokens font 2 octets et d'autres 1. Donc est est incapable d'accéder au n-ièm cratère autrement qu'en vérifiant un par un si chaque caractère fait un octet ou deux.. donc c'est catastrophique. (enfin c'est plus une structure de liste chainée que de tableau quoi)

Pour ça que les sub( sont longs etc.. ( et bon après y'a un jeu d'instructions pas très complet mais ça c'est encore de la faute à Ti )

Non, suis *vraiment* le lien!

Ca prend pas 5000 octets.
Ce sont les vraies chaines de caractères, de 1 à 255... (sauf qu'elles ont des noms bizarres...)

Programme de 5276 octets sur Ti.. j'ai suivit *vraiment* ton lien, j'ai jeté un cp d'oeil sur le code, le readme et l'ait exécuté.... bon ensuite j'ai lu le read-me lisible (ie en html, quelle connerie d'en écrire en .doc..) et visiblement on est obligé de faire ça à la main en exécutant manuellement le programme.. donc quand tu transmet le prog tu fais comment ? (on arrive à transférer les vars hackés ?)

Bon j'ai reluké un peu plus précisément le code ( par ce que c'est intéressant – bon en fait par ce que je dois bosser – ), alors le plus comique c'est qu'il utilise la méthode que j'ai décrite dans son programme (pour "proposer les noms de variables"), c'est ça qui prend tant de place

Ils utilise pleins de méthodes horribles en Ti-basic ( ce qui arrange pas la taille du prog. ), et le hack visiblement est soit fait grâce à la création d'une variable supplémentaire en mémoire par hack (vielle technique de débordement qui a permis l'asm sur 82, etc), soit par une petite routine assembleur qui créer cette variable, soit par une méthode que je ne connais/comprends pas encore

Ouaip, mais ça marche bien^^

Je me permet de upper ce topic.

Pourquoi, hinhin, mystère... oui d'accord je vous le dit (pourquoi upper le topic sinon ) : j'ai trouvé la onzième chaine de caractère sur ma ti 84+ !

Alors oui, j'ai un peu bidouillé, mon éditeur m'a beaucoup aidé.

Celle-ci semble bien fonctionner, sauf qu'elle s'affiche par un "?" dans la calc ^^.

A la prochaine version de mon éditeur promis je vous permet de l'avoir vous aussi

C'est bon pour moi, j'ai déjà les 255^^

Elles sont toutes aussi rapides qu'un string normal ?

Je sais pas. Déjà, faudrait vérifier qu'elles tiennent sur un octet comme les normales, et je pense pas que ce soit le cas...

Les Str normales tiennent sur deux octets. Quand tu mets Str1 dans ton prog par exemple, ton prog est plus lourd de 2 octets. C'est bien de ce poids que tu veux parler ?

Moi je trouve ça incroyable le string caché, je suis super content d'avoir découvert ça. Le problème c'est que je sais pas trop si ça marche sans bug. Faudrait voir.

myst6re n2 (./27) :
Les Str normales tiennent sur deux octets. Quand tu mets Str1 dans ton prog par exemple, ton prog est plus lourd de 2 octets. C'est bien de ce poids que tu veux parler ?

Oui, c'est bien de ça que je parle...
Jusqu'à maintenant, j'ai pas eu de problèmes avec...

Faut voir pour les transferts, les dégroupages, MirageOs, etc...

Tiens d'ailleurs, une petite anecdote comme ça:
Vous aurez surement remarqué que parfois la fonction Rand donne des résultats incohérents (genre 0.85 E99)
Bon, c'est un truc qui s'enlève facilement en faisant 1->Rand ou en mettant n'importe quelle valeur... (Attention, on connait d'avance la suite infinie que donne rand par la suite...)
Le seul ennui, c'est que MirageOs ne le supporte pas. Ca fait de très jolis Ram Clear pour du Ti Basic^^