#13400: Use strong caches diligently
-------------------------------+--------------------------------------------
Reporter: nbruin | Owner: robertwb
Type: enhancement | Status: new
Priority: major | Milestone: sage-wishlist
Component: coercion | Resolution:
Keywords: | Work issues:
Report Upstream: N/A | Reviewers:
Authors: | Merged in:
Dependencies: | Stopgaps:
-------------------------------+--------------------------------------------
Comment (by SimonKing):
Replying to [comment:25 nbruin]:
> Are you taking the following into account?
> {{{
> sage: GF(13) is Integers(13)
> False
> }}}
Apparently I do, since the timings improve in the same way:
Without [attachment:trac_13400_quick_ZZ_ideal.patch] one has
{{{
sage: %time L = [Integers(n) for n in srange(10000)]
CPU times: user 4.36 s, sys: 0.05 s, total: 4.40 s
Wall time: 4.42 s
}}}
With the patch, one has
{{{
sage: %time L = [Integers(n) for n in srange(10000)]
CPU times: user 3.38 s, sys: 0.08 s, total: 3.46 s
Wall time: 3.47 s
}}}
Hence the speedup is `(4.42-3.47)/4.42`: about 21%
> I did not quite understand the following:
> {{{
> sage: R=Integers(13); k=GF(13)
> sage: a=R(1); b=k(1)
> sage: R is k
> False
> sage: type(a); type(b)
> <type 'sage.rings.finite_rings.integer_mod.IntegerMod_int'>
> <type 'sage.rings.finite_rings.integer_mod.IntegerMod_int'>
> sage: parent(a+b) is k
> True
> sage: R.has_coerce_map_from(k), k.has_coerce_map_from(R)
> (False, True)
> }}}
> So `k` seems to be the more canonical in the eyes of sage. But why the
difference between `k` and `R` at all?
Actually I have wondered about that, myself. I guess it is just a tribute
to very old code. IIRC, someone (William Stein?) argued as follows: It is
actually typical that coercion goes from "less structure / simpler" (e.g.
from a base ring) to "more structure / more complicated" (e.g., to a
polynomial ring or to a matrix space over the base ring).
And: If we have an object O in some category (say, GF(5) in the category
of fields), and an object X that is obtained from O by a forgetful functor
(say, Integers(5) in the category of fields), and we have a in O and b in
X, then we typically want that a+b belongs to the "richer" structure -
otherwise, we would have worked in X right away.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/13400#comment:26>
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 post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
