Kakucomb : source GTC on calc - Page 1

Kakuro Combinaition (penser à renommer outbin.asm en kakucomb)

ainsi kakucomb(7,2) tapé sur l'écran HOME retournera [["1+6"];["2+5"];["3+4"]] sur l'écran HOME !!!
temps calcul: 1s maximum !!!

Merci Pollux Spécial dédicace (Même si le programme est modeste )

Commentaires, questions, bugs, améliorations (oh oui ! il doit y en avoir) ... n'hésitez pas !

(Désolé pour les explications non exhaustives ... j'ai dû taper ça en vitesse).

Pour l'instant elle bug un peu.

Je mets mon fichier asm :
Fichier joint : source.kakucomb.89t
(---elle contient un oubli : commentaire de la fonction BinTabToStr ==> nbrChfr chiffres au maximum seront placés.
--- elle contient un oubli : commentaire effet de bord de la fonction BinTabToStr ==> on verifie ... avec SommeTab ... si le tableau ne contient que des 0 et des 1
--- la fonction BinTabToStr de la version "89t zip" est mal structurée tout court ... (déclaration double de l'identificateur i, insertion d'une instruction entre les déclarations ... moi je dis, de temps en temps : il faut savoir faire dodo ) .

J'apporterais ultérieurement le code correctif (sans passer par un post de source, désolé, j'estime que cela serait du gaspillage) ultérieurement : il devrait se situer au niveau de la fonction BinTabToStr (et oui, encore la même )

alors juste qqs idées d'optimisation :
- pour calculer une puissance de 2 tu peux faire un décalage au lieu de passer par pow() : 1<<i est égal à pow(2,i), mais le calcul est bcp plus rapide
- pour accéder au i-ème chiffre binaire d'un nombre x tu peux faire simplement if (x & (1<<i) != 0) plutôt que de t'embêter avec pow2Act, nbrAct etc...
(pour savoir pourquoi c'est possible de faire ça : http://www.gamedev.net/reference/articles/article1563.asp )

euh sinon pourquoi tu stockes les résultats dans une matrice au lieu de mettre dans une liste ?

point 1 : j'avais oublié (il y a 5 ans que j'avais abandonné TIGCC), merci beaucoup : (en assembleur lsr, lsl (Low Shift Right/Left)
point 2 : je sais, c'est une question de masque
point 3 : merci beaucoup pour la doc

point 4 : merci beaucoup d'avoir donné de ton temps pour me conseiller :bounce: :bounce: :bounce:

Que penses tu des commentaires du programme , du nettoyage de TOP_ESTACK, de la lisibilité (Mes trois points forts du programme) ?

logical, quelle erreur de débutant

pour la lisibilité/commentaires je pense que c'est pas mal (enfin t'as p-ê voulu en faire trop, y a qqs commentaires superflus du style "entier compteur", "i : chaque element de la liste")
par contre niveau propreté utiliser des constantes genre 13 ou 9 c'est pas très joli... de même je vois pas vraiment pourquoi tu initialises les tableaux comme "resultats", "copie" ou "tabComb" ?

pour l'estack j'en sais rien parce que je programme plus trop sur TI, par contre j'ai l'impression que tu vérifies pas s'il y a pas des arguments en trop ^^

[REM : changement de nickName]

*** niveau commentaires : c'est vrai que j'ai trop voulu être exhaustif
*** niveau constantes : je n'ai pas compris pourquoi cela n'est pas joli d'initialiser à 13 ou à 9
*** niveau initialisation tableaux : c'est l'habitude du Java sur PC
*** niveau estack : c'est vrai, je me suis contentné de reprendre le code de nettoyage estack figurant sur la doc de TIGCC

linkof64 (./8) :
*** niveau constantes : je n'ai pas compris pourquoi cela n'est pas joli d'initialiser à 13 ou à 9

Tu perds :
- en flexibilité : si tu veux passer par exemple à des sommes contenant plus de 9 nombres tu es obligé de rechercher 9 partout dans le programme, et à chaque instance deviner si c'est bien ce 9 là ou bien si c'est un 9 qui n'a rien à voir avec la quantité de nombres dans chaque somme ; l'autre problème c'est que 512 et 511 sont liés à 9, mais ce lien n'apparaît pas explicitement donc même en changeant tous les 9 ça ne suffirait pas
- en lisibilité : si tu as NUMBERS_PER_SUM à la place de 9 on sait tout de suite d'où ça vient (et on peut éventuellement se référer à la définition commentée de NUMBERS_PER_SUM pour avoir plus de détails), de même si tu as (1<<NUMBERS_PER_SUM)-1 c'est à mon avis beaucoup plus clair que 511

linkof64 (./8) :
*** niveau initialisation tableaux : c'est l'habitude du Java sur PC

Oui, mais là aussi tu perds en flexibilité parce que tes tableaux auront une taille que tu ne pourras pas modifier facilement ; en lisibilité parce que tes "7+0+0+0+..." ne correspondent à rien du tout ; et en taille parce que le programme compilé devra contenir des informations inutiles...

[Re changement de login]

Erk !! Rien compris : tu me surestimes là Pollux dans ton explication !

C'est plus facile si tu veux changer qqch plus tard d'avoir toutes les constantes regroupées dans un même endroit au début du programme

Les consantes : j'aurais du penser à la directive #define (et j'ai compris ton explication du post 8 --> *** changer partout
*** 2 puissance x - 1)

Pour les tableaux, j'ai échoué à l'utilisation de malloc ou de HeapAllocPtr ---> d'où le procédé

oui c'est très bien de les allouer sur la pile comme ça, c'est juste que c'est pas la peine de les initialiser, il suffit d'écrire :
int resultats[13];

Ah oui, pour tout int/char déclaré, c'est 0 par défaut. Il n'est pas obligatoire d'assigner une valeur, comme il faut le faire en Java.

Je ne crois pas.
En Java, si tu ne précises pas de valeur lors de la déclaration d'attribut de classe, elle est automatiquement initialisée à 0 pour les types de base ou à null pour les Object.
En C si tu ne précises rien tu peux obtenir n'importe quoi.
Pour les tableaux c'est un peu plus subtil : int tab[3]={}; est équivalent à int tab[3]={0,0,0};

Sasume (./15) :
En C si tu ne précises rien tu peux obtenir n'importe quoi.

Oui, c'est vrai Un excellent prof me l'avait expliqué.

Ahhhh, quel niiob je suis (après l'équivalent de 3 mois en programmation TIGCC) :

le résultat obtenu est horrible, ce programme est une véritable usine à Gaz ... je ne veux plus continuer, ce programme , comme beaucoup d'autres par le passé, me dépasse !

Je ne comprends pas pourquoi le code suivant ne fonctionne pas, pouvez-vous m'aider ?

#define USE_TI_89
#define MIN_AMS 101
#define RETURN_VALUE

#include <estack.h>
#include <string.h>

void PushResultat(char ** resultats, int numElem){
   push_zstr(resultats[numElem]);
}

void _main(){

   static char resultats[3][18];

   /******************** 
   nettoyage de la pile
   *********************/
   
   while(GetArgType(top_estack)!=END_TAG) 
         top_estack = next_expression_index(top_estack);
   top_estack -= 1;

   /************************
   attribution du resultat
   *************************/
   strncpy(resultats[1], "1+5+6+7", 18-1);

   /***************************
   on pousse le resultat
   ***************************/
   PushResultat(resultats,1);

}

Et bien le programme obtenu me retourne une chaîne vide

Je n'ai pas regardé en détails, mais char **var et char var[3][18] sont deux types différents.
Essaie avec ça : void PushResultat(char (*resultats)[18], int numElem){

oui, l'erreur vient de là ^^ mais il n'y avait pas de warning, ce sera corrigé dans la prochaine version de gtc...

Merci

Mais quelqu'un pourrait-il m'expliquer plus en détails mon erreur ? J'ai une grande envie de retenir le défaut de mon code pour ne plus la reproduire à l'avenir .
Peu importe si l'explication me paraitra trop complexe au premier abord.

c'est parce qu'un char * et un char[18] sont stockés différemment en mémoire : le char * stocke juste le pointeur vers les données sur 4 octets, alors que le char[18] stocke directement les données elles-mêmes (donc sur 18 octets). Du coup si tu fais un tableau de char * ce n'est pas du tout la même chose qu'un tableau de char[18] -- par exemple la taille d'un tableau de char* à n éléments sera de 4*n octets, alors que c'est 18*n octets pour les char[18]...

Note que la solution de Sasume peut s'écrire différemment :

typedef char chaine_de_18_caracteres[18];

void PushResultat(chaine_de_18_caracteres *resultats, int numElem){ ... }

void _main(){ 
   static chaine_de_18_caracteres resultats[3];
   ...
}

Et bien je vais peut-être te surprendre (on entre dans la programmation bien avancée, donc il faut être prêt) ... mais j'ai tout compris
Merci Tu as très bien expliqué le concept.

Maintenant, j'ai tout ce qu'il me faut pour recoder entièrement et proprement mon programme kakucomb.

Si mes souvenirs sont bons, pour la fonction, j'ai le droit d'écrire directement :
void PushResultat(chaine_de_18_caracteres resultats [], int nbrElem){}

Martial Demolins >>> Pollux m'a en fait expliqué la différence entre char * [n] et char[18][n], d'où le n*18 octets.

Bon, voici l'état des lieux de mon programme Kakucomb, entièrement rénové, en ce jeudi 17 mai 2007 (Ouais, un jour férié !!!)

--- Le programme fonctionne parfaitement sur une base de 9 symboles (celle du Sudoku / Killer Sudoku traditionnel).
--- Le set de caractères pour 16 symboles (la table ASCII ne me correspond pas pour cela, à cause de l'ordre des caractères chiffres/lettres) est déjà en place, et le jeu de constantes aussi. Mais quand je configure le programme à 16 symboles, il bloque je ne sais pour quelle raison.
--- Ce n'est plus un simple tableau que je passe à mes fonctions, mais une structure SommeKakuro contentant aussi bien la représentation char *, que le char codant le nombre de symboles effectivement utilisés et le int représentant la somme représentée. La maintenance en est donc considérablement facilitée (si l'on en tient pas compte de la place du code)
--- Pollux, il y a peut être encore un bug de GTC. Si cela se confirme, je te le dirais.

Pollux : voilà pour toi ce que je suppose être un bug de compilation :


Le bug réside, comme décrit dans le fichier texte associé, tout simplement dans le fait que GTC parvient à compiler une ligne qui ne devrait pas l'être, une ligne du genre :
strncmp("1+3+5","2+3+5",/****************/).

Comment ai-je eu cette idée ? Je voulais me constituer un genre de signet et j'ai appuyé par erreur sur F5. (Je savais déjà, avant même d'appuyer que le résultat constiturait un anomalie).

oui, tu as raison c'est corrigé (mais pas encore dans la version oncalc signée)

Voilà mon nouveau programme kakucomb, entièrement réécris pour tenir compte des remarques que vous m'avez faîtes sur ce forum. Mais juste deux hics :
--- j'ai oublié de vous "créditer" (remarquez, le programme n'est pas assez extraordinaire que cela pose vraiment problème ...)
--- si je définis la base à 16 symboles, alors que j'ai prévu un set à cet effet, ça génère un blocage.
Voilà :