Re: sets of t_POLMOD

[Bill Allombert <Bill.Allombert@math.u-bordeaux.fr>]

On Thu, Feb 22, 2018 at 10:25:50AM -0500, Max Alekseyev wrote:
> Dear Karim,
> 
> Now I understand the source of this behavior, but I confused about how
> to cope with it.
> Should I always envelope any operations on t_POLMOD with simplify(),
> or what would be a correct approach here?

I would suggest to avoid creating t_POLMOD which lift to something
which is not a t_POL. You can use multiplication by x^0 for that.

Basically there are two different issues (your case is the second one).

1) objects that are normally t_POLMOD or t_POL, but you know from
mathematic that they are actually scalar. Then you can use simplify to
recover the scalar:

? z=Mod(2*x+3,x^2-2);type(simplify(lift(z*conj(z))))
%6 = "t_INT"
? z=Mod(2*x+3,x^2-2);type(lift(z*conj(z)))
%7 = "t_POL"

2) objects that are scalar but you want them to be handled as t_POL for
the purpose of structural comparison (===, cmp, Set, Map).
You can multiply them by x^0 (for the correct variable x) to make sure
they are t_POL:

? type(lift(Mod(1,x^2+1)))
%9 = "t_INT"
? type(lift(Mod(x^0,x^2+1)))
%10 = "t_POL"
? cmp(Mod(1,x^2+1),Mod(x^0,x^2+1))
%11 = -1
? Mod(1,x^2+1)===Mod(x^0,x^2+1)
%12 = 0

You might think you could do the converse and use simplify everywhere
instead. This would probably work, however basic GP semantic is to 
keep degree-0 polynomial as polynomial so that the variable name is
preserved. So if you start with t_POL-only objects, you can expect to
stay with t_POL-only and not need to multiply by x^0.

(Why do we even allow t_POLMOD with .pol component not being a t_POL is
something I do not know)

Cheers,
Bill.