Graaaaaaah ! Déjà qu'elle y connait rien en info, maintenant elle se mêle de programmation... Snif.
Déjà on programme avec Maple. Pour ceux qui connaissent pas, Maple c'est un formidable outil de calcul formel, associé à un piteux langage de programmation. Toutes sortes d'instructions non standard, une gestion des boucles... pathétique, et une syntaxe générale qui me rappelle le pascal. (vous savez, ce truc qu'on utilisait il ya longtemps)
Pour un soft qui sort régulièrement avec des versions de plus en plus performantes, c'est déprimant.

Bon, ça c'est l'intro.

La nouvelle marotte de PG, c'est de dire qu'il ne faut pas se servir des fonctions natives de Maple. (en gros de se priver de son seul intérêt)
Mais le pire, c'est le pourquoi de cette étrange décision.
"C'est plus rapide de recoder les fonctions, le programme sera plus rapide" (sic!)
Donc, pour résumer, voilà le fonctionnement de Maple.
Il parse le code pour repérer les erreurs.
Il l'interprète, le compile et enfin l'exécute.
Par quel MIRACLE, utiliser une fonction native précompilée et over optimisée serait-il plus lent que de
faire interpréter puis compiler puis utiliser une fonction. Ca implique que le temps d'interprétation et de compilation soit négatif. Problème.

Deuxièmement, sur un plan moins technique, je voulais parler du comportement général du programmeur.
Un comportement bien (que je m'efforce de respecter) consiste à aérer son code, indenter, éviter les astuces™ foireuses de programmation, de faire des bouts de code réutilisables, mettre des noms de variables explicites, bien sûr à commenter, bref respecter le lecteur éventuel.

Le programmeur qui code pour lui pourrait à la limite ne pas suivre ces conventions (bien que je ne lui conseille pas), mais quand on est professeur, ça devient indispensable.
Surtout que la majorité des élèves ne connaissait pas la programmation avant le premier cours de cette année.

En gros, voilà ce qu'il ne faut pas faire (en règle générale, mais surtout lorsque c'est un "corrigé") :

Racine_carré :=proc(a,e)
     local p,c,q,em,b,n,f,u;
     p:=0; c:=1; while c<a do p:=p+1; u=2*u od;
     u:=1; q:=0; while 2*q<p-2 do q:=q+1; c=2*c od;
     em:=e/(3*u); b:=1/5;f:=proc(x,a)  ;(x*x+a)/(2*x) end;
     print(p,q,'valeurs_initiales_choisies u0_et_u1_sont', u, 'et', evalf(f(u,a)));
     u:=f(u,a); n:=1;while b>em do n:=n+1;b:=b*b;u:=f(u,a) od;
     print('valeur_approchée de_racine_de_',a,'est', evalf(u));
     print('valeur_obtenue_en_',n,'_iterations');
     print('valeur_approchée_donnée_par_maple', evalf(sqrt(a)));
     end;
     
   
  

Voilà le code à la PG, featuring plusieurs instructions par ligne, la proc sous définie en plein milieu d'autres
instructions, aucune indentation, aucun commentaire.
Comment donner envie aux gens de programmer. Bravo. Clap Clap.

Racine_carré :=proc(a,e)
  local p,c,q,em,b,n,f,u;
  p:=0;
  c:=1;
  while c<a do# On approxime rapidement le premier terme de la suite par des puissances de 2
   p:=p+1; c=2*c
  od;
  u:=1;
  q:=0;
  while 2*q<p-2 do# On calcule u0=2^E(p/2)
   q:=q+1; c=2*c
  od;
  em:=e/(3*u);#Calcul visant à obtenir la précision de l'approximation
  b:=1/5;
  f:=proc(x,a) # Fonction dépendant d'un paramètre
   (x*x+a)/(2*x);
  end;
  print(p,q,'valeurs_initiales_choisies u0_et_u1_sont', u, 'et', evalf(f(u,a)));
  u:=f(u,a);
  n:=1;
  while b>em do#Tant que la précision voulue n'a pas été atteinte
   n:=n+1;b:=b*b;u:=f(u,a)
  od;
  print('valeur_approchée de_racine_de_',a,'est', evalf(u));
  print('valeur_obtenue_en_',n,'_iterations');
  print('valeur_approchée_donnée_par_maple', evalf(sqrt(a)));
 end; 

Voilà un code un peu plus clair
Enfin bon c'est pas à moi de faire son boulot, mais ya des fois ça m'énerve