#12630: Add representations of quivers and quiver algebras to sage
-------------------------------------------+--------------------------------
Reporter: JStarx | Owner: AlexGhitza
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-5.1
Component: algebra | Resolution:
Keywords: algebra, quiver, module | Work issues:
Report Upstream: N/A | Reviewers:
Authors: Jim Stark | Merged in:
Dependencies: #12412, #12413 | Stopgaps:
-------------------------------------------+--------------------------------
Comment (by SimonKing):
Replying to [comment:17 JStarx]:
> Innards of my code (line 1047). Why would only the first matter?
Because I thought that the failing doctest was of the kind "display a set
or dict that is returned by some method". In that case, the only problem
would be a non-unique string representation.
But now I was looking at the actual error the patchbot complained about,
and I see that the error went beyond that. If I understand correctly, you
have a set, and transform it into a tuple in order to use it in a cache
key, and then you display the cache key in one test, right?
Then you are right that the innards ought to be changed, because if you
used non-ordered tuples for a cache key then the cache was broken.
Note that there is an immutable version of sets, called "frozenset". It
can be used in cache keys! It is faster to compare two frozensets than to
have two tuples, one of them sorted, sort the second tuple, and compare
then:
{{{
sage: S = frozenset(randint(1,10000) for _ in range(1000))
sage: T = deepcopy(S)
sage: %timeit S==T
625 loops, best of 3: 33.8 µs per loop
sage: S2 = tuple(S)
sage: T2 = sorted(tuple(S))
sage: T2==S2
False
sage: sorted(S2)==T2
True
sage: %timeit sorted(S2)==T2
625 loops, best of 3: 312 µs per loop
}}}
Hence, if the cache access is time critical, then you could consider to
use frozenset (which would mean to be careful in the doctest, because
again the doctest would test against the non-unique string representation
of the cache key). But if time is no problem, then using ''sorted'' tuples
in the cache keys is fine.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/12630#comment:18>
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.