2014-06-12 19:13 UTC+02:00, Robert Bradshaw <rober...@gmail.com>:
> On Thu, Jun 12, 2014 at 12:50 AM, Marc Mezzarobba <m...@mezzarobba.net>
> wrote:
>
>> But here is a similar example right from the Sage library (adapted from
>> http://wiki.sagemath.org/EqualityCoercion):
>>
>> sage: FiniteEnumeratedSet(GF(3))
>> {0, 1, 2}
>> sage: add(FiniteEnumeratedSet([0,1,2]))
>> 0
>
> Um, isn't that what you want? The sum of the elements of GF(p^e) for
> any odd prime is zero, which is a handy property.
In two fresh Sage consoles
{{{
sage: sum(FiniteEnumeratedSet([0,1,2]))
3
}}}
and
{{{
sage: FiniteEnumeratedSet(GF(3))
sage: sum(FiniteEnumeratedSet([0,1,2]))
0
}}}
Because FiniteEnumeratedSet has a cache on the input!
>>>> sage: {42, QQbar(42)}
>>>> {42, 42}
>>>> sage: {42, SR(42)}
>>>> {42}
>>>> sage: {2^100, SR(2^100)}
>>>> {1267650600228229401496703205376, 1267650600228229401496703205376}
>>>
>>> Hash is not as good as it could/should be for large symbolic integers.
>>> And for AA/QQbar.
>>
>> And do you honestly think this will ever be fixed for all sage objects?
>
> For the common ones at least. And sometimes elements should not define
> hash, as normalizing them is expensive, if even possible.
Are we allowed to through errors for them?
Vincent
--
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
