58 views

Skip to first unread message

Jul 30, 2012, 4:18:02 AM7/30/12

to sage-...@googlegroups.com

Hi,

in the definition of a QuotientRing there is the following assumption

ASSUMPTION:

``I`` has a method ``I.reduce(x)`` returning the normal form

of elements `x\in R`. In other words, it is required that

``I.reduce(x)==I.reduce(y)`` `\iff x-y \in I`, and

``x-I.reduce(x) in I``, for all `x,y\in R`.

On the other hand, the default definition of reduce in

sage/rings/ideal.py says

def reduce(self, f):

return f # default

Wouldn't it be better to raise a NotImplementedError?

These are the consequences:

sage: Z16x.<x> = Integers(16)[]

sage: GR.<y> = Z16x.quotient(x**2 + x+1 )

sage: I = GR.ideal(4)

sage: I.reduce(GR(6))

6 # should be reduced mod 4

another example is

sage: J = Z16x.ideal([x+1, x+1]) # just to avoid that the ideal is identified as a principal ideal

sage: R.<z> = Z16x.quotient(J)

sage: R(x) # should be 15

Best,

Thomas

in the definition of a QuotientRing there is the following assumption

ASSUMPTION:

``I`` has a method ``I.reduce(x)`` returning the normal form

of elements `x\in R`. In other words, it is required that

``I.reduce(x)==I.reduce(y)`` `\iff x-y \in I`, and

``x-I.reduce(x) in I``, for all `x,y\in R`.

On the other hand, the default definition of reduce in

sage/rings/ideal.py says

def reduce(self, f):

return f # default

Wouldn't it be better to raise a NotImplementedError?

These are the consequences:

sage: Z16x.<x> = Integers(16)[]

sage: GR.<y> = Z16x.quotient(x**2 + x+1 )

sage: I = GR.ideal(4)

sage: I.reduce(GR(6))

6 # should be reduced mod 4

another example is

sage: J = Z16x.ideal([x+1, x+1]) # just to avoid that the ideal is identified as a principal ideal

sage: R.<z> = Z16x.quotient(J)

sage: R(x) # should be 15

Best,

Thomas

Jul 30, 2012, 5:36:06 AM7/30/12

to sage-...@googlegroups.com

2012/7/30 Thomas Feulner <thomas....@uni-bayreuth.de>:

Right now, reduce does exactly what it says:

"""

Return the reduction of the element of `f` modulo the ideal

`I` (=self). This is an element of `R` that is

equivalent modulo `I` to `f`.

"""

If you don't get any objections, you could change this documentation

and add a deprecation warning to this default implementation. Then

later it can be changed to NotImplementedError.

> These are the consequences:

>

> sage: Z16x.<x> = Integers(16)[]

> sage: GR.<y> = Z16x.quotient(x**2 + x+1 )

> sage: I = GR.ideal(4)

> sage: I.reduce(GR(6))

> 6 # should be reduced mod 4

> another example is

> sage: J = Z16x.ideal([x+1, x+1]) # just to avoid that the ideal is

> identified as a principal ideal

> sage: R.<z> = Z16x.quotient(J)

> sage: R(x) # should be 15

I'm fine with all the outputs above, though they can be improved.

However, I think the following is a bug:

sage: R(x+1) == 0

False

The only correct answer is "True". This goes wrong because the

"ASSUMPTION" that you quotes above is not satisfied. However, I would

trust R to be correct, because I never get to see the assumption, even

when I type

Z16x.quotient??

R??

Suggested fixes:

- add the assumption to the documentation of the quotient method of Z16x, or

- add some checks to the equality tests of QuotientRing, or

- kill the default implementation of reduce as you suggest (but do

deprecation first).

(or some combination of the above)

Best,

Marco

> Hi,

>

> in the definition of a QuotientRing there is the following assumption

>

> ASSUMPTION:

>

> ``I`` has a method ``I.reduce(x)`` returning the normal form

> of elements `x\in R`. In other words, it is required that

> ``I.reduce(x)==I.reduce(y)`` `\iff x-y \in I`, and

> ``x-I.reduce(x) in I``, for all `x,y\in R`.

>

> On the other hand, the default definition of reduce in

> sage/rings/ideal.py says

> def reduce(self, f):

> return f # default

>

> Wouldn't it be better to raise a NotImplementedError?

It would be safer, but it sounds like it would break a lot of code.
>

> in the definition of a QuotientRing there is the following assumption

>

> ASSUMPTION:

>

> ``I`` has a method ``I.reduce(x)`` returning the normal form

> of elements `x\in R`. In other words, it is required that

> ``I.reduce(x)==I.reduce(y)`` `\iff x-y \in I`, and

> ``x-I.reduce(x) in I``, for all `x,y\in R`.

>

> On the other hand, the default definition of reduce in

> sage/rings/ideal.py says

> def reduce(self, f):

> return f # default

>

> Wouldn't it be better to raise a NotImplementedError?

Right now, reduce does exactly what it says:

"""

Return the reduction of the element of `f` modulo the ideal

`I` (=self). This is an element of `R` that is

equivalent modulo `I` to `f`.

"""

If you don't get any objections, you could change this documentation

and add a deprecation warning to this default implementation. Then

later it can be changed to NotImplementedError.

> These are the consequences:

>

> sage: Z16x.<x> = Integers(16)[]

> sage: GR.<y> = Z16x.quotient(x**2 + x+1 )

> sage: I = GR.ideal(4)

> sage: I.reduce(GR(6))

> 6 # should be reduced mod 4

> another example is

> sage: J = Z16x.ideal([x+1, x+1]) # just to avoid that the ideal is

> identified as a principal ideal

> sage: R.<z> = Z16x.quotient(J)

> sage: R(x) # should be 15

However, I think the following is a bug:

sage: R(x+1) == 0

False

The only correct answer is "True". This goes wrong because the

"ASSUMPTION" that you quotes above is not satisfied. However, I would

trust R to be correct, because I never get to see the assumption, even

when I type

Z16x.quotient??

R??

Suggested fixes:

- add the assumption to the documentation of the quotient method of Z16x, or

- add some checks to the equality tests of QuotientRing, or

- kill the default implementation of reduce as you suggest (but do

deprecation first).

(or some combination of the above)

Best,

Marco

Aug 6, 2012, 5:50:27 PM8/6/12

to sage-...@googlegroups.com

I'm just letting the list know that there is a patch at http://trac.sagemath.org/sage_trac/ticket/13345 deprecating the default implementation of "Ideal_generic.reduce" in favour of NotImplementedError.

Op maandag 30 juli 2012 11:36:06 UTC+2 schreef Marco Streng het volgende:

Op maandag 30 juli 2012 11:36:06 UTC+2 schreef Marco Streng het volgende:

2012/7/30 Thomas Feulner:

Reply all

Reply to author

Forward

0 new messages

Search

Clear search

Close search

Google apps

Main menu