#269: Add __mod__ to coercion model
-------------------------------------+-------------------------------------
       Reporter:  dmharvey           |        Owner:  somebody
           Type:  enhancement        |       Status:  needs_review
       Priority:  major              |    Milestone:  sage-7.3
      Component:  coercion           |   Resolution:
       Keywords:                     |    Merged in:
        Authors:  Jeroen Demeyer     |    Reviewers:
Report Upstream:  N/A                |  Work issues:
         Branch:                     |       Commit:
  u/jdemeyer/add___mod___to_coercion_model|  
35b3dfa3a464f73426dd60a41bb681d15e2efcfb
   Dependencies:                     |     Stopgaps:
-------------------------------------+-------------------------------------
Description changed by jdemeyer:

Old description:

> Add `__mod__` to the coercion model for `Element` and change `__mod__` to
> `_mod_` where applicable.
>
> We change the behaviour of `__mod__` for integer mod rings: the following
> (which is mathematically meaningless) is now an error:
> {{{
>              sage: a = next_prime(2**31)
>              sage: b = Integers(a)(100)
>              sage: a % b
>              Traceback (most recent call last):
>              ...
>              ZeroDivisionError: reduction modulo 100 not defined
> }}}
>
> Apart from this, this branch does not change any semantics of
> remaindering.
>
> As proof-of-concept for refactoring more generally the arithmetic methods
> on `Element`, the implementation of `__mod__` is different from the usual
> implementation:
> 1. `_mod_` will be added to `Element` and not `RingElement` or similar.
> 2. The prototype is `cpdef _mod_(self, Element other)` with no typing for
> the return value.
> 3. We do not implement the in-place `__imod__` which is useless anyway
> with coercion.
>
> My intention is that eventually all arithmetic methods should be
> implemented like `__mod__`.

New description:

 Add `__mod__` to the coercion model for `Element` and change `__mod__` to
 `_mod_` where applicable.

 We change the behaviour of `__mod__` for integer mod rings: the following
 (which is mathematically meaningless) is now an error:
 {{{
              sage: a = next_prime(2**31)
              sage: b = Integers(a)(100)
              sage: a % b
              Traceback (most recent call last):
              ...
              ZeroDivisionError: reduction modulo 100 not defined
 }}}

 Apart from this, this branch does not change any semantics of
 remaindering.

 As proof-of-concept for refactoring more generally the arithmetic methods
 on `Element`, the implementation of `__mod__` is different from the usual
 implementation:
 1. `_mod_` will be added to `Element` and not `RingElement` or similar.
 2. The prototype is `cpdef _mod_(self, other)` with no typing for the
 arguments or return value.
 3. We do not implement the in-place `__imod__` which is useless anyway
 with coercion.

 My intention is that eventually all arithmetic methods should be
 implemented like `__mod__`.

--

--
Ticket URL: <http://trac.sagemath.org/ticket/269#comment:30>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica, 
and MATLAB

-- 
You received this message because you are subscribed to the Google Groups 
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.

Reply via email to