Erreur dans du codage

[slejoly]

J'ai encore des soucis avec les fonctions de codages et notamment le symbole : \
qui correspond au code ascii 92,
et : "
qui correspond au code ascii 34,
je vous montre ce que j'ai fait :

code:= (c)->{
return(asc(c)-32);
};

decode:= (k)->{
return(char(k+32));
};



affine:= (message,a,b)->
{ local s,j,messcode;
s:=size(message);
messcode:="";
for (j:=0;j<s;j:=j+1) {
messcode:=messcode+decode(irem(a*code(message[j])+b,96));
};
return(messcode);
};



voilà pour les programmes (inspirés de la doc !)

Je prends :
affine("bonjour",85,2)

ce qui me donne :
L}(T};\

puis reciproquement :

affine("L}(T};\",61,70)

et là : Syntax compatibility mode xcas Parse error line 2 a

alors en cherchant caractère par caractère :

char(irem(61*(asc("\")-32)+70,96)+32)

donne : Syntax compatibility mode xcas Parse error line 3 a

et pour confirmation : asc("\") donne :
Syntax compatibility mode xcas Parse error line 2 a


J'ai la même erreur avec le symbole " : asc(""") Syntax compatibility mode xcas Parse error line 2 a

le problème c'est que cela corespond à l'espace :
affine(" ",85,2) donne "
et l'espace me serait bien utile pour coder quelques messages simples.

Voilà je ne sais pas comment m'en sortir à part limiter le nombre de caractères à utiliser ce qui est un peu dommage.

Stéphane Lejoly.

PS : je n'ai plus le .xcasrc de l'autre jour.
Est ce que le problème avec ans() est corrigé ?

[parisse]

\ est en effet un caractere d'echappement, il faut taper \\ pour obtenir un \ dans une chaine. Et justement c'est \ qui sert a taper un " (on peut aussi taper "" pour avoir un "), par exemple
"1""b"
"1\"b"

[slejoly]

1) Oui cela marche cela veut donc dire que que si je reçois comme message :
L}(T};\
il faut que manuellement je rajoute un deuxième \
pour le décoder (même chose pour le ").

2) Y a t-il d'autres symboles qui peuvent poser problème ?

3) asc("\"") ne marche pas (par contre asc("""") si ).

Stéphane Lejoly.

[parisse]

oups, il y a en effet un bug du meme genre que le precedent pour reconnaitre \"
sinon, si votre message contient \ vous devrez en effet le doubler pour le decoder, sauf bien sur si vous codez et decodez dans la meme session, auquel cas vous pouvez stocker dans une variable.
je vais essayer de mettre a jour la version mac la semaine prochaine (mardi si tout va bien)

[slejoly]

1) J'ai eu un autre petit problème, toujours en m'amusant avec les exemples de la doc : (la fonction "bonpara" dans la partie codage)
cela vient de : bezout_entier(85,96) qui me renvoie : bezout_entier(85,96) étonnant !
Alors qu'en changeant par iegcd(85,96) (qui donne bien [35 31 1]) bonpara fonctionne.

2) Est que le pb avec ans() sera lui aussi corrigé pour la prochaine mise à jour ?

Merci pour toutes vos réponses.

Stéphane Lejoly

[parisse]

peut-etre que la traduction bezout_entier ne fonctionne pas encore dans la version mac.
sinon, oui le probleme de ans() sera corrige dans la prochaine mise a jour mac.

[parisse]

la version os x a ete mise a jour!

[slejoly]

Merci pour cette nouvelle mise à jour.

Cependant j'ai un autre problème.
Xcas "quitte inopinément" quand je fais les calculs suivants pour RSA (à noter que je me suis installé, aujourd'hui, la version Windows au lycée et que je n'ai pas eu ces problèmes) :

p:=nextprime(123456789987654321123456789987654321)
123456789987654321123456789987654391

q:=nextprime(987654321123456789987654321123456789)
987654321123456789987654321123456817

feu:=(p-1)*(q-1)
121932632103337905905959457319311151927602505513793623143575680297822240

f:=nextprime(999999999999999999999999999999)
1000000000000000000000000000057

gcd(f,feu)
1

d:=inv(f%feu) et ça plante ou alors:
infinity (et ça plante)


En essayant d:=iegcd(f,feu) ça plante encore.

Par contre en reduisant la taille de p et q cela marche mais ce n'est pas le but !

Stéphane Lejoly.

PS : intéressant le dossier terminale S.

Je vais vous envoyer ma session et le rapport du "crash" des fois que cela vous donne plus d'indications.

[parisse]

ca a l'air d'etre un pb sur mac uniquement alors, sur mon linux ca marche normalement, il faudra que je me reprocure le mac pour tester tout ca...

[parisse]

apres 3 heures de debogage, je declare forfait pour le moment. C'est un probleme de memoire, qui se produit semble-t-il lorsqu'on manipule des entiers de taille superieure a 128 bits, et qui n'affecte que le mac. Il est possible que ce soit un probleme lie a la librairie GMP, en faisant les tests de regression de GMP sur Mac, j'ai 3 erreurs reportees dans les fonctions d'export/import qui sont utilisees pour lire et afficher les grands entiers, je vais probablement envoyer un bug report aux developpeurs de GMP pour en savoir plus sur ce point.

[slejoly]

Tenez moi au courant (en espérant que cela marche bientôt).
Stéphane Lejoly.

[parisse]

apres encore une matinee de tests, j'ai trouve une configuration qui semble plus stable, en desactivant le support de PARI-GP, j'ai mis a jour xcas os x sur le site. Dites-moi si ca fonctionne correctement chez vous!
Si c'est bien PARI-GP le probleme, il faudra sans doute que je recompile une version de pari ou/et que je regarde les pb de pari sur mac os x.

[slejoly]

J'ai repris les calculs du cours G Connan pour RSA et là, plus de problème :

p:=nextprime(4578465795689568795678456845684567879065780) ;

q:=nextprime(907689576834535362345135535467569745645734576) ;

n:=p*q ;

phi_n:=(p-1)*(q-1) ;

f:=nextprime(8543467856572465856758634567896897) ;

igcd(f,phi_n) ;

ET C'ETAIT LA QUE TOUT PLANTAIT : d:= inv(f%phi_n) ; plus aucun soucis ....

Donc c'est bon pour moi, j'aurais l'air moins bête qu'avec RSA et des p=17 , q=23 !!!

Merci.

P.S. : en quoi joue le fait de désactiver PARI-GP sur cette version que je viens d'installer (y-a-t-il des trucs qui ne marcheront pas) ?

[parisse]

oui, il manquera des fonctionnalites, mais ca ne devrait pas gener au niveau lycee. Ce que vous verrez principalement, c'est que la factorisation de grands nombres est beaucoup moins rapide (il manquera aussi toutes les fonctions exportees par la commande pari()). Ceci dit je ne desespere pas de relinker avec PARI sur mac quand j'aurai un peu de temps a y consacrer...

[slejoly]

Je suis en train de préparer un autre exercice avec le codage affine mais où je me restreins aux 26 lettres majuscules et je rajoute l'espace
je me suis servi des exemples de la doc que j'ai modifié comme cela :

code26:= (c)->{
return(asc(c)-65);
};

decode26:= (k)->{
return(char(k+65));
};

affine26:= (message,a,b)->
{ local s,j,messcode;
s:=size(message);
messcode:="";
for (j:=0;j<s;j:=j+1) {
if (message[j]==" " ) messcode:=messcode+" ";
messcode:=messcode+decode26(irem(a*code26(message[j])+b,26));
};
return(messcode);
};


Dans affine26 il y juste la ligne suivante en plus pour garder les espaces :

if (message[j]==" " ) messcode:=messcode+" ";

et si je rentre : affine26("A A",11,4) (A espace A donc 3 caractères)

j'obtiens : "E ,E" E espace , E 4 caractères bizarre.

Et puis avec la fonction de décodage :

affine26("E ,E",19,2)

cela donne :
"A @:A" au lieu du "A A"

Je ne comprends pas.