On Tuesday, August 19, 2014 12:13:07 PM UTC-7, Simon King wrote:
I think this would make sense---of course with bidirectional coercions,
as mentioned in my previous mail.
Bidirectional coercion implies memory leak: The strong references to the
codomains on the coercion maps will keep
Hi Jean-Pierre,
I'm currently wrapping FLINT fq modules into new Sage classes for finite
fiels and got strange coercion errors when running non trivial code.
Indeed, the polynomial ring constructors use a dictionary and so relies on
the hash of finite fields (the parents).
By some chance,
On Tuesday, August 19, 2014 7:39:18 PM UTC+2, Peter Bruin wrote:
Hi Jean-Pierre,
I'm currently wrapping FLINT fq modules into new Sage classes for finite
fiels and got strange coercion errors when running non trivial code.
Indeed, the polynomial ring constructors use a dictionary and so
I also see that some double underscore methods rather than single
underscore ones are implemented, that might be one of the problems here.
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To unsubscribe from this group and stop receiving emails
On Tuesday, August 19, 2014 8:26:13 PM UTC+2, Jean-Pierre Flori wrote:
I also see that some double underscore methods rather than single
underscore ones are implemented, that might be one of the problems here.
Or the other way around...
--
You received this message because you are
I guess _cmp_ should be used for cython parents and __cmp__ for python ones.
There is in parent.pyx:
# Both are parents -- but need *not* have the same type.
if HAS_DICTIONARY(left):
r = left.__cmp__(right)
else:
r =
Hi Jean-Pierre,
On 2014-08-19, Jean-Pierre Flori jpfl...@gmail.com wrote:
Though (non-prime) finite fields with the same order and defining
polynomial are considered equal, I'd say the hashes should be different.
Absolutely no way. If they are considered equal, then the hashes must be
the
Hi Jean-Pierre,
I'm not sure I understand correctly; do you mean that the problem is
caused by fields comparing equal even if the implementations are
different? I think we should in any
Not sure.
I seem to be able to produce things with different hashes but equal...
sage: GF(13**5,
Hi Peter,
On 2014-08-19, Peter Bruin pjbr...@gmail.com wrote:
I'm not sure I understand correctly; do you mean that the problem is caused
by fields comparing equal even if the implementations are different? I
think we should in any case make FiniteField inherit from WithEqualityById,
so
On Tuesday, August 19, 2014 9:05:15 PM UTC+2, Simon King wrote:
Hi Jean-Pierre,
On 2014-08-19, Jean-Pierre Flori jpf...@gmail.com javascript: wrote:
Though (non-prime) finite fields with the same order and defining
polynomial are considered equal, I'd say the hashes should be
Thanks for all the answers.
It seems my issues was caused by defining the _cmp_ method with the wrong
number of underscores in my cython extension classes.
Do you confirm that for parents defined in a usual Python class __cmp__
with two underscores should be used and for a cython extension
On top of that, Python3 want have cmp anymore :)
--
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,
Hi Simon,
I'm not sure I understand correctly; do you mean that the problem is
caused by fields comparing equal even if the implementations are
different? I think we should in any case make FiniteField inherit
from WithEqualityById, so two instances compare equal if and only if
they are
13 matches
Mail list logo
