Recognizing the topology of surfaces

[CharlesArnal]

Dear all,

My question is as follows. I have some patchworked surface S (in either \( \mathbb{R}^3 \) or \( \mathbb{R}\mathbb{P}^3 \)), obtained with something like

Code: Select all

$S_0 = new Hypersurface<Min>(DUAL_SUBDIVISION=>$my_dual_sub); $S = $S_0>PATCHWORK(SIGNS=>$my_signs)

I know how to compute the homology of S with coefficients in \( \mathbb{Z}_2 \), but is there any simple way to recover its topology,
i.e. something like "the surface S is the union of 2 spheres, a genus 2 surface and a copy of the projective plane" ?
If it's not doable directly, is there any way that I can recover each connected component of S separately and in a way that would allow me to compute its \( \mathbb{Z}_2 \) homology ?
As I am working with real algebraic projective surfaces, I could recover the topology using only the \( \mathbb{Z}_2 \) homology of each connected component (and the degree of S).

I am a bit rusty with polymake and I might have failed to see an obvious answer, in which case I hope you will forgive me.

Best regards,

Charles Arnal

[pvater]

hey charles,

i've been out of math for a while, so i might be forgetting basic stuff.
but afaik there is atm no direct way to do this unfortunately.

there is however a pretty straight forward idea for such an algorithm, since we have knowledge of the combinatorics of the surface via the real phase structure:
take a facet in the real phase structure (i.e. (f,o) for a facet f of the original tropical surface for an orthant o), and iteratively find all such facets it "connects" to (*).
this gives you one connected component as a cell complex, and you can ask polymake for its euler characteristic for example.
continue with all non visited facets for the remaining connected components.

(*): figuring out which and how facets of different orthants intersect is slightly tricky technically - i think i implemented something like this once in some throw-away script, if i find time i'll make this functionality accessable in a user-method. i also think that lars kastners cellularSheaves extension might be able to do this, though my memory is getting very hazy now.

a slightly different approuch - there is the method ->realize() (or something like that) which builds a polyhedral complex representation of the patchworked surface in R3. if you only care about the topology in R3 then the above approach becomes very simple with this (although the R3 topology depends on the affine chart, so how useful is it actually?).
to get the topology in RP3 you'd need to "connect" the unbounded facets of that polyhedral complex "at infinity" (as in (*)) - not sure if this would be simpler than the other approach.

let me know if any of that gibberish makes sense, or rather if it doesn't!

best, paul

[joswig]

Could you please upload your `$my_dual_sub` and `$my_signs`? One way would be to save the `$S_0` object and share the resulting JSON.

I can't promise, but maybe we can do a bit more here.

[CharlesArnal]

Dear Paul,

Thanks for your answer. As you suspected, I am more interested in surfaces in RP3, hence your second approach would not work unaltered. Regarding your first suggestion, I agree that conceptually this seems like a very sound way to proceed, but it looks like it would require me to get my hands very dirty by directly working with relatively user unfriendly objects to implement it in practice (it's not that I am lazy, but rather that I am not sure I am comfortable enough with Polymake to succeed in a reasonable time). Thence my hope that there would be some already existing tool that would allow me to extract each connected component.

[CharlesArnal]

Dear Michael,

Thanks for thinking about my problem!
One thing I might not have made clear is that I don't have ONE surface whose topology I want to compute - rather, I have some process that generates thousands of surfaces whose topology I want to compute.
With that in mind, I have attached the JSON file of one such surface (in fact saved as a .txt because I can't upload .json files to the forum), corresponding to the `$S_0` from my example. In practice, most of my surfaces are more "complicated" (in terms of degree, number of connected components, Betti numbers, ...).

[pvater]

i had an idea to simplify the above approach:

instead of naively constructing a cell-complex representation for a connected component C, i think it should be possible to save the combinatorics of C in an object like the real phase structure R of the patchworked hypersurface H, but restricted to C (i.e., it tells you for each facet of H in which orthant it has a copy - IF it lies in C).
Call it R_C.
with that we can just create a new `PATCHWORK` subobject on our hypersurface, initializing its real phase structure with R_C - `...->PATCHWORK(SIGNS=>[original signs], REAL_PHASE=>R_C)` (this is of course not an actual patchworked hypersurface, but we can pretend; the signs are unfortunately necessary for technical reasons).
and for this polymake can calculate the `...->BETTI_NUMBERS_Z2`. (*)

this means we don't need to manually worry about the combinatorics of how copies of facets are glued together between different orthants, because the implementation already takes care of that internally.
we just need to figure out WHEN they are glued together, in order to build R_C.
and now that i've thought about it again, the criterion is relatively simple:

recall that we encode orthants via the binary representation of unsigned integers, e.g. (+,-,+) -> 101 -> 5.
take a copy (f,o) of a facet f of H.
consider the set D of the directions of the vertices at infinity of f as 0-1-vectors.
for each subset {d1,...,dk} of D, (f,o) is glued to (f,o') where o' = o XOR d1 XOR ... XOR dk.
(for the purposes of this algorithm it's enough to glue (f,o) to (f,(o XOR d)) for each d in D, and then just iterate the gluing step)

again, something like this should probably be a user-function, but maybe it's good enough for now.

the thing that's missing in this approach is the identification of a non-orientable component, which, unfortunately, i don't know how to do here.
also, (*) should be tested, since i'm only like 80% sure that it works, and i can't check right now.

[CharlesArnal]

Dear Paul,

Thanks for your ideas, and sorry for my slightly delayed answer (I was moving house).
I understand the principles behind your suggestion, and it seems very reasonable to me, but I am still not sure how I should proceed to implement it in practice; for example, how could I get this R_C object you speak of ?
Would I have to play around with Polymake's C++ code ? I have only used the more "user friendly" sides of Polymake up till now (pre-defined objects, rules and properties).

I don't think orientability would be an issue : there can be either 0 or 1 non-orientable component in a (smooth) projective real algebraic surface depending on the degree, and assuming that I can compute the Z2 Betti numbers associated to these R_C objects you spoke of, the non-orientable component would be the only component with an odd total Betti number (it is a projective plane with some handles glued to it, so its Betti numbers would be something like [1 1+2k 1]).

[pvater]

ah yes you're right about the orientability!

there's no need to write or look at c++.
the idea is to find the (facet, orthant)'s for each connected component, in the way i have described, and encode that information (for each connected component) in an object just like the object you get from `...->REAL_PHASE`.

recall how this works (admittedly i don't exactly remember the type of REAL_PHASE, but it's equivalent to a boolean matrix): for each entry (i, j) it tells you whether the i-th facet of the j-th orthant lies in the patchworked hypersurface or not.

so now for each connected component we build an object just like REAL_PHASE - this is what i called R_C - and create a new patchworked hypersurface, initializing its REAL_PHASE-property with R_C. this new hypersurface, representing the current connected component of the original hypersurface, should happily inform us of its `...->BETTI_NUMBERS_Z2`.

now that i re-read your comment i'm not sure anymore whether the above wasn't actually clear anyway, and your question is more about technical details?

anyways, i could also take a crack at this myself. it's probably not complicated to implement, i just need to set up polymake again, and i generally don't have much time anymore during the week currently.
we could also zoom call as a more efficient way of communication if you have more questions.

[CharlesArnal]

Indeed, the question was more about the technical details; I have really only ever used the most external tools provided by Polymake - writing simple stuff like "$S_0 = new Hypersurface<Min>(DUAL_SUBDIVISION=>$my_dual_sub);" is basically the extent of my knowledge.
Your answer does help me visualize a bit better how I should proceed in terms of code.
I have a few deadlines in the coming weeks, but it would be great if you agreed to a call after that !