Coder un algorithme récursif

Hello les clickeurs,

Savez-vous comment coder une fonction récursive avec Fusion ?

En C, c'est tout con, c'est une fonction qui s'appelle elle-même :

int produit(int n, int x)
{
  if (n > 0)
    return produit(n - 1, x) + x;
  else
    return 0;
}

Mais avec Fusion, comment faire la même chose sans rendre le bordel ingérable, genre une boucle dans une boucle, dans une boucle...

Ca a toujours été un problème.
Peut être en créant des objets actifs invisibles et utiliser les variables.

Pourquoi tu ne veux pas faire une boucle qui s'appelle elle-même, c'est pourtant ce que fait un appel récursif?
Condition de départ -> lancer boucle "fonctionrec" 1 fois

On "fonctionrec"
+ Condition de continuation -> actions à faire + lancer boucle "fonctionrec" 1 fois

Cela dit, j'ai pas testé mais je ne vois pas pourquoi cela ne fonctionnerait pas.

Le problème est que le principe de la récursivité c'est une fonction qui s'envoi elle même un paramètre.

Salut salut,
Je pense que ça dépend principalement que ce qu'on cherches à faire. J'avoue que sans situation concrète j'ai un peu de mal avec le concept de fonctions récursives.

Pourquoi tu ne veux pas faire une boucle qui s'appelle elle-même, c'est pourtant ce que fait un appel récursif?
Condition de départ -> lancer boucle "fonctionrec" 1 fois

On "fonctionrec"
+ Condition de continuation -> actions à faire + lancer boucle "fonctionrec" 1 fois

Cela dit, j'ai pas testé mais je ne vois pas pourquoi cela ne fonctionnerait pas.

Merci Conceptgame pour ton aide. Mais cette solution ne fonctionne pas dans le cadre d'un backtracking. Faire une boucle infinie avec une condition d’arrêt reviendrait au même. Ici, le but est de s'enfoncer dans les tests, tout en ayant la possibilité de remonter d'un cran (retour sur trace).
C'est par exemple très utilisé pour rechercher une solution à un problème par bruteforce, en parcourant en profondeur un "arbre" tout en ayant la possibilité de revenir en arrière quand un blocage se présente, afin d'emprunter un autre chemin.

C'est bon, j'ai réussi !!!
j'ai créé un solveur de Sodoku en 10 lignes de code  :sonic

Un peu chiant à expliquer mais pour faire simple, dans une boucle n, on sauve l'état à n-1 dans une variable. Comme ça, on sait y retourner en cas de backtracking et continuer là où on s'était arrêté grâce à cette variable.

Bravo !
J'étais sûr que c'était possible.
A l'occasion une petite explication, un mfa même payant sur le ClickStore, ce serait super.

Bravo Cyberclic.

Il y a un exemple qui existe pour mmf2, mais le concept ramait, le mot est faible, le temps de proposer une grille valide.

Edit:

Des explications trouvées sur la toile.

3. Une logique vicelarde : la programmation récursive
Vous savez comment sont les informaticiens : on ne peut pas leur donner quoi que ce soit sans qu’ils essayent de jouer avec, et le pire, c’est qu’ils y réussissent.
La programmation des fonctions personnalisées a donné lieu à l'essor d’une logique un peu particulière, adaptée en particulier au traitement de certains problèmes mathématiques (ou de jeux) : la programmation récursive. Pour vous expliquer de quoi il retourne, nous allons reprendre un exemple cher à vos cœurs : le calcul d’une factorielle (là, je sentais que j’allais encore me faire des copains).
Rappelez-vous : la formule de calcul de la factorielle d’un nombre n s’écrit :
N ! = 1 x 2 x 3 x … x n
Nous avions programmé cela aussi sec avec une boucle Pour, et roule Raoul. Mais une autre manière de voir les choses, ni plus juste, ni moins juste, serait de dire que quel que soit le nombre n :
n ! = n x (n-1) !
En bon français : la factorielle d’un nombre, c’est ce nombre multiplié par la factorielle du nombre précédent. Encore une fois, c’est une manière ni plus juste ni moins juste de présenter les choses ; c’est simplement une manière différente.
Si l’on doit programmer cela, on peut alors imaginer une fonction Fact, chargée de calculer la factorielle. Cette fonction effectue la multiplication du nombre passé en argument par la factorielle du nombre précédent. Et cette factorielle du nombre précédent va bien entendu être elle-même calculée par la fonction Fact.
Autrement dit, on va créer une fonction qui pour fournir son résultat, va s’appeler elle-même un certain nombre de fois. C’est cela, la récursivité.
Toutefois, il nous manque une chose pour finir : quand ces auto-appels de la fonction Fact vont-ils s’arrêter ? Cela n’aura-t-il donc jamais de fin ? Si, bien sûr, rassure-toi, ô public, la récursivité, ce n’est pas Les Feux de L’Amour. On s’arrête quand on arrive au nombre 1, pour lequel la factorielle est par définition 1.
Cela produit l’écriture suivante, un peu déconcertante certes, mais parfois très pratique :
Fonction Fact (N en Numérique)
Si N = 0 alors
  Renvoyer 1
Sinon
  Renvoyer Fact(N-1) * N
Finsi
Fin Fonction
Vous remarquerez que le processus récursif remplace en quelque sorte la boucle, c’est-à-dire un processus itératif. Et en plus, avec tous ces nouveaux mots qui riment, vous allez pouvoir écrire de très chouettes poèmes. Vous remarquerez aussi qu’on traite le problème à l’envers : on part du nombre, et on remonte à rebours jusqu’à 1 pour pouvoir calculer la factorielle. Cet effet de rebours est caractéristique de la programmation récursive.
Pour conclure sur la récursivité, trois remarques fondamentales.

    la programmation récursive, pour traiter certains problèmes, est très économique pour le programmeur ; elle permet de faire les choses correctement, en très peu d'instructions.
    en revanche, elle est très dispendieuse de ressources machine. Car à l’exécution, la machine va être obligée de créer autant de variables temporaires que de « tours » de fonction en attente.
    Last but not least, et c’est le gag final, tout problème formulé en termes récursifs peut également être formulé en termes itératifs ! Donc, si la programmation récursive peut faciliter la vie du programmeur, elle n’est jamais indispensable. Mais ça me faisait tant plaisir de vous en parler que je n’ai pas pu résister… Et puis, accessoirement, même si on ne s'en sert pas, en tant qu'informaticien, il faut connaître cette technique sur laquelle on peut toujours tomber un jour ou l'autre.

Source:
http://pise.info/algo/complements.htm

Perso, pas trop bossé le sujet qui semble, pour le moins utile avec CTF, histoire de réduire le klik code.

On utilise des trucs avec un langage code, que l'on ne pense pas forcément à "translater" (transférer?) sur un klik soft.

Merci Kloug pour ce pavé  :D

Mon solveur de Sudoku est ultra rapide, car je l'ai optimisé à fond. 10 lignes de code, aucun calcul inutile. Il résout n'importe quelle grille, de la plus simple à la plus complexe, en quelques millisecondes.

Je le mettrais en ligne bientôt. Encore quelques bugs à corriger.

Merci à toi Cyberclic.  :D

MDR => Pas capter solveur de Sodoku, moi gros nul, avoir compris générateur de grilles sodoku.
Areuh! Areuh!, Je retourne à la maternelle.

Exemple réalisé avec TGF1:
https://www.dropbox.com/s/zezrlyhvcztvwpm/Cellule%20Sudoku%20ok.mfa?dl=0

J'ai hâte de voir ton exemple, bon courage pour la suite.

Voici mon solveur en .exe  :P
Le code source pourra être distribué selon mon envie et à quelques clickeurs de confiance.

Il est très moche, c'est juste le moteur qui compte dans un premier temps.

Je n'ai pas encore implémenté le contrôle en cas de grille impossible à résoudre, du coup l'application se figera (boucle infinie). Donc utilisez des grilles possible à résoudre.

Il peut être mis en échec sur des grilles conçues pour mettre à mal les algos de résolution.

Le pire des cas étant :



La raison est que la  solution vient vers la fin de la descente récursive, et le nombre d'essais/erreurs est tellement grand qu'on arrive aux limites de CTF. En C, ça met 20 secondes à être résolu.

Sinon sur des grilles facile à démoniaque "grand public" ça résout en moins d'une seconde.

:bravos

Félicitations!

J'en reste sur le popotin, il s'agit d'un très bon résolver de grilles, moins d'une seconde pour une grille "standard".



Cyberclic, tu mérites une médaille klik pour cet exploit!

Ton adaptation pour CTF est spectaculaire, encore bravo.

:bravos  :bravos  :bravos

Mon truc est un vérificateur de grilles, rien de comparable avec ton travail.

Ca c'est mon loulou !! J'ai rien à dire, je passe par là...et je suis fier de travailler au quotidien avec toi mon lapin ! C'es tout, bises à tous.... :bravos

On va se faire un p'tit jeu de Sudoku sur mobile avec quelques concepts inédits, ma canaille  ;) Et à nous la richesse, ou pas  :P

Merci à tous pour vos retours.

Pour sûr, je serai curieux de décortiquer le klik tableau, pour voir comment en pratique, tu as déterminé l'ordre de parcours de la grille, en remplissant les cases ayant le moins de possibilités de nombre, aux cases en ayant le plus.

En théorie c'est ainsi, tu as peut être choisi de faire autrement...

Tu as utilisé quoi pour mémoriser l'ordre de remplissage de la grille?
L'objet tableau?

Édit:
Je t'envoie un MP, si tu le permets...

Ouahh, c'est un tout autre niveau de Fusion ça, que je ne connaissais pas  !!  :o

Normalement, c'est un niveau que l'on doit avoir quand on maîtrise un langage code.

Fonctions et procédures II : la récursivité
https://openclassrooms.com/courses/apprendre-a-programmer-avec-ada/fonctions-et-procedures-ii-la-recursivite

Le léger souci est la translation vers CTF => Humour.

Pour mieux comprendre l'exploit réalisé.

Le backtracking par l'exemple : résoudre un sudoku
https://openclassrooms.com/courses/le-backtracking-par-l-exemple-resoudre-un-sudoku

Avec un langage code on ne capte pas trop le truc, il reste la bonne vieille méthode du copier, coller.

Là, on doit passer par une interface "limitée", en klik and play code, le backtracking n'existait pas jusqu'à Cyberclic.

Édit:
On parle backtracking efficace, capable de résoudre une grille sudoku en moins d'une seconde.

j'avais loupé se spots honte a moi je vient de test c est remarquable Cyberclic  :bravos