Forum TI-Planet.org

critor a écrit:Après non, je ne me sens pas tenu en mathématiques de respecter un mauvais choix opéré dans la code ASCII de 1967 aux débuts de l'informatique.
Un choix valable dans le contexte de l'époque (cible une élite professionnelle et non la masse scolaire, précision limitée des écrans et imprimantes de l'époque qui pouvaient faire confondre le signe de multiplication et la lettre x) mais hors sujet dans le contexte d'aujourd'hui.

L'informatique est un outil qui doit s'adapter aux mathématiques, et non l'inverse.
Sinon, nous écririons tous en ligne sur nos copies plutôt qu'en 2D.

Je ne parle pas d'affichage, mais d'echange de donnees. Un calcul a vocation a etre sauvegarde et echange, et dans ce cadre l'utilisation du signe * est le seul standard interoperable, que ce soit en ligne de commande ou dans un programme.
Dire que les eleves sont incapables de s'adapter a l'utilisation du signe * sur une calculatrice (ou un PC) parce qu'on note la multiplication au tableau autrement (et pas de maniere uniforme d'ailleurs) et croire par ailleurs qu'ils vont accepter sans sourciller la meme notation dans un programme, ou la notation a=a+1 pour l'affectation dans certains langages de programmation me parait bien etrange.
D'autre part, je pense qu'utiliser l'entree en 2d sans montrer egalement comment saisir une expression en 1d est dommage. Saisir une ligne de commande syntaxiquement correcte peut certainement aider d'une part a comprendre les priorites entre operateurs et d'autre part a ecrire des programmes. Pour editer certaines expressions, c'est bien plus simple en 1d qu'en 2d. Sans compter que c'est tres utile pour qui poursuit des etudes de sciences. Comme tout outil, il faut faire bon usage de la saisie en 2d. Avoir les 2 options comme sur la Prime c'est tres utile.

Peut être que le choix concerne uniquement la représentation visuelle du caractère *, cela dit, et que niveau code ascii ça restera la même chose - une customization de la tête de la police sur ce caractère, quoi. Mais bon il faudrait leur demander.

l'avantage avec les calculatrices rpn c'était que l'opérateur n'apparaissait pas

Pourquoi ce n'est plus le cas ?

Pour les calculs je pense que si , par contre pour les programmes c'était aussi la petite étoile si mes souvenirs sont bons

Hello,
Unfortunately the formal mathematical language to be used in computing (1950, …), had to adapt to the ASCII encoding, for example SQ as a synonym of √, -> as synonymous with →
, > = as a synonym of ≥, <= as a synonym of ≤, it should be noted that the symbol >, < ( ASCII # 60 AND 62, it is not even the largest or smallest symbol, it is an angle bracket on the right, and left),
Fortunately Xcas can interpret some operators either in the middle of the operands (infix operator), as a functional prefix, as a functional symbolic prefix, postfix.
This feature allows entry according to several styles, but to write documents using calculators and mathematical packages, they must have as an option the symbols closest to the formal mathematical language that are available in UNICODE

About Xcas mathematical package, if the user does not want to enter real mathematical symbols, he can use the functional version of the operator, for example

Case 1: POSTFIX OPERATOR, (that is, the form: operand operator )
a! (postfix operator)
5! [↵] returns 120

Case 2: PREFIX FUNCTIONAL OPERATOR, (that is, the form: name_operator( operand(s ))
factorial(a)
factorial(5) [↵] returns 120
sum(1/n^2,n,1,17) [↵] returns 238357395880861/150117385017600
root(4) [↵] returns 2
not(true) [↵] returns false

Case 3: SYMBOLIC PREFIX FUNCTIONAL OPERATOR, (that is, the form: operator_symbol( operand(s ))
Σ(1/n^2,n,1,17) returns 238357395880861/150117385017600
√(4) [↵] returns 2
!(true) [↵] returns false

CASE 4: digraph infix operator (that is, two continuous symbols)
a <= b (<= as digraph infix operator), a ≤ b (≤ as real infix operator)
a >= b (>= as digraph infix operator), a ≥ b (≥ as real infix operator)
a != b (!= as digraph infix operator), a ≠ b (≠ as real infix operator)

"A" <= "a" [↵] returns true
"A" ≤ "a" [↵] returns true
"A" != "a" [↵] returns true
"A" ≠ "a" [↵] returns true

Unfortunately Xcas still does not support exofix operators (that is, the operand is in the middle and the operator symbol is on the outside)

ceil(a) (ceil as functional operator), ⌈a⌉ (ceil as exofix operator)
floor(a) (floor as functional operator), ⌊a⌋ as (floor as exofix operator)
abs(a) (floor as functional operator), |a| (abs as exofix operator)

Now, in the formal mathematical language the symbol of multiplication is an intermediate point (·) or the symbol (+) rotated 45 ° (× ASCII # 215), both (·) and (×) it is only written to give clarity in a definition, but not in everyday use. Although the symbol (×) should be better used best for the Cartesian product
To give taste to several input styles, calculators and mathematical packages have to allow the interpretation of asterism (*), as well as the intermediate point (·) as multiplication symbols

84/6·x + 84/12·x + 84/7·x + 5·84 + 84/2·x + 4·84 = 84·x
84/6*x + 84/12*x + 84/7*x + 5*84 + 84/2*x + 4*84 = 84*x

But they have to show by default only the intermediate point in the output (·), since it occupies less horizontal space and the mathematical expression is more readable
The survey should also ask about the use of the standard symbol ÷ as a division operator as input

84÷6·x + 84÷12·x + 84÷7·x + 5·84 + 84÷2·x + 4·84 = 84·x

En ce qui concerne l'encodage en lui-même d'un caractère qui n'est pas *, j'ai pu demander à Romain, voici sa réponse : "probablement un caractère différent, vu que de toute façon on aura besoin de l'étoile dans Python". Donc ce ne serait pas dans ce cas une simple modification visuelle du caractère ascii *. En effet, en Python il serait étrange de ne plus pouvoir avoir * mais autre chose à la place, sans pouvoir y faire quoi que ce soit

Je ne vois pas en quoi afficher * en Python empeche d'afficher un autre signe dans l'affichage 2d d'une expression. L'editeur 2d a forcement un code specifique pour afficher les sommes et les produits, il n'a pas besoin de faire afficher le caractere * comme dans un terminal.

Oui, c’est ce qui a été dit.
Mais autant les autres caractères se collent (autant que possible) à de l’ascii, la si ce n’est pas * ça sera un autre custom, et python gardera bien sûr son * visuellement (et ascii).
Rien de bien surprenant, juste une confirmation

Bon, c'est pas tres clair de quoi on parle. Ce qui me semble essentiel pour l'interoperabilite, c'est que l'encodage d'une ligne de commande utilise * pour la multiplication. Apres si on est dans un systeme boite noire ou les chaines de caracteres representant une ligne de commande (i.e. la saisie en 1d) ne sont pas accessibles a l'utilisateur, il n'y a pas d'interoperabilite. Mais le probleme apparaitra si on veut ensuite '"ouvrir", par exemple permettre de copier/coller une expression depuis ou vers l'emulateur Numworks.
Bien sur on peut imaginer un lexer qui accepte plusieurs signes de multiplication, sauf que avec de l'encodage UTF8 il faut rajouter du code ad hoc dans le lexer pour reconnaitre le signe de multiplication special et ajouter un espace apres, faute de quoi on ne pourra pas utiliser des noms de variables multi-caracteres UTF8.