Re: Bug in Mod (2.0.15)

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

[Ilya:]
> a)
> 
>     ? z=Mod(x,x^2+y^2)
>     %1 = Mod(x, x^2 + y^2)
>     ? u=Mod(z,x^2+y^2+t^2)
>     %2 = 0

It's a (debatable...) feature : modular objects (POLMOD/INTMOD)
of different modulus are adjusted to a common modulus first, here
gcd(x^2 + y^2, x^2 + y^2 + t^2) = 1, and all objects mod 1 are equal to 0...

In general, a POLMOD is an invalid argument for Mod (the documentation is too
vague here, it allows all "scalars". It shouldn't). It can be valid if the
modulus are compatible, but this will usually be a hazard, hence should be
disabled...

In fact one should review all generic functions (gadd, gmul, gdiv, gmul,
ggcd, gaffect and maybe one or two others), and specify precisely what is
allowed and what is not, then enforce it in the code. Right now the situation
is very messy and too permissive : these functions can create objects which
are "incorrect" (in the sense of producing a SEGV) for some other functions.

[ Bill wrote a nice random "program generator" a while ago that easily
crashed PARI by systematically checking "borderline" cases. The obvious
problems have been fixed, the general quirkiness remains ]

A "clean" solution would involve a rewrite of the type system, which is in
order anyway, but I'd rather postpone it until 2.1 is out.

[ If b) was supported, of course, that would be the correct thing to do. ]

> b) Additionally: why do not we allow quotients by ideals with several
>    generators, like making the above thing to live in
> 
>     Q[x,y]/(x^2+y^2,x^2+y^2+t^2)
> 
>    ?

That's a lot of work. I can put it in the TODO list [ along with decent
support for multivariate objects, which would be required anyway... ].

> c) If $\fl$ is equal to $1$, the modulus of the created result is put
>    on the heap and not on the stack, and hence becomes a permanent
>    copy which cannot be erased later by garbage collecting (see
>    \secref{se:garbage}). In particular, care should be taken to avoid
>    creating too many such objects, since the heap is very small
>    (typically a few thousand objects at most).
> 
>    This is an excerpt from Mod() documentation.  Definitely with
>    hardware of today we can create billions of objects on the stack, right?

Well, not litteraly billions (unless you're willing to let the machine swap
to hell and back...), but a bit more than "a few thousand at most". I have
already cut out that part (in 2.0.18 I think), but it should be modified
further:

    If  flag  is  equal to 1,  the modulus of the created result is put on the
 heap and not on the stack, and hence becomes a permanent copy which cannot be
 erased later by garbage collecting (see Section (??)). Functions will operate
 faster  on  such objects and memory consumption will be lower.   On the other
 hand, care should be taken to avoid creating too many such objects.

    Under GP,  the same effect can be obtained by assigning the object to a GP
 variable   (the  value of which is a permanent object for the duration of the
 relevant  library  function  call,   and is treated as such).   This value is
 subject  to  garbage  collection,   since  it  will be deleted when the value
 changes. This is preferable and the above flag is only retained for
 compatibility reasons (it can still be useful in library mode).

   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/