Knot Notation (Updated): September 7th, 2010

[Michael Ohene]

Update: The knot notation is near finalization but the automation is indefinitely stalled. Although I began with the program and finished the planning, the actual programming was too extensive to finish by myself. The notation can still be used to record knot moves, but is currently unable to automate the drawing of knots for computer programs; which would have been nice and a huge time saver.
My webpage : http://www.whatsthesequency.com/knot.html provides the current knot notation with better explanations than before. I still need feedback from people about any confusion with the notation.

The following is the original discussion

Hello,
   New guy here bringing new ideas.I have read these boards and I see that folks have no standard, concise way of describing how to tie a knot. I have worked on a notation which is adapted from Thomas Fink and Yong Mao's notation for tying tie knots.
My notation: http://www.whatsthesequency.com/knot.html

The notation may have a few iffy areas, for example some terms (section) still do not have clear definitions.
It may be helpful to view Fink and Mao's Nature article to understand the basis of their notation:
http://www.tcm.phy.cam.ac.uk/~tmf20/TIES/PAPERS/paper_nature.pdf
Comparing their Four-in-Hand notation to my Four-in-Hand notation will probably be the best help in understanding my notation.

Quick explanation, (correction:this quick explanation is incomplete):
L-Left turn, left offset
R-Right turn, right offset
S₁-Penetrate the first loop

subscripts...
i-into the page (away from you), sometimes over
o-out of the page (toward you), sometimes under
x-performed on an object (e.g. a stick, metal road, hook, etc.)
subscript (for R or L)₁ - performed on first section of rope
subscript (for R or L)_-2 - performed on second to last section of rope

Quick practical examples of my notation:
Clove Hitch: L_ixR_oxi1L_oxo-1
Clove hitch: L_ixR_oxi1ixL_oxi-1
Four in Hand: L_iR_o1L_i1S_o1S_i2
Icicle Hitch: R_(ixox)⁵L_i1oxS_i1

This notation has many possible benefits:
1. Concise explanation on how to tie knots
2. Revealing patterns - notice the alternating R,L pattern - in knots to:
a. analyse knot integrity
b. design knots
3. To my knowledge, the notation is structured to have only one interpretation, therefore it cannot be misinterpreted.

If you have ever worked in physics (Electromagnetics) then this notation isn't too hard to understand, otherwise it may take a little while to get use to.

-Michael Ohene

[Dan_Lehman]

[THIS TOPIC SHOULD BE UNDER "KNOT THEORY & COMPUTING".]

Prior to tackling the pdf file,
I have quite a problem finding a Clove H. in the indicated code
"Clove Hitch: LixRoxi1Loxo-1" !?

Firstly, to my mind, L is a lateral, visual planar move, and x/o
traverse that plane.  Secondly, I'd like to have some *base*
for starting--"L" could be headed anywhere (on the plane,
to my mind), but is left unspecified (which might be fine
as general guidance, but makes me pause at the start).
But, seeing "Lix" as e.g. going say up (that lack of base)
and a bit leftwards, then away from me and back around
some (x) object (though I might be getting more out of
"x" than is strictly spec'd!), and then brought up (o) and
R-wards over my start --but wait:  there's no indication
of crossing priority:  over/under!?  And this absence sees
further issue with the finish of the knot, as the end must
come around and not cross back over the starting end
but under the Clove's crossbar part.

 

[Michael Ohene]

[THIS TOPIC SHOULD BE UNDER "KNOT THEORY & COMPUTING".]

Prior to tackling the pdf file,
I have quite a problem finding a Clove H. in the indicated code
"Clove Hitch: LixRoxi1Loxo-1" !?

Base: The starting position can be thought of as vertical, with the standing end hanging down (-z direction), with the rope in front of the object Or as an axis -90 perpendicular to that (standing end in the -x direction). In other words, the z axis always points to 90 or 0 degrees.

The beauty and confusion can be seen in the clove hitch example. If you were to interpret the L_ix notation as start under the object moving away from you, then move up, the remaining moves would not make sense. I have to think about this...you wouldn't be able to complete the last tuck move going left because there would be nothing to tuck under.

This is what needs to be worked out. This notation is sometimes implicit, it sometimes leaves two options, only one of which will actually make sense (will not undo a previous move). Notation combinations will imply which option is correct. For example, in the granny knot ABoK #80 R_ixoxo1, the moves  _oxo1 would not make sense, in fact they will never make sense if you started from the top of the object.

So, is there confusion? Yes. But from my knowledge it can all be identified and clarified as in the granny knot example.

You are right with your moves, the running end moves up and around the object with a left offset.

there's no indication of crossing priority:  over/under!?

R_oxi1: The pdf lists the meaning of R_oxi1 as coming out at you around an object with a right offset, then under the first section (the standing end)

L_oxo-1: You are right, this should be R_ixL_oxi-1
Note: the last move L_oxi-1 comes out at you with a left offset and tucks under the previous section.
 
So the clove hitch should be: L_ixR_oxi1ixL_oxi-1
Hopefully this clears things up.

[TheTreeSpyder]

i've all ways thought, that we should have a notation of common knot lacings, that build other knots.  the notation should be based on mechanics of these 'machines', not the more visual form of the lacing.

i think a simple Hitch is where the Standing crosses over and nips the Bitter; but if the same arraingemeant were pulled backwierds, it is like a frictioned slip/Crossed Turn(?), in that the empowered Standing now is under/ not nipped by the Bitter over it.  So, to a lacing definition, both might be viewed as same, but mechanically, and thus in play, the 2 are not the same. To me the mechaincal understanding rules, and leads to higher things-at least in working class knot lacings IMLHO.

To this definition, a Clove would be of 2 parts, the pulled/Standing/empowered end of the Clove would be more of a Crossed Turn with Standing/empowered under the subsequent crossing, but the 2nd Turn configuration would be a nipped Hitch, for the Standing for that part of the lacing is over the subsequent Bitter at the crossing of that part of the lacing (taken as a whole unto itself for this exam eye nation).

[Michael Ohene]

i've all ways thought, that we should have a notation of common knot lacings, that build other knots.  the notation should be based on mechanics of these 'machines', not the more visual form of the lacing.

In other words, it sounds like you would prefer a functional as opposed to a visual definition of knots. That would be similar to something like a patent definition where everything is defined in terms of function. I will differ and say if the notation is correctly defined - as I hope it is currently - it should be possible to determine the function. This should be similar to perhaps computer programming where a limited number of commands can imply one overall function. Practically, Fink and Mao have show that they can classify 'machines' or functions (all possible tie knots) based off notation. Therefore, I am working off the assumption that a related notation can be extended to define other functions (hitches, bends, etc.) based on notation patterns.

I am not sure if I understand the rest of your reply, but just to summarize:
i) all knots will have a unique notation.
ii) a knot tyer can correctly tie a knot based off the notation
iii) a complicated knot should take about 1 to 2 minutes to tie working off the notation
iv) coming up with a notation for an observed knot might take 4 to 6 minutes

Michael Ohene

[rsilvers]

Would you be able to define a Rosenthal loop knot in this notation? And then could someone write a computer program to animate the knot from the notation?

[Michael Ohene]

Zeppelin Bend: L _i1,1R_o1,2 S_o1 : L_o2,2 S_i1 S_i2
aka the Rosenthal Bend

The notation is as follows "rope one:rope two"
subscript _1,2 means "rope 1 acting on rope 2"
S_o1 before the colon means "running end of the first rope penetrates the first loop of the first rope" and is simply a short hand notation for S_o1,1

Can the notation be used for automation? Good Question. Yes the only problem I would see would be the fact that sometimes you have to consider the previous move in order to understand how to interpret the current move, but this should be no big problem to resolve. In engineering this is still considered causal and thus it can still be implemented.

I have never done graphical programming so this alludes me, but I can see what other people are doing so I can try to implement this without recreating the wheel.

I have been lagging of late, so I think my next step will be to complete notation for all knots contained in Ashley's Book of Knots (ABoK) - although the fancy knots may be a bit tricky

I do admit I have to work out the references:
For example, when you are switching ropes in the Rosenthal/Zeppelin Bend, the reference should be "looking up and away from the standing end" in fact, I believe that this is always the reference to be used.

[rsilvers]

I think a good test for the notation would be if a computer could interpret it. I would test it on 50 knots before doing all of the ABOK because you may end up adding to the notation if you learn that a computer cannot follow the notation as it exists now.

[Michael Ohene]

Very good point about computer testing 

[DaveRoot]

Can the notation be used for automation? Good Question. Yes the only problem I would see would be the fact that sometimes you have to consider the previous move in order to understand how to interpret the current move, but this should be no big problem to resolve. In engineering this is still considered causal and thus it can still be implemented.

I have never done graphical programming so this alludes me, but I can see what other people are doing so I can try to implement this without recreating the wheel.

Thoughts on automating the graphics based on your knot notation:

1. Try viewing some knots in KnotTyer3D (http://www.stevenabbott.co.uk/Knots/knottyer3d.html), and use its built-in editor to learn its knot notation.  If you can figure out a sequence of steps to convert your knot notation to the KnotTyer3D notation, then a program can probably be written which uses KnotTyer3D to display knots in 3D based on your knot notation (see point #2).  KnotTyer3D is point-based, meaning that it graphically connects a series of points.

2. Another graphical knot program is KnotMaker (http://www.Layhands.com/KnotMaker), which Derek Smith and I wrote.  KnotMaker is tile-based, meaning that the user draws a knot by placing pre-defined 2D tiles onto a drawing grid.  If you can figure out a sequence of steps to convert your knot notation into the proper set of KnotMaker tiles, then I can probably modify KnotMaker to display knots based on your knot notation.  Within KnotMaker you can also pop up KnotTyer3D to display knots in 3D, so KnotMaker can be a user-interface to convert your knot notation for either of the drawing programs (if you can figure out the appropriate conversion steps).  Edit: The attached KnotMakerTiles.jpg file shows all of the pre-defined KnotMaker tiles and their tile numbers, in case you want to make an attempt to figure out how to convert your notation to the appropiate KnotMaker tiles.

3. One thing to consider is that users won't be able to type in any subscripts when they enter your knot notation into a program's text box.


Let us know what you come up with!

Dave

[TheTreeSpyder]

i figure that can be done, great work on knot tyer!

In my mind, especially with working class 1 or 2 line situations; there are a rather finite set of positions ther lines can take.  While the formulaes shown will cover all that, it seems to me that it is viewing something at atomic level that we could do just as well - perhaps  better to look at a more molecule level- or binding together of common steps from a micro commands to more of a 'macro' sets of repeating commands/positions to view and understand.  For, to me it is about the same, these mechanix are giving commands to the knot machine, just as it would to a computer.

In short i think if you wrote enough knot definitions on paper or for computer, you'd in time find these redundant patterns that would probably evolve to become macros(?)/blocks of several steps.  If taken at key points, i think these would end up being the very mechanix that define not only the lacings, but their mechanix as well(?).

[Michael Ohene]

I am working on trying to integrate the notation with the knot tying computer programs. The first step is making sure my notation is consistent. Specifically, defining when loops and sections are formed when tying knots.

I don't think it should take more than 3 weeks to make sure the notation is coherent.

Michael Ohene

[Michael Ohene]

1. Try viewing some knots in KnotTyer3D

I couldn't get this program to download. I think the link may be broken.

2. Another graphical knot program is KnotMaker The attached KnotMakerTiles.jpg file shows all of the pre-defined KnotMaker tiles and their tile numbers, in case you want to make an attempt to figure out how to convert your notation to the appropiate KnotMaker tiles.

I need help interpretting your tile graphic. For instance, the lines of move 31 seems to come out of the middle of 30, and the 31,30,32,33 moves almost look like a cluster (combination) of moves. Are 31 and 30 supposed to be independent moves?

I assume moves 55 and 56 are independent and are only combined to show the most frequent combination in which they are used.  Is this correct?

Michael

[DaveRoot]

In the tile graphic, each numbered tile is in a single square of the drawing grid.  This is easier to see if you look at the top two rows. 

Some of the tiles contain diagonal lines (e.g. 30, 31, 32, 33), and those tiles extend beyond the boundaries of their individual grid cells (because otherwise the diagonal lines won't meet up with the diagonal lines in an adjacent tile).  Unfortunately, this obscures the grid lines, which makes the tile graphic a bit confusing.  But if you look at the top two rows and see how big each grid cell is, then it's not too difficult to distinguish each individual tile.  In most cases, the tile number is approximately in the center of the tile, which helps to distinguish each individual tile.

Did that help?

Dave

[Michael Ohene]

Yeah, I see, it's just unintended overlapping. Gotcha.

I have been working on the notation interpreter for KnotMaker 1.2 and conceptually it is not that hard, it is just the fact that there is more than one graphical representation for a knot but only one notation. The implication being, if the KnotMaker program can read the knot notation, which graphical representation will it draw? The most compact, a knot representation based on user preferences, etc? This project will just take lots of scratch paper and maybe a month longer than I expected to complete.

July 11th, 2009
Wow, I just discovered I will have to dabble in knot theory to get this project done. The user interface should remain simple, but the underpinnings will be a little more complex than I expected.

July 23rd, 2009
I have been working on another project for the past two weeks. It has consumed me, but I think I should finish my other project this weekend leaving me time to resume work on the knot problem this coming Monday.

August 12th, 2009
I have finally started the knot notation project. I can say for sure that it take me at very least 3 weeks to finish the first version. That is 3 weeks working day and night.

August 24th, 2009
The draft of the conversion from my knot notation to the KnotMaker tiles is taking shape. I have been goofing off a little, but it seems I have a firm grasp on the notation/KnotMaker software incorporation. At soonest, the logic/draft/pseudocode should be done by this weekend. To have the program code written may take at least a month I am also working out quirks of my notation along the way.

September 24, 2009
I have begun programming. This should be done before the end of the year, no more slackin off for me!

March 7th, 2010
I took a break for a few months but I am back and working on this project.
Okay I, this was harder than I thought, I am 3/4ths done with the pseudocode then I need to write the program and test. I am thinking of writing things in C++. The goal right now is confined mainly to generating the equations for the line segments and the points and orientation of intersection. No more promises about the completion date of this project, it will take a while. What I am doing is essentially basic graphics programming. Eventually I want my loops modeled as circles to be modeled by Bezier Curves in OpenGL, but I am ahead of myself.

July 15th, 2010
After 2000-3000 lines of code, I am in the debugging stage. After debugging (this week) I can begin testing. The program is written in C.

cheers,
-Michael