> < ^ Date: Mon, 10 May 1999 11:37:57 +0100 (BST)
> < ^ From: Alexander Hulpke <hulpke@math.colostate.edu >
> < ^ Subject: Re: Galois Groups

Dear Gap-Forum,

Allow me comments on two points brought up in the two recent replies.

> > KANT 2.0 can determine Galois groups of polynmials up to degree 15. Can this
> > be done in GAP3 in a relatively easy way?
Yes, GAP3 also provides the functionality up to degree 15, Igor Schien's
mail already explained how to do this.

> In general, GAP3 is much slower than KANT in finding Galois groups ( unless
> the group is S_n or A_n, where it's fast for both). PARI, on the other hand,
> is faster than KANT ( save for odd degree-11 groups ). However, PARI cannot
> go beyond degree-11.
Indeed GAP3 is slower. (When I implemented the code in 1993 all other
systems I knew could go only up to degree 10 -- so there also was no
chance to compare the times.) This is partially due to a
different strategy being used by Kant and Pari, but mainly due to the fact
of both systems using floating point approximation of roots.

Besides the fact that GAP does not have floating point numbers, there is one
major problem with this: As far as I know both systems mentioned ignore error
propagation and are very economic with the approximation accuracy they use.
I therefore would not want to rely on their results for polynomials whose
coefficients are 20-digit or so.

These problems will (or -- not being able to rule out programming errors --
I better say: should) not happen in GAP: Unless a function explicitly is
defined to give only a probabilistic result, the result is proven correct
and if it doesn't, it is a bug. However this comes at a certain cost which
slows down the calculation in GAP.

If you are rather interested in quick results, there also is a function
`ProbabilityShapes' in GAP3 which gives a (list of) likely Galois groups,
but whose result is not proven.

> Is there a chance of speeding up Galois() for GAP4?
One reason of not having converted the existing code is that I plan to
implement some improvements that should increase speed as well as extend the
algorithm to higher degrees, but as the code does not yet exist I don't want
to promise anything yet.

Alexander


> < [top]