Hi!
By lack of decision for the moment, I postponed the change to a later
ticket, I just uploaded on trac a minimal version of my patch which
just lets IntegerModRing use its categories, without upgrading its
category to Fields(): see
On Sat, Mar 20, 2010 at 04:35:01PM +0100, Florent hivert wrote:
Hi There,
In order to let Rob use IntegerModRing(n) as example of finite
additive group for his cool Cayley graph feature (#7555), I just wrote
a patch (#8562) letting IntegerModRing(n) use the category
framework.
On Sat, Mar 20, 2010 at 03:50:43PM +, John Cremona wrote:
There are surely many other similar situations, for example when
constructing a commutative ring it might be expensive to determine
whether or not it is an Integral Domain.
Yup.
I would always use GF(p) rather than IntegerMod(p)
Hi!
In order to let Rob use IntegerModRing(n) as example of finite
additive group for his cool Cayley graph feature (#7555), I just wrote
a patch (#8562) letting IntegerModRing(n) use the category
framework. That was essentially a one liner, plus minor updates here
and there, and all test
Hi There,
In order to let Rob use IntegerModRing(n) as example of finite
additive group for his cool Cayley graph feature (#7555), I just wrote
a patch (#8562) letting IntegerModRing(n) use the category
framework. That was essentially a one liner, plus minor updates here
and there, and
I would say that you should never test for primality unless
specifically required, e.g. if the user asks is_field() (after which
the category could be upgraded? I don't know if that is possible).
I would always use GF(p) rather than IntegerMod(p) for when I know p
is prime. it is is vital in
On 20-Mar-10, at 8:50 AM, John Cremona wrote:
I would say that you should never test for primality unless
specifically required, e.g. if the user asks is_field() (after which
the category could be upgraded? I don't know if that is possible).
I would always use GF(p) rather than IntegerMod(p)
