Discussion :

[tomlev]

Peut être un indice? J' ai utilisé une fonction récursive et Math.Pow ça tient sur 3 lignes et j'obtient que le score de 2/3.
Sur quoi se basent-ils pour noter le skill?

Pas besoin de récursivité... De plus le nom de la section ("loops") est un indice, mais il n'est pas indispensable d'utiliser une boucle explicite (ou même une boucle tout court, cf. le message d'Ivelios)

[23JFK]

Peut-être parce que c'est une erreur de syntaxe (en C# en tous cas)

Pas en java, les deux sont permises.

[miky55]

Pas besoin de récursivité... De plus le nom de la section ("loops") est un indice, mais il n'est pas indispensable d'utiliser une boucle explicite (ou même une boucle tout court, cf. le message d'Ivelios)

Effectivement si j'entre la formule de wikipedia j'obtient 3 points, cela dit on demande rarement à un dev de pondre une formule mathématique. J'ai trouvé que solutionné une suite arithmétique avec une fonction récursive était la solution la plus logique, de plus techniquement une fonction récursive est une "loop".

[tomlev]

Effectivement si j'entre la formule de wikipedia j'obtient 3 points, cela dit on demande rarement à un dev de pondre une formule mathématique.

Effectivement... Perso j'ai utilisé Linq. Voilà ma solution :
https://gist.github.com/thomaslevesq...b96bf8dc9050f8
(je mets un lien plutôt que de poster le code directement, pour éviter de spoiler pour ceux qui l'ont pas encore fait)

techniquement une fonction récursive est une "loop".

Bah non... Dans le cas de la récursion terminale, ça revient effectivement à faire une boucle, mais pas dans le cas général. Une fonction itérative réalise une boucle, mais pas une fonction récursive

[miky55]

Effectivement... Perso j'ai utilisé Linq. Voilà ma solution :
https://gist.github.com/thomaslevesq...b96bf8dc9050f8
(je mets un lien plutôt que de poster le code directement, pour éviter de spoiler pour ceux qui l'ont pas encore fait)

J'imaginais meme pas qu'on puisse ajouter des namespaces .NET, ils ont vraiment poussé le truc, je pense que le code doit être vraiment compilé coté serveur, le concept est vraiment très prometteur pour apprendre en ligne!

Bah non... Dans le cas de la récursion terminale, ça revient effectivement à faire une boucle, mais pas dans le cas général. Une fonction itérative réalise une boucle, mais pas une fonction récursive

Je pense que ça se discute, ça relève plus de la terminologie qu'autre chose, tu fais le raccourci boucle=itérative alors que l'on parle de boucle infinie lorsqu'il manque une condition d’arrêt dans une fonction récursive.

[Iradrille]

Concept intéressant mais le fait que des contraintes soient ajoutés à chaque fois qu'on test son code c'est assez frustrant.

Petite question au passage : On ne peut pas "jouer" avec l'overflow des int en C# ? (cf screenshot http://uppix.net/AWS8yX.png)

[tomlev]

Je pense que ça se discute, ça relève plus de la terminologie qu'autre chose, tu fais le raccourci boucle=itérative alors que l'on parle de boucle infinie lorsqu'il manque une condition d’arrêt dans une fonction récursive.

Si tu ne mets pas de condition d'arrêt dans une fonction récursive, ça fait pas une boucle infinie... ça fait une stack overflow, parce que tu consommes tout l'espace disponible pour la pile (sauf, là encore, dans le cas d'une récursion terminale)

[tomlev]

Petite question au passage : On ne peut pas "jouer" avec l'overflow des int en C# ? (cf screenshot http://uppix.net/AWS8yX.png)

Si, avec les instructions checked/unchecked ; par défaut tu es dans un context unchecked, c'est à dire qu'un overflow ne provoque pas d'erreur. Mais la méthode Sum de Linq fait la somme dans un contexte checked, donc ça déclenche une OverflowException (c'est d'ailleurs indiqué dans la doc). Donc il faut soit faire la somme toi-même (avec une boucle ou avec la méthode Aggregate), soit faire un cast en long pour ne pas avoir d'overflow sur la somme et convertir le résultat en int.

[Etanne]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
public static bool Puzzle(int a, int b, int c) {         
		return (Math.Pow(Math.Min(a,b),2)==(Math.Max(a,b)+c)*(Math.Abs(c-Math.Max(a,b))))?true:false;
    }

"You wrote elegant code!"

Plus le code est court (sans { } !!) plus il est élégant.. ..merci Microsoft de nous montrer les bonnes manières.

[tomlev]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
public static bool Puzzle(int a, int b, int c) {         
		return (Math.Pow(Math.Min(a,b),2)==(Math.Max(a,b)+c)*(Math.Abs(c-Math.Max(a,b))))?true:false;
    }

"You wrote elegant code!"

Plus le code est court (sans { } !!) plus il est élégant.. ..merci Microsoft de nous montrer les bonnes manières.

J'avoue, je comprends pas trop ses critères pour juger de "l'élégance" du code

Soit dit en passant, c'est redondant d'écrire x ? true : false, tu peux retourner directement x

[Etanne]

J'avais zappé cette évidence (issue d'un copier-coller )

[23JFK]

'CodeHunt.JavaExtras' does not contain a definition for 'ArrayToString'

Ce jeu a manifestement des lacunes dans sa partie java. A croire que leurs créateurs veulent promouvoir le C#


Pour mémoire, l'erreur vient avec ce type de code

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
public class Program {
    public static String Puzzle(String s) {
        
        char[] c = s.toCharArray();
        
        for(int i = 0; i < c.length; i++)
            c[i] = (char)(((((int)c[i]-(int)'a')+5) % 26) + (int)'a');
                   
        return String.valueOf(c);
    }

vi, le truc n'est pas non plus très doué pour les conversions implicites

[miky55]

Si tu ne mets pas de condition d'arrêt dans une fonction récursive, ça fait pas une boucle infinie... ça fait une stack overflow, parce que tu consommes tout l'espace disponible pour la pile (sauf, là encore, dans le cas d'une récursion terminale)

Désolé de revenir à la charge, mais je dois avoir l’esprit de contradiction si j'oublie de mettre une condition d’arrêt dans une boucle récursive, je risque d'avoir un stcak overflow, mais ça n'est pas obligatoire peut être qu'une autre exception va être levée avant (comme une division par zéro). De la meme manière une boucle while qui ne remplit jamais sa condition et qui recourt à la pile pourra lever un stack overflow. Bref tu mélanges un concept théorique qu'est une boucle infinie et une cause technique relative à la limitation physique d'un pc...

[tomlev]

si j'oublie de mettre une condition d’arrêt dans une boucle récursive, je risque d'avoir un stcak overflow, mais ça n'est pas obligatoire peut être qu'une autre exception va être levée avant (comme une division par zéro).

Là tu chipotes... Oui, bien sûr, une autre exception peut se produire avant ; mais s'il n'y a pas d'erreur, ni de condition d'arrêt, ça finira par une stackoverflow. D'ailleurs, même sans erreur et avec une condition d'arrêt, tu peux avoir une stackoverflow. Exemple classique : le calcul récursif d'une factorielle. Tu n'arriveras jamais à calculer la factorielle de 1000000 de cette manière, tu auras un stackoverflow avant (même en supposant que tu utilises un type de données qui supporte des valeurs aussi grandes)

D'autre part, la notion de "boucle récursive" n'a pas vraiment de sens...

De la meme manière une boucle while qui ne remplit jamais sa condition et qui recourt à la pile pourra lever un stack overflow.

Qu'entends-tu par "recourir à la pile" ? La pile contient les paramètres et les variables locales pour chaque appel de méthode ; le nombre de paramètres et de variables locales ne change pas, donc tant que tu n'appelles pas d'autres méthodes, tu ne recourt pas à la pile. Je serais curieux de voir un exemple d'une boucle while qui déclenche une stackoverflow (et qui n'appelle pas de méthode récursive, évidemment, parce que dans ce cas ce serait la récursion qui causerait la stackoverflow et non la boucle)

Bref tu mélanges un concept théorique qu'est une boucle infinie et une cause technique relative à la limitation physique d'un pc...

En l'occurrence ce n'est pas une limitation physique à proprement parler (même si la limite physique théorique existe en effet, vu qu'on a pas encore inventé la RAM infinie), mais plutôt une limite arbitraire imposée par le système (en .NET c'est 1Mo par thread pour la pile)

Une boucle infinie, sauf cas particulier, peut tourner indéfiniment quelles que soient les limitations de la pile ; une récursion infinie pourrait effectivement marcher en théorie s'il n'y avait pas de limitation de la pile, mais ça ne change rien au problème : on vit dans un monde réel avec des limites réelles, pas dans un monde imaginaire où tout est permis...

Donc je maintiens que c'est plutôt toi qui mélanges récursion et itération... Je vois pas quoi te donner de plus comme argument, c'est juste pas la même chose. C'est comme si tu soutenais que tourner en rond dans un manège (boucle) est équivalent à creuser un puits (récursion) (oui je sais, l'analogie est un peu foireuse...)

[23JFK]

Y a qu'a dire qu'une récursion à besoin de conserver les données de l'appel précédent ce qui conduit à empiler les données de chaque appel de fonction alors qu'une itération, n'ayant pas besoin des données antérieures, peut les écraser. Dans le cas de la récursion le besoin d'allocation mémoire est variable et nécessairement croissante avec la longueur du calcul, alors qu'avec une itération la valeur allouée est constante et indépendante de la longueur du calcul.

Il y a tellement de profs qui font la promotion de la récursion comme étant quelque chose de merveilleux. J'ai jamais compris cette fascination pour un mécanisme qui monopolise des ressources système alors même qu'il est très rare d'avoir besoin d’accéder aux données intermédiaires, et même alors, la structure d'une pile n'est pas la plus adaptée pour envisager une exploitation ponctuelle efficace des données qu'elle contient.

[tomlev]

Il y a tellement de profs qui font la promotion de la récursion comme étant quelque chose de merveilleux. J'ai jamais compris cette fascination pour un mécanisme qui monopolise des ressources système alors même qu'il est très rare d'avoir besoin d’accéder aux données intermédiaires, et même alors, la structure d'une pile n'est pas la plus adaptée pour envisager une exploitation ponctuelle efficace des données qu'elle contient.

Bah c'est sûr qu'il faut pas l'utiliser partout, mais il y a un certain nombre de problèmes pour lesquels la récursion est l'approche la plus naturelle. On peut généralement réécrire le code sous forme itérative, mais c'est souvent beaucoup moins intuitif. Les langages fonctionnels (Haskell, OCaml, F#...) utilisent beaucoup la récursivité, et le mécanisme de récursion terminale fait qu'à l'exécution ça fonctionne effectivement comme une boucle (à condition que l'appel récursif soit la dernière instruction). D'ailleurs on peut "simuler" la récursion terminale en C#, j'avais écrit un article à ce sujet il y a quelque temps : http://www.thomaslevesque.fr/2011/08...erminale-en-c/

[Matthieu Vergne]

L'idée est sympa, mais le jeu a encore de longues heures d'améliorations devant lui. Je suis arrivé à l'exercice 1.10, avec un truc bien bizarre :
(x,y) -> résultat
(1,1) -> 1
(2,2) -> 2
(2,65) -> 23

Je me suis fait un petit Math.max(23, x) en Java, je lance la capture et... il affiche rien, ni résultat ni erreur. On fait comment ? {^_^}

Non, c'est sympa pour des adultes qui veulent jouer à programmer, mais c'est ni pour des enfants (qu'est-ce que ça veut dire une opération linéaire pour un gosse ?) ni pour ceux qui veulent apprendre à programmer (on arrive vite à des trucs tordus).