On 23 October 2016 at 18:13, John Cremona <john.crem...@gmail.com> wrote:
> On 23 October 2016 at 16:45, Vincent Delecroix
> <20100.delecr...@gmail.com> wrote:
>> John, there seems to be a confusion in your answer.
>
> Right -- thanks for clarifying. The current behaviour is what I would
> expect when coercing (or at least converting) into Zmod(n) but we are
> implementing something else for r%n to be consistent to what people
> expect when r is real. OK.
Yes. This is the point. Sage started to fork Python behaviour when
implementing the operator %. We want to reverse it for compatibility
and consistency.
Note that Sage behavior is also wrong with respect to the tilde ~.
Sage uses it as unary inverse but in Python it stands for
bitcomplement. Jeroen opened a thread about that some months ago.
> One solution is surely to not have another method on QQ at all, but
> let users use the existing Zmod(n)(r) and lift if they need an element
> of ZZ?
That is indeed a solution! But I find it not very user friendly and
bad from the point of view of performance. Moreover, to implement
correctly the conversion Zmod(n)(r) in #21745 I had to copy a lot of
times the same line
((r.numerator() % n) * (r.denominator().inverse_mod(r))) % n
I wanted to get rid of it by having a proper method on rationals.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
