#10963: More functorial constructions
-------------------------------------+-------------------------------------
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_work
Priority: major | Milestone: sage-6.1
Component: categories | Resolution:
Keywords: days54 | Merged in:
Authors: Nicolas M. Thiéry | Reviewers: Simon King, Frédéric
Report Upstream: N/A | Chapoton
Branch: | Work issues: Detect and fix
public/ticket/10963 | Heisenbugs
Dependencies: #11224, #8327, | Commit:
#10193, #12895, #14516, #14722, | 8eaf51a82c4e2194769db13457979ae601ebbc04
#13589, #14471, #15069, #15094, | Stopgaps:
#11688, #13394, #15150, #15506 |
-------------------------------------+-------------------------------------
Comment (by SimonKing):
Replying to [comment:260 nbruin]:
> Another issue (and this is already in the code) is that
`base_category_and_axiom` is a module level function, so has a global
cache. Any input to it (including erroneous input?) will be stored for
eternity: memory leak.
No, it is not a memory leak. The stored items are formed by classes that
are defined in modules anyway.
> In addition, `_base_category_and_axiom` is a lazy class attribute, so it
has a cache of its own. Why are we caching things twice?
When making this function an uncached function (thus relying on the lazy
attribute), and hence when removing the hack with temporarily filling the
cache, one gets this many calls of `base_category_class_and_axiom(cls)`,
sorted by `cls`:
{{{
sage.categories.sets_cat.Sets.Infinite: 1,
sage.categories.commutative_rings.CommutativeRings: 98,
sage.categories.distributive_magmas_and_additive_magmas.AdditiveCommutative.AdditiveUnital:
1,
sage.categories.distributive_magmas_and_additive_magmas.AdditiveAssociative.AdditiveCommutative:
1,
sage.categories.distributive_magmas_and_additive_magmas.DistributiveMagmasAndAdditiveMagmas.AdditiveAssociative:
1,
sage.categories.additive_magmas.AdditiveMagmas.AdditiveCommutative: 1,
sage.categories.additive_magmas.AdditiveUnital.AdditiveInverse: 1,
sage.categories.additive_magmas.AdditiveMagmas.AdditiveUnital: 1,
sage.categories.distributive_magmas_and_additive_magmas.AdditiveUnital.Associative:
1,
sage.categories.magmas.Magmas.Commutative: 1,
sage.categories.distributive_magmas_and_additive_magmas.AdditiveUnital.AdditiveInverse:
1,
sage.categories.magmas.Unital.Inverse: 1,
sage.categories.magmas.Magmas.Unital: 1,
sage.categories.commutative_algebras.CommutativeAlgebras: 97,
sage.categories.finite_fields.FiniteFields: 98,
sage.categories.finite_enumerated_sets.FiniteEnumeratedSets: 98,
sage.categories.finite_sets.FiniteSets: 94,
sage.categories.finite_semigroups.FiniteSemigroups: 91,
sage.categories.finite_monoids.FiniteMonoids: 91,
sage.categories.unital_algebras.UnitalAlgebras.WithBasis: 1,
sage.categories.infinite_enumerated_sets.InfiniteEnumeratedSets: 97
}}}
So, it may be a hack, but what else do you suggest to avoid this high
number of function calls?
> Finally, and there are some design decisions in the ticket itself:
Currently, there is code that relies on packages being in
`sage.categories` by looking at the `__name__` and doing string mangling
on it. Furthermore, it relates the class name `CamelCase` to the module
`camel_case`. These are all fine as programming ''conventions'' but I find
it questionable if it's a good idea to engrave them in ''program logic''.
+1.
Ceterum censeo: Trac sucks. My browser keeps jumping to the middle of this
long ticket while I write.
--
Ticket URL: <http://trac.sagemath.org/ticket/10963#comment:261>
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 unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/groups/opt_out.
