Re: Bug in Mod (2.0.15)

[Karim BELABAS <Karim.Belabas@math.u-psud.fr>]

[I wrote:]
> (13:01) gp > u = Mod(z,x^2+y^2+t^2)
> %6 = Mod(Mod(x, x^2 + y^2), x^2 + (y^2 + t^2))
>
> which is an incorrect object... Mod() currently only checks its second
> argument, leaving the user responsible for the other one. This follows the
> "PARI philosophy" [ try to make sense of most input, and let the user shoot
> himself in the foot if she wishes ]. Again, this should probably be revised
> (generic functions are far too permissive in my opinion).

Since I received a number of worried private emails related to the subject
above, let me be a little more precise : I don't intend to change that
"philosophy", since I believe it's one of the main reasons people use PARI
nowadays (together with free availability and, to a lesser extent, library
programming).

The object above is "incorrect" in the sense that it can completely crash a
session if fed to the wrong function, and not in the sense that it will
yield a "wrong" result (or even a weird error message). Most functions will
correctly detect that something is wrong, but some will not. The main point
is that there can't be a systematic way of checking things (for a developer)
if they have not been specified beforhand.

It's perfectly OK for the ordinary user to discover what a function will do
with a given object by trial and error, and I don't plan to enforce absolute
safety by preventing dangerous objects. But, as a developer, I feel
unconfortable to have to do the same [ I actually don't: I make educated
guesses after glancing at the code, and sometimes I'm wrong ]. One thing is
to know what the precise problem is and to disregard it; being bitten
unexpectedly after pressing the wrong key and losing the whole session is
another.

To make it short: I'd strive for better internal consistency, without
changing a thing externally (except possibly allowing even more inputs to
make sense, but that's not my current priority).

[Ilya:]
> My idea what that *allowing* such objects would allow quotients by
> non-principal ideals without a lot of reworking.  Since I know no
> details of this part of the core, this estimate may be wrong.

One problem is that, as the current type system and type checking procedures
go, you would have to systematically go through most library functions to
make sure they behave properly and don't make undue assumptions of the kind:
if I lift a POLMOD, I get a POL [ which, even in the current state of
affairs, is not valid; although a few functions still relied on it as late as
2.0.16. And maybe some still do ].

Another deeper problem is that, in the above example, PARI implicitly works
in Q(y,t)[x], and in that ring every ideal will be principal... Changing that
view would change the way a number of functions behave [ e.g currently we
have denominator(x/y) = 1, not y ], and more importantly would require that
steps be taken to allow users to specify a particular unlerlying ring for a
given operation. I don't see a way to do it consistently without a lot of
work [ and without complicating the interface, since the current default is
not the "natural" ].

Cheers,

  Karim.
__
Karim Belabas                    email: Karim.Belabas@math.u-psud.fr
Dep. de Mathematiques, Bat. 425
Universite Paris-Sud             Tel: (00 33) 1 69 15 57 48
F-91405 Orsay (France)           Fax: (00 33) 1 69 15 60 19
--
PARI/GP Home Page: http://www.parigp-home.de/