Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Adding support to input virtual knots #4

Open
zitterbewegung opened this issue Jul 3, 2020 · 11 comments
Open

Adding support to input virtual knots #4

zitterbewegung opened this issue Jul 3, 2020 · 11 comments

Comments

@zitterbewegung
Copy link

Hi, how would one approach adding support for Sphereogram to support virtual knots?

I was thinking about subclassing the crossing class. Would this be the right approach?
@culler
Copy link
Member

culler commented Jul 3, 2020 via email

@zitterbewegung
Copy link
Author

zitterbewegung commented Jul 4, 2020 •
edited
Loading

So if I understand the crossing conventions {0,+1,-1} would it be better if I did {0,+1,-1,2} or would I just add a boolean to say if it is virtual or not?

@culler
Copy link
Member

culler commented Jul 4, 2020 via email

@NathanDunfield
Copy link
Member

There is no particular need to have the values of Crossing.sign have a fixed type. So I would just use the string "virtual". Makes the code easy to read:

if C.sign == 1:
    ...
elif C.sign == 'virtual':
    ...

@zitterbewegung
Copy link
Author

Seems to be a UI to input virtual knots at https://github.com/kmill/knotfolio/tree/virtual

@culler
Copy link
Member

culler commented Aug 5, 2020 via email

@NathanDunfield
Copy link
Member

Seems to be a UI to input virtual knots at https://github.com/kmill/knotfolio/tree/virtual

Assuming it works like Kyle's base knotfolio, it starts with an image of a knot (e.g. a photo of chalkboard or scan of a drawing on paper) and then works out the topological description of the knot via image analysis. Which is extremely cool, even for non-virtual knots.

Note our PLink, which is the standard knot editor in SnapPy, has limited support for virtual crossings. This was added to make it possible to input square-tiled surfaces into Twister. I don't recall the details and I think the feature is hidden by default. Let us know if you need pointers to where it is in the PLink code.

@zitterbewegung
Copy link
Author

zitterbewegung commented Aug 5, 2020 via email

@NathanDunfield
Copy link
Member

In terms of the UI, to turn an ordinary crossing into a virtual one, you shift-click on it. From https://github.com/3-manifolds/PLink/blob/master/plink_src/crossings.py it looks like each Crossing object has a is_virtual attribute, so I would just search code in plink_src to find out where else is_virtual is accessed (looks like manager.py is key). We do support saving virtual knot projections to a file, but the PD and Gauss do not encode the virtual crossings.

@zitterbewegung
Copy link
Author

zitterbewegung commented Aug 5, 2020 via email

@NathanDunfield
Copy link
Member

Would this be applicable for a gauss code for virtual knots ? https://www.math.toronto.edu/drorbn/Students/GreenJ/gausscode.html

Seems reasonable, though I note the scheme there does not encode the virtual crossings at all. Which is reasonable choice theoretically, as one is really thinking about knots in (surface) x I, but does mean that choices have to be made to go from a Gauss code as above to an actual planar diagram that could be displayed to the user.

In terms of representing virtual knots internally in Spherogram, for the same reason perhaps one could simply omit the virtual crossings entirely. That is a VirtualLink would just be a subclass of Link where the check_planarity call in the __init__ method is disabled...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@zitterbewegung @culler @NathanDunfield