59Fermer61
PolluxLe 18/05/2008 à 18:52
PpHd (./59) :
Pollux (./58) :
Ben pour prendre l'exemple d'une interface haut-niveau vers may tu ne peux pas nier qu'on peut avoir envie de stocker l'entier (x+1)/2 dans une variable, puis après d'utiliser cette variable dans un calcul modulo p... Ca veut dire que si x avait une valeure concrète on aurait eu la vraie réponse, mais que s'il reste symbolique pouf ça dégénère en NAN, c'est pas le comportement qu'on veut (une TI qui est incapable d'intégrer une fonction la laisse intacte, elle ne remplace pas par NAN). C'est très courant en arithmétique de devoir faire ce genre de divisions, par exemple l'exposant du symbole de Legendre est (p-1)/2 ; tu peux me répondre que les exposants tu les calcules dans N, mais je te réponds que l'utilisateur peut vouloir les calculer dans phi(p) = p-1, et 2 n'est pas inversible modulo p-1 donc ça te ferait aussi un NAN*p + NAN.
En gros ta méthode consiste à peu de choses près à avoir un gros switch global "tout faire mod p" ou "ne rien faire mod p", mais c'est pas assez fin pour représenter tout ce qu'on veut faire, même si tu traites les exposants comme un cas spécial.

Oui.
Et ce que tu décris (et besoin) correspond plus à une fonction fonction 'rem' qui renvoie un reste qu'à une fonction modulo.
Ton interface de haut niveau aura je pense créé cette fonction rem la calculant.
Et je suis désolé, mais (x+1)/2 mod 2 doit donner NAN*x+NAN (qui est surement la réponse la plus compréhensible des CAS que je connaisse).
Et franchement, c'est à l'utilisateur de savoir ce qu'il fait. S'il calcule dans Z/pZ, faut pas s'étonner à avoir des NAN si on divise par p. S'il calcule dans les exposants, il ne calcule pas avec modulo. Avant de remplacer sa variable, il vérifie que c'est un entier. C'est évident. S'il veut quelque chose de plus souple, il écrit du code correct (et il a plein de moyens d'en faire). C'est pas comme si la future extension 'mod' ou si kernel_intmod étaient les seules façons de calculer un reste.
Je ne supporterai jamais le neu-neu proof. smile

C'est même pas une question de neuneu proof, c'est juste que ton truc est un gros switch global donc on ne peut pas faire tout ce qu'on veut. Pourquoi pas, hein, mais c'est quand même une limitation.
Pollux (./58) :
mod(4^(1/2),3) est transformé en mod(1^(1/2),3) = 1, je suppose ? Or évidemment si tu calcules la puissance avant de "simplifier" tu obtiens mod(2,3) = 2.

Sémantiquement non, car x^y avec y non entier est considéré comme une fonction classique (comme exp(y*ln(x)))

Donc 4^n n'est jamais simplifié en 1 ? :/