#13566: Simplicial complex examples as singletons
---------------------------------------------------+------------------------
Reporter: tscrim | Owner: tscrim
Type: enhancement | Status: needs_work
Priority: minor | Milestone: sage-5.6
Component: algebraic topology | Resolution:
Keywords: simplicial | Work issues:
Report Upstream: N/A | Reviewers: Travis
Scrimshaw
Authors: Christian Nassau, John Palmieri | Merged in:
Dependencies: #13244, #12587 | Stopgaps:
---------------------------------------------------+------------------------
Comment (by nbruin):
Replying to [comment:20 tscrim]:
> If I understand #13115/the thread correctly, a way to do this would be:
>
> - have an `import homology/examples as simplical_complexes` in the
`all.py`
> - Make each of these methods into a subclass of `SimplicialComplex` and
`UniqueRepresentation` and have these be at the module level
>
> since right now `SimplicialComplex` is mutable until specified
otherwise. (I guess with this we can also do some optimization with
certain methods, such as homology for `Sphere`... and that should be a
different ticket.)
Yes, that sounds looks like a sensible approach. Additionally, if that
seems like a heavy-weight solution (it does to me), one should probably
see if uniqueness is so important that it warrants a subclass and/or if
there are other pressing reasons to make these subclasses. Reasons against
uniqueness:
- `SimplicialComplex` is not a parent so there's sage-technical reason to
enforce uniqueness (that's just a reason not ''for'' uniqueness)
- While any two `Sphere(3)` complexes are isomorphic, they are not
canonically so, so mathematically there can be good reasons to have
multiple non-identical spheres in memory.
- It makes things like `Sphere` behave different from `SimplicialComplex`
(and more generally not simple ''be'' a `SimplicialComplex`. That makes
code harder to maintain because now you have similar-but-subtly-different
acting objects. You should only do that if there's a benefit elsewhere.
Should uniqueness of `SimplicialComplexes` be desirable in general (why?
are they meant to become parents?) then it should perhaps be fixed on that
level. Mutable obviously can't be forced to be unique, so then you should
probably make two: `SimplicialComplex` and `MutableSimplicialComplex` (one
a subclass of the other if at all possible), where you can make the
immutable one unique by also inheriting from UniqueRepresentation. Going
to the immutable one then of course should return an immutable ''copy'',
not just change a flag.
Alternatively, (I don't know if that would be too hackish) you could add
another flag, `canonical_instance=true/false` (only to be used with
`is_mutable=False`), or make (a renamed version of) `is_mutable` tristate,
to determines whether a cache is involved. That would have the severe
drawback you'd have to break open the caching mechanism used in
`UniqueRepresentation`.
If you find there's no need for `Sphere` etc. to be anything more than
just a `SimplicialComplex` the implementation becomes ''really'' easy:
`sage.homology.examples.Sphere` can simple be a function, returning the
relevant `SimplicialComplex`.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/13566#comment:21>
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.
