#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 tscrim):
Replying to [comment:21 nbruin]:
> Reasons against uniqueness:
>
> - `SimplicialComplex` is not a parent so there's no 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.
That is a good point since I believe not all triangulations of a (high
enough dimensional) sphere can be obtained by bistellar flips.
> - It makes things like `Sphere` behave different from
`SimplicialComplex` (and more generally not simply ''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.
Also a good point.
> 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.
What I was thinking when I created this ticket was that since these are
particular examples of simplicial complexes, they should be unique and
immutable. However, perhaps it would be better to have them be mutable
copies for computations rather than having the user create a copy (I don't
really know offhand if these are used computationally in Sage)...I will
leave this decision to someone who uses these more than me.
> 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`.
If it is decided to essentially do nothing, perhaps we should use this
ticket to move everything down to a function.
Also it seems like this needs to be rebased to 5.6.beta1.
Thanks,[[BR]]
Travis
PS - I may not be able to respond for 2 weeks
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/13566#comment:22>
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.
