Re: polresultant disagrees with sage, maxima and magma

[Charles Boyd <csboyd07@gmail.com>]

Should it perhaps give a warning or throw an error that the resultant is not being taken w.r.t. an indeterminate from the base field? Inform the user in some way that it is computing something different from what you probably want it to be computing?

On Sep 20, 2012 9:20 AM, "John Cremona" <john.cremona@gmail.com> wrote:

On 20 September 2012 14:55, Bill Allombert
<Bill.Allombert@math.u-bordeaux1.fr> wrote:
> On Thu, Sep 20, 2012 at 03:26:57PM +0200, Andreas Enge wrote:
>> On Thu, Sep 20, 2012 at 04:09:07PM +0300, Georgi Guninski wrote:
>> > I don't claim this is a bug in pari, more like a bug in the
>> > mentioned CAS.
>> >
>> > ? p1=x2*(x3-x4);p2=x2*(x3-2*x4);polresultant(p1,p2,x1)
>> > %1 = 0
>> >
>> > Since p1 and p2 certainly have common roots I expect the resultant
>> > w.r.t. x1 (not present in p1 or p2) to be able to vanish.
>>
>> As a polynomial in x1, both polynomials are constant and non-zero and so do
>> not have roots. The correct result should be 1.
>
> If x1 has highest priority then indeed the computation is done in
> Q(x2,x3,x4)[x1] and indeed the result is 1.
>
> x1;p1=x2*(x3-x4);p2=x2*(x3-2*x4);polresultant(p1,p2,x1)
> %1 = 1

I don't think this is a good enough answer (sorry, Bill!).    I know
that there are reasons for pari's variable priorities, and I have
personally been entertained by hem for many years,  but  if
"polresultant(p1,p2,x1)" is to correspond to any mathematically
correct resultant function then it has to be independent of that
(invisible) priority.

John

>
> Cheers,
> Bill.
>