Forum TI-Planet.org

parisse a écrit:C'est sur que si on peut faire ça, ce sera d'autant plus transparent pour l'utilisateur, mais est-ce que ça ne va pas poser des problèmes sur les modèles non CAS?

Woops, bien vu... L'assignation d'expression avec des symboles va poser problème, effectivement.. Mais bon, ca ne plantera rien, la variable restera inchangée, c'est tout ^^
On peut cependant avertir les utilisateurs de non-CAS que la feature en question sera pas aussi bonne que sur CAS... (ne marchera qu'avec des trucs numériques, je pense...)

parisse a écrit:Sinon la commande VARS() dans giac renvoie la liste des variables affectées, ensuite il suffit de faire eval(v,1) pour avoir la valeur de tous les éléments v de VARS().

Humm j'irai faire un tour du côté de cette fonction et voir comment on peut faire interpréter la sortie de façon à l'exploiter comme on veut...

Merci

S'il y a un mécanisme de quote utilisable sur les nspire (du genre a:='b+1'), il faut l'utiliser, et ça devrait alors marcher sur les nspire non CAS (je pense que les erreurs sur non-CAS sont seulement déclenchées à l'évaluation d'une variable non affectée). Sinon, si on peut tester le type de machine en lua, il vaut sans doute mieux ne le faire que sur les machines CAS, sur les autres ça ferait sans doute trop d'erreurs.
Par contre, ce qui serait intéressant c'est de pouvoir sauvegarder le contexte d'une session khicas (contenu des variables et modes), il y a des fonctions pour ça dans giac, mais pour l'instant j'ai désactivé les échanges fichiers dans giac sur nspire, car fstream ne marche pas.

Je comprends mieux votre thèse, maintenant, parisse. Cependant, je pense justement que le gain à utiliser un moteur de calcul pour aller plus vite n'a d'effet réel qu'à partir d'un certain niveau, évidemment non présent au Bac. Comme vous êtes professeur d'université, je ne sais de quel niveau vous parlez. Malgré le gain de temps que vous indiquez (presque inexistant au lycée, surtout pour une équation du second degré qui se résout plus vite à la main), l'existence de la calculatrice et qui plus est à moteur de calcul formel n'a en réalité que pour conséquence d'approfondir le manque d'apprentissage de la part des élèves. C'est ce que l'on voit parfaitement d'après ce que les membres de passage viennent demander ici : simplement à avoir leur Bac en bourrant leur calculatrice. D'où le fait que je pense que l'examen doit vérifier la maîtrise des calculs.

De plus, même à un niveau plus élevé, avoir fait de nombreux calculs est extrêmement utile par la suite, lorsque l'on fait des calculs trop complexes pour être faits sur machine, avoir déjà acquis une certaine pratique permet d'être plus rapide et de faire moins d'erreurs.

Mais j'insiste, même si c'est "la réaction" que vous qualifiez (et à tord), le propos n'a pas lieu d'être.

parisse a écrit:S'il y a un mécanisme de quote utilisable sur les nspire (du genre a:='b+1'), il faut l'utiliser, et ça devrait alors marcher sur les nspire non CAS (je pense que les erreurs sur non-CAS sont seulement déclenchées à l'évaluation d'une variable non affectée).

Oui, mais l'intérêt serait limité aussi - côté TI, on ne pourrait pas en faire grand chose, en fait. Mais ça pourrait être utilisé par la suite pour des fonctionnalités de state save/restore que tu as mentionné après...

parisse a écrit:Sinon, si on peut tester le type de machine en lua, il vaut sans doute mieux ne le faire que sur les machines CAS, sur les autres ça ferait sans doute trop d'erreurs.

On peut savoir ça en Lua, oui. (un rapide appel à math.eval sur un calcul symbolique...)
Edit : voila => isCAS = not not math.evalStr('""+""') (joli, hein )

parisse a écrit:Par contre, ce qui serait intéressant c'est de pouvoir sauvegarder le contexte d'une session khicas (contenu des variables et modes), il y a des fonctions pour ça dans giac, mais pour l'instant j'ai désactivé les échanges fichiers dans giac sur nspire, car fstream ne marche pas.

Oui.
Avec une synchronisation qui marche bien, c'est faisable.
Mais il y a autre chose d'utilisable, peut-être : sauver l'état de giac en interne (côté c++) et produire un hash (ou sérialiser l'état, bref, n'importe quoi du moment que c'est réversible), et le donner au Lua via une fonction luagiac.getState par exemple. Ensuite, l'API Nspire-Lua dispose de 2 événements : on.save() et on.restore(data) (cf. wiki inspired-lua) qui peuvent être utilisée sans soucis pour communiquer à giac l'état sauvé... Du genre :

Code: Tout sélectionner

function on.save()
    return { luagiac.getState() }
end

function on.restore(data)
    luagiac.setState(data[1])
end

mdr1 a écrit:Je comprends mieux votre thèse, maintenant, parisse. Cependant, je pense justement que le gain à utiliser un moteur de calcul pour aller plus vite n'a d'effet réel qu'à partir d'un certain niveau, évidemment non présent au Bac. Comme vous êtes professeur d'université, je ne sais de quel niveau vous parlez.

Il ne s'agit pas seulement de gagner du temps, il s'agit de rendre les calculs accessibles, de permettre la vérification (qui n'est pas assez enseignée à mon avis) et la conjecture. Quant au niveau auquel j'enseigne, ça commence en L1 ST et ça va jusqu'en prépa agreg. Comme vous vous en doutez, en L1, nous avons la continuité du bac, avec des élèves qui ne viennent pas tous de S déjà, et qui ont rarement choisi cette orientation, ce ne sont pas des élèves de prépa! Autant dire qu'ils sont souvent très mal à l'aise dès qu'il faut faire un calcul. Faut-il pour autant leur dire résoud d'abord ton équation du 2nd degré (je caricature)? A mon avis non (je précise que cet avis n'est pas partagé par la grande majorité de mes collègues). D'autant plus si ce sont des étudiants dont la majeure n'est pas les maths, plutot que de les en dégoûter, mieux vaut leur apprendre à se servir d'outils qu'ils auront à leur disposition plus tard.

D'où le fait que je pense que l'examen doit vérifier la maîtrise des calculs.

Je ne m'oppose pas non plus à ce que une partie d'un examen vérifie la maitrise des calculs ou l'apprentissage de résultats, mais ça doit se limiter à une partie, l'autre partie faisant usage (intelligent) des outils de calcul.

Mais j'insiste, même si c'est "la réaction" que vous qualifiez (et à tord), le propos n'a pas lieu d'être.

Je pense le contraire. Je le redis, ce n'est absolument pas une attaque contre vous personnellement, c'est la façon dont je ressens l'attitude de refus systématique des outils de calcul évolués, attitude partagée par une grande majorité de mes collègues à la fac et certainement aussi par une partie des collègues du secondaire : certains n'ont tout simplement pas envie de remettre en cause leurs pratiques, d'autres trouvent là un moyen commode de ne pas apprendre à se servir des outils de calcul, d'autres sont certainement sincèrement convaincus après avoir essayé (peut-être pas de la meilleure façon à mon idée).
Peut-être que j'ai tord, simplement c'est ma conviction, et c'est pour cela que j'ai consacré maintenant plus de 14 ans à développer Xcas.

Mise a jour de l'interface, la touche menu permet de saisir quelques commandes classees par theme.

parisse a écrit:Mise a jour de l'interface, la touche menu permet de saisir quelques commandes classees par theme.

Pas mal du tout - une remarque cependant : pour éviter les erreurs de saisies inopinées dans l'historique (au lieu de l'input), ce code serait mieux :

Code: Tout sélectionner

function menustring( str )
    if fctEditor then fctEditor:addString( str ) end
end

Ok, je change ca. Je vais aussi enlever le passage en mode geogebra, il semble que les matrices et vecteurs sont bien geres maintenant, consequence les indices commencent a 0 dans les tableaux si on utilise l[n], il faudra utiliser l[[n]] pour commencer a 1 (on peut aussi utiliser l(n) en lecture).

Quelqu'un pourrait-il copier les caracteres speciaux pour l'exponentielle et le i imaginaire des nspire, ca me permettrait de les reconnaitre dans le parser de giac.
Il faudrait aussi traduire les fonctions reciproques trigo en asin/acos/atan.

Tu peux utiliser ord("i") (==61487) sur l'ému (si j'ai bien compris ce que tu cherches à faire).
TI utilise une des plages à usage privé de l'unicode pour ses caractères.