Adding support to input virtual knots

[zitterbewegung]

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]

I think that extending the crossing class would be a good place to start. I am not sure if it needs to be a subclass, however. - Marc

…

On Fri, Jul 3, 2020 at 4:38 PM Joshua Herman ***@***.***> wrote: 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? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#4>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJ6CP2UUATC3H3WDFASAXLRZZFVJANCNFSM4OQCWSZQ> .

[zitterbewegung]

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]

Well, I had in mind that crossings would be right-handed, left-handed or virtual.

…

On Fri, Jul 3, 2020 at 10:07 PM Joshua Herman ***@***.***> wrote: So would I have a crossing class that would have another property that would be true or false if it is virtual or not? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#4 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJ6CP6XIGZ754ZGBP4HFALRZ2MI3ANCNFSM4OQCWSZQ> .

[NathanDunfield]

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]

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

[culler]

I don't think it would be practical to embed javascript in SnapPy. - Marc

…

On Tue, Aug 4, 2020 at 8:36 PM Joshua Herman ***@***.***> wrote: Seems to be a UI to input virtual knots at https://github.com/kmill/knotfolio/tree/virtual — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#4 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJ6CP7NFW5SO6LZTRWT7NLR7CZTTANCNFSM4OQCWSZQ> .

[NathanDunfield]

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]

Yea can you give me pointers where that would be at ?

…

Sent from my iPhone

On Aug 4, 2020, at 10:42 PM, Nathan Dunfield ***@***.***> wrote:  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. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[NathanDunfield]

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]

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

…

On Aug 4, 2020, at 10:56 PM, Nathan Dunfield ***@***.***> wrote:  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. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[NathanDunfield]

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...