Informatique en cycle 3/4: découvrons Scratch (récapitulatif tenu à jour de mes essais page 8)

ben2510 a écrit:

ycombe a écrit:

ben2510 a écrit:

Spoiler:

Ta pièce jointe mérite une petite modification:


Juste pour discuter du critère d'arrêt avec les élèves

Chut ! :lol:
Il ne faut pas le dire trop vite
L'idée est plutôt de prendre n=2^a*3^b*5^c*17*23*p où p est premier et p>10000, histoire d'avoir le temps de comprendre pourquoi l'humain a déjà fini, alors que Scratch continue à compter :-)

Je précise que quand je donne cet algorithme à mes secondes (à la main, puis en Python, puis en TI-Basic mais là c'est eux qui traduisent), ils ont préalablement travaillé sur le crible d'Eratosthène, avec des remarques du type "quand on entoure p, le premier nombre composé qui sera éliminé sera p² puisque 2p, 3p, 4p, ....(p-1)p l'ont déjà été".

En troisième, je commence le cours d'arithmétique par la racine carrée entière. Et je montre la propriété suivante:

Si n = a×b, alors le plus petit des deux nombres a et b est inférieur ou égal à la racine carrée entière de n

En général j'ai des élèves qui après réflexion me disent que c'est évident.

Avec le corollaire suivant:

Si n n'est pas premier, alors il admet un diviseur premier inférieur ou égal à sa racine carrée entière.

Ensuite, ça me sert de critère d'arrêt pour le crible d'Erathostène, l'algorithme qui donne la liste des diviseurs d'un nombre et le test de primalité basique (ce dernier étant utilisé pour la décomposition en facteurs premiers).

Un algorithme intéressant à leur faire faire pour comprendre qu'on peut avoir le meilleur ordinateur du monde et le meilleur langage du monde, tant que l'algorithme n'est pas bon ça ne sert à rien, c'est celui du calcul des couples de nombres amiables jusqu'à un million. (Edit: les faire passer à Python ou Lisp avant. En Scratch ce n'est pas la peine, ça va être beaucoup trop long. Scratch est adapté pour des petits jeux, pas pour autre chose).

ycombe a écrit:
Un algorithme intéressant à leur faire faire pour comprendre qu'on peut avoir le meilleur ordinateur du monde et le meilleur langage du monde, tant que l'algorithme n'est pas bon ça ne sert à rien, c'est celui du calcul des couples de nombres amiables jusqu'à un million. (Edit: les faire passer à Python ou Lisp avant. En Scratch ce n'est pas la peine, ça va être beaucoup trop long. Scratch est adapté pour des petits jeux, pas pour autre chose).

Il a fallu un peu plus de 5 min de calcul à Scratch pour afficher les nombres parfaits et amiables jusqu'à 1000. Je n'imagine même pas le lui faire faire jusqu'à un million.


(Ou alors mon algorithme est franchement nul.)

Un autre élément qui éloigne Scratch de la programmation classique, ce sont les structures de contrôles. La répétition s'obtient classiquement de deux structures ou trois:

- la boucle "for" ou répétition inconditionnelle.
- la boucle "while" ou répétition conditionnelle.
- parfois une boucle "repeat … until"

Scratch 1.4 propose:
- une boucle «répéter indéfiniment»
- une boucle «répéter indéfiniment si … »
- une boucle «répéter jusqu'à …»
- une boucle «répéter n fois»

On peut se demander quelle est l'intérêt de la deuxième, il me semble qu'il suffit de glisser la première dans un test "si" pour obtenir le même effet.

La première s'obtient classiquement par la troisième en forçant de test à «vrai», par exemple avec 1=1 s'il n'y a pas de prédicat vrai/faux.

Quand à la dernière, «répéter n fois» est très loin du fonctionnement classique avec variable «répéter pour … variant de … à …» . LOGO propose une telle primitive, mais peu de langages vraiment utilisés en programmation en ont une (lisp en a une, bien entendu. Mais c'est lisp, il a un peu tout.)

Quelques secondes suffisent si on se restreint aux nombres parfaits pair:

Spoiler:

Je pense que ce genre d'algorithmes est assez loin de l'esprit du programme.

ycombe a écrit:

Le même en python:

Code:


#!/usr/bin/python

import sys
limit = eval(sys.argv[1])

parfaits = []
n = 2
t = 2**(n-1)
dmu = 2**n-1
    
while  t * dmu < limit:
    i=2
    premier=True

    while premier and (i*i<=dmu):
        if dmu % i == 0:
            premier = False
        i+=1
        
    if premier:
        parfaits.append(t*dmu)

    n+=1
    t = 2**(n-1)
    dmu = 2**n-1
    
print parfaits


C'est bien sûr beaucoup plus rapide en python qui ne met pas un dixième de seconde à afficher les 7 8 premiers nombres parfaits (contre 52 s à Scratch), le septième huitième étant validé en 15 millièmes de seconde. Il lui faut plus de 4 minutes pour le huitième neuvième…

Euh j'ai 17ms pour le 8e.
Par contre j'attends toujours le 9e !

Franchement, ça me semble parfaitement dans l'esprit du programme (de TS spé maths :lol: )

Temps en ms :
6 0.0
28 0.003000020980834961
496 0.0
8128 0.0010001659393310547
33550336 0.0009999275207519531
8589869056 0.002000093460083008
137438691328 0.0019998550415039062
2305843008139952128 0.07299995422363281

[EDIT] 2658455991569831744654692615953842176 65736.89600014687

ben2510 a écrit:Euh j'ai 17ms pour le 8e.
Par contre j'attends toujours le 9e !

Euh oui, pardon. Je ne sais plus compter jusqu'à 8.

Algorithme pour trouver la liste des diviseurs d'un nombre. Je le fais en troisième (à la main).

On teste les décompositions a×b en partant de a=1 et en augmentant a à chaque fois.
30 =
1×30
2×15
3×10
5×6

Le critère d'arrêt est que le premier nombre devienne supérieur à la racine carrée entière du nombre étudié, qui est 5 ici. On peut aussi s'arrêter lorsque les nombres s'inversent mais c'est moins efficace.

L'algorithme donne les diviseurs ordonnés en descendant puis en remontant.

La transcription dans Scratch peut être simple, en ajoutant à liste les deux diviseurs à chaque fois. Mais la liste va être désordonnée.

Question: comment faire dans scratch pour obtenir  une liste ordonnée ?

Ma solution:

http://www.scientificamerican.com/article/mann-why-global-warming-will-cross-a-dangerous-threshold-in-2036/

Avec des vrais morceaux de code MATLAB dedans, et une jolie équa diff qui va fissa se retrouver sous le nez de mes TS.
Voila une occasion pertinente de faire un peu de programmation (mais pas avec des collégiens).

ben2510 a écrit:http://www.scientificamerican.com/article/mann-why-global-warming-will-cross-a-dangerous-threshold-in-2036/

Avec des vrais morceaux de code MATLAB dedans, et une jolie équa diff qui va fissa se retrouver sous le nez de mes TS.
Voila une occasion pertinente de faire un peu de programmation (mais pas avec des collégiens).

Je croyais qu'il n'y avait plus d'équa diff au programme de TS.

Exact !
Corollaire : je fais du hors-programme.

"La notion d'équation différentielle est le pivot de la conception scientifique du monde"
Arnold.

Bon de mon coté j'attaque Scratch (pour me remettre dans le bain) aujourd'hui, je vous tiens au 220V

Je cherche des idées de truc simples à faire programmer en Scratch qui imposent une petite réflexion mathématique. (Certains sont peut-être compliqués).

L'armoire: deux murs avec un espace entre figurant une porte, une armoire plus large à faire pivoter en indiquant un angle. Plus on est proche de l'angle minimal, plus on marque de points.

Le créneau: piloter une voiture pour faire un créneau. Perte de points si on le fait à la parisienne (bing ça touche).

La flèche qui doit atteindre sa cible mais attention: il y a du vent et la gravitation (celui-là il est dans GCompris).

Le crocodile écossais: un crocodile d'un côté d'un rivière, une gazelle de l'autre côté. Trouver le meilleur angle selon lequel traverser la rivière pour attraper la gazelle. Si le temps mis est supérieur de plus de 10% à l'optimum, la gazelle se carapate.

La précision SNCF. Un train à une distance donnée de la gare. Indiquer la vitesse à laquelle il doit rouler pour y être à l'heure prévue. Perte de point suivant l'écart à l'optimum.

ycombe a écrit:Le crocodile écossais: un crocodile d'un côté d'un rivière, une gazelle de l'autre côté. Trouver le meilleur angle selon lequel traverser la rivière pour attraper la gazelle. Si le temps mis est supérieur de plus de 10% à l'optimum, la gazelle se carapate.

Une que Descartes adorerait (réfraction) :

Un sauveteur sur la plage.
Un nageur en train de se noyer, mais pas en face (c'est-à-dire que la droite passant par le sauveteur et le nageur n'est pas perpendiculaire à la ligne de séparation sable/eau, qu'on supposera rectiligne).

Sur le sable, le sauveteur va deux fois plus vite que dans l'eau.
Déterminer le trajet le plus rapide.

(Merci Feynman, évidemment).

JPhMM a écrit:

ycombe a écrit:Le crocodile écossais: un crocodile d'un côté d'un rivière, une gazelle de l'autre côté. Trouver le meilleur angle selon lequel traverser la rivière pour attraper la gazelle. Si le temps mis est supérieur de plus de 10% à l'optimum, la gazelle se carapate.

Une que Descartes adorerait (réfraction) :

Un sauveteur sur la plage.
Un nageur en train de se noyer, mais pas en face (c'est-à-dire que la droite passant par le sauveteur et le nageur n'est pas perpendiculaire à la ligne de séparation sable/eau).

Sur le sable, le sauveteur va deux fois plus vite que dans l'eau.
Déterminer le trajet le plus rapide.

Pédagogiquement parlant, ça le fait de mettre une photo de David et Pamela en maillots de bain rouge dans le jeu?

On croit que c'est Pythagore, et paf c'est Thalès.
http://dl.free.fr/sjCu4PFzD
http://dl.free.fr/t3Ah4iDXI

Bon, il se peut que l'aigrette (malgré ses changements de direction instantanés voire franchement pas dérivables   ) vole deux fois moins vite en montée qu'en descente.

ycombe a écrit:

JPhMM a écrit:

ycombe a écrit:Le crocodile écossais: un crocodile d'un côté d'un rivière, une gazelle de l'autre côté. Trouver le meilleur angle selon lequel traverser la rivière pour attraper la gazelle. Si le temps mis est supérieur de plus de 10% à l'optimum, la gazelle se carapate.

Une que Descartes adorerait (réfraction) :

Un sauveteur sur la plage.
Un nageur en train de se noyer, mais pas en face (c'est-à-dire que la droite passant par le sauveteur et le nageur n'est pas perpendiculaire à la ligne de séparation sable/eau).

Sur le sable, le sauveteur va deux fois plus vite que dans l'eau.
Déterminer le trajet le plus rapide.

Pédagogiquement parlant, ça le fait de mettre une photo de David et Pamela en maillots de bain rouge dans le jeu?

Ne pas le faire serait bien sûr une faute de goût impardonnable !  

ycombe a écrit:

JPhMM a écrit:

ycombe a écrit:Le crocodile écossais: un crocodile d'un côté d'un rivière, une gazelle de l'autre côté. Trouver le meilleur angle selon lequel traverser la rivière pour attraper la gazelle. Si le temps mis est supérieur de plus de 10% à l'optimum, la gazelle se carapate.

Une que Descartes adorerait (réfraction) :

Un sauveteur sur la plage.
Un nageur en train de se noyer, mais pas en face (c'est-à-dire que la droite passant par le sauveteur et le nageur n'est pas perpendiculaire à la ligne de séparation sable/eau).

Sur le sable, le sauveteur va deux fois plus vite que dans l'eau.
Déterminer le trajet le plus rapide.

Pédagogiquement parlant, ça le fait de mettre une photo de David et Pamela en maillots de bain rouge dans le jeu?

Oui.

C'est plus conforme à l'idée d'origine d'ailleurs.
http://www.lerepairedessciences.fr/seconde/univers/chap2/act2.1b%20-%20apparition%20spectres.pdf
(voir page 2)

La solution est donnée (p16) par Daniel Perrin  "la règle que l'on doit apprendre aux futurs maîtres-nageurs c'est
tout simplement de courir jusqu'à l'aplomb du nageur !"

Merci. pour le lien. Daniel Perrin est un de mes héros.

Il prend pour hypothèse que la nageur nage au cinquième de sa vitesse de course. Pour en faire un travail de programmation, on prendra une hypothèse plus irréaliste (mais qui oblige à faire le calcul, vraiment).

...
Avec le p'tit père Perrin,
Faut toujours faire un dessin !
...
(Une chanson composée par les capésiens qu'il formait à Paris XI)

Perrin + Lafforgue + Demailly = des programmes décents :-)

J'ai essayé pour ma part de programmer un algorithme des différences (pas le truc le plus compliqué du monde, a priori ...). Je précise que la version (offline) était en anglais. J'ai galéré avec la fonction "change y by 10" qui ne signifie pas "change y en 10" (donc "remplace y par 10"), mais "change y de 10" (donc " augmente y de 10"). Pour remplacer y par 10, il faut "set y to 10". Ycombe, tu dis à un moment qu'une fonction "remplacer ... " fonctionnait et pas l'autre : je pense que c'est un souci du même genre.

Déjà que je rame (j'ai fait un peu de programmation sur turbo pascal à la fac, mais c'était il y a 15 ans ... et je n'étais pas très à l'aise) ... si en plus les consignes ne sont pas claires ou mal traduites Je ne me vois pas du tout me lancer là dedans avec 30 gamins sur les 13 postes de la salle info. Heureusement qu'on va avoir 3 jours de formation, ouf, sauvés !

cube a écrit:J'ai essayé pour ma part de programmer un algorithme des différences (pas le truc le plus compliqué du monde, a priori ...). Je précise que la version (offline) était en anglais. J'ai galéré avec la fonction "change y by 10" qui ne signifie pas "change y en 10" (donc "remplace y par 10"), mais "change y de 10" (donc " augmente y de 10"). Pour remplacer y par 10, il faut "set y to 10". Ycombe, tu dis à un moment qu'une fonction "remplacer ... " fonctionnait et pas l'autre : je pense que c'est un souci du même genre.

Déjà que je rame (j'ai fait un peu de programmation sur turbo pascal à la fac, mais c'était il y a 15 ans ... et je n'étais pas très à l'aise) ... si en plus les consignes ne sont pas claires ou mal traduites Je ne me vois pas du tout me lancer là dedans avec 30 gamins sur les 13 postes de la salle info. Heureusement qu'on va avoir 3 jours de formation, ouf, sauvés !

Je confirme.

Pour avoir menus, blocs etc. en Français, c'est facile : tu cliques sur la petite mappemonde en haut à gauche !

Je réactualise un peu le fil vu que nos IPR ont officialisé l'utilisation de Scratch pour la partie programmation de 3° (pour le moment, je n'avais eu aucune confirmation officielle).

J'ai donc essayé un peu de voir ce qu'on peut faire... en essayant de mêler le moderne et le vintage.

C'est pas tout à fait fini mais déjà jouable : version 1.0

P.S. : ne soyez pas trop durs sur les critiques du gameplay/RP