Software that makes placemats

[jdaw1]

Any possibility of multiple roots between initial bounds (excluding duplicate root)? (I.e. can we either exclude the possibility of multiple roots being present, and If not then do we care? i.e. are all roots required, or any root). Could there be any bounding of the relative ratio of xTolerance to initial delta between upper and lower bounds?

n.b. I assume direct calculation would not be appropriate?

LowerX < UpperX; f(LowerX) × f(UpperX) ≤ 0. Any root that is between LowerX and UpperX, please.

n.b. I assume direct calculation would not be appropriate?

I thought about that, and decided that it would be too much grief.

[PhilW]

Could there be any bounding of the relative ratio of xTolerance to initial delta between upper and lower bounds?

(and if the implicit answer from your previous post is "no", then how is xTolerance defined/determined?)

[jdaw1]

how is xTolerance defined/determined?)

I know that x is in points, so xTolerance is defined to be 0.01. An answer that accurate is good enough for me.

[PhilW]

how is xTolerance defined/determined?)

I know that x is in points, so xTolerance is defined to be 0.01. An answer that accurate is good enough for me.

If a maximum paper size can also be assumed, perhaps no greater than 3.5m in one dimension should be more than sufficient, then this would presumably bound the upper limit to 10000 points, which with a tolerance of 0.01 gives a worst case ratio of tolerance to initial upper-lower of 1/1000000 or approx. 1/(2^20). To identify a 1 in 2^20 region, would then require 20 calculations of y using bisection, which then gives us an upper bound for the required computation.

Desiderata include robustness, speed, and simplicity of code

Interpolation is only worthwhile compared with bisection if division is sufficiently computationally efficient compared with the saving in additional multiplication/addition operations to calculate the additional bisection steps. At some point this trade-off may change. On a system where division is not fully accelerated in hardware, a division could be as computationally intense as say five bisections, in which case only one or two interpolations may be worthwhile before switching to subsequent bisections, for example.

Going back to your original formula; it is not in the form I would have intuitively expected, but is equivalent, and your arrangement maps well to define the restriction of movement of the estimation region boundaries. The computation is essentially equivalent to standard interpolation; Notably the division could also be avoided for the case where the interpolation is limited, since the tests:
-LowerY<=0.14*(UpperY-LowerY) OR -LowerY>=0.86*(UpperY-LowerY)
could be performed and the division only calculated if they were true.

The generalised formula as:
next x = LowerX + (UpperX”“LowerX) × Max[alpha, Min[(1-alpha), LowerY/(LowerY”“UpperY) ]]
does seem useful, where determination of suitable alpha for different applications is possible.

Seems like a good approach for this application provided division isn't too costly (in which case bisection wins). I would guess you could usefully select a slightly higher value than 1/7 (anything up to 1/4 potentially) which would speed some cases up and others down. Not sure where the optimum value would be, likely data dependent.

[jdaw1]

1/1000000 or approx. 1/(2^20).

PostScript uses single precision, with a 23-bit mantissa.

Seems like a good approach for this application provided division isn't too costly

(LowerX + UpperX) ÷ 2 still has s division. Maybe the hardware tests for and accelerates by-two division. Probably not.

Not sure where the optimum value would be, likely data dependent.

Constant, 1/7, determined by crude experiment in Excel.

[PhilW]

Seems like a good approach for this application provided division isn't too costly

(LowerX + UpperX) ÷ 2 still has s division.

(LowerX + UpperX) * 0.5 does not have a division in floating point calculation and would be the expected implementation to reduce computation for that case;
(LowerX + UpperX) >> 1 would be similarly used for the integer case (though an integer /2 might well be compiler optimised to that shift).

[jdaw1]

n.b. I assume direct calculation would not be appropriate?

I thought about that, and decided that it would be too much grief.

Alas, it is required. Damn.

Have you recommended (pseudo)code that will convert c0!c4 to four roots?

[PhilW]

Have you recommended (pseudo)code that will convert c0!c4 to four roots?

No, sorry; I would use the formulae from there, and implement calculation of discriminant,p,q,S,Q,x (where c4..c0 are a..e and is only valid for non-zero a).

The only optimisations I can see would be potential detection of non-real solutions to allow you to ignore part of the calculation, but not much in the general case.

The fortran implementation here might help?

[jdaw1]

PostScript lacks complex types, and lacks derived types. Ick. I’ll try harder to avoid this.

[jdaw1]

/DiamondsPlus: done.


Best fitting of seven glasses on A4.

[djewesbury]

/DiamondsPlus: done.


Best fittin of seven glasses on A4.

Is the mathematician's solution always the drinker's?

[jdaw1]

Is the mathematician's solution always the drinker's?

We once had two sets of seven, Warre and Fonseca, and a room with space constraints. /DiamondsPlus would have helped.

However, it is less elegant than some other arrangements. So should be used only when needed only when packing seven onto A4 or US Letter = 8½″×11″, or ten onto US Legal 8½″×14″.

I thought it a mite harsh of you to add a spelling error to the quote of my correctly spelt words.

[djewesbury]

I thought it a mite harsh of you to add a spelling error to the quote of my correctly spelt words.

Oops! How did I manage that I wonder..
Your Warre/Fonseca placemats are things of beauty. How did the traced line connecting the glasses appear? And what is the correct way of including an external graphic (the makers' brands)?

[jdaw1]

Made by PhilW, not by me.

[djewesbury]

There appears to be a problem with /Array .
The example code in the manual:
[ /Array /Positions [0 2] [2 2 3 2] [4 2 3 2] [6 2] [0 1] [3 1] [6 1] [0 0] [3 0] [6 0] ] ,
when used in a test script, results in an automatic substitution of /TopRow for the intended pattern.
The same thing happens with other examples: /TopRow subsitution every time.
There appears to a be a syntactical error.
The code appears to use /PositionsStart, the manual /Positions .

[PhilW]

How did the traced line connecting the glasses appear?

These were my custom use of the feature "MakePathConnectingGlasses" within Julian's postscript.

And what is the correct way of including an external graphic (the makers' brands)?

This is not a standard feature. I took a couple of photographs, converted them to postscript format using an imaging program, and then cut/pasted their use with function prototypes into Julian's program, using an online postscript manual as a reference.

[djewesbury]

This is not a standard feature. I took a couple of photographs, converted them to postscript format using an imaging program, and then cut/pasted their use with function prototypes into Julian's program, using an online postscript manual as a reference.

Right... I can live without that for now then, given that I got a migraine trying to get the /Array packing style to work...

[jdaw1]

DJ: did the emails help? Please suggest words for the manual.

[jdaw1]

Desiderata include robustness, speed, and simplicity of code

Interpolation is only worthwhile compared with bisection if division is sufficiently computationally efficient compared with the saving in additional multiplication/addition operations to calculate the additional bisection steps. At some point this trade-off may change. On a system where division is not fully accelerated in hardware, a division could be as computationally intense as say five bisections, in which case only one or two interpolations may be worthwhile before switching to subsequent bisections, for example.

It has taken me a while to realise what this misses. The assumption is that computation of f[] is slow compared to the modest computation done by the calling routine. Calling f[] half as many times is assumed to be much much more important. So the extra division of interpolation is de minimus.

[jdaw1]

The code appears to use /PositionsStart, the manual /Positions .

Very sorry. Damn. Will be fixed today.

[djewesbury]

DJ: did the emails help? Please suggest words for the manual.

The code appears to use /PositionsStart, the manual /Positions .

Very sorry. Damn. Will be fixed today.

It's all working fantastically now. The manual only needs a clearer eg for the /Array syntax, perhaps a block of code with all parameters correctly expressed for the basic (x,y) function.

Emails were v helpful. Thanks!

[jdaw1]

The placemats, which only required 14 major drafts and several ".1.1.1" updates... I'm learning...

And one bug fix in the code , and one new feature. No trouble at all.

[jdaw1]

A note to self, following the 1966 Horizontal on Thu 27 June 2013: if RAYC is printing, he prints glasses sheets to card, and TN sheets to paper. So they should be separated, perhaps by

• /PageOrderingNonDecanterLabelGlasses {[ GlassesOnSheets length {-1} repeat ]} def

[RAYC]

Alternatively they can simply be printed to paper, if preferred. I marginally favour card, but the difference is very slight.

[jdaw1]

Broader question: what should be the default? That leads to a question about our behaviour.

What do we do when setting up a tasting?
1. Arrange glasses sheets on table, simultaneously putting TN sheets with the glasses sheets.
2. Arrange glasses sheets, and when that is all done, then put the TN sheets with the glasses sheets.
Yesterday we did the second.

If we do #1, the the ideal ordering is the current one:

• Person 1
  • Glasses
  • TNs
• Person 2
  • Glasses
  • TNs
• Person 3
  • Glasses
  • TNs
• Person 4
  • Glasses
  • TNs
• !

If we do #2, the ideal ordering is

• Glasses
  • Person 1
  • Person 2
  • Person 3
  • Person 4
  • !
• TNs
  • Person 1
  • Person 2
  • Person 3
  • Person 4
  • !

I’m half-preferring acknowledging that we tend to do the second behaviour, so should have the second arrangement. Thoughts?

(FYI, the programming effort is about zero the switch would be very easy to implement.)

[PhilW]

Broader question: what should be the default? That leads to a question about our behaviour.
...
I’m half-preferring acknowledging that we tend to do the second behaviour, so should have the second arrangement. Thoughts?

I think there is a good argument for at least facilitating the latter behaviour; If A3 printers were more common, I think we would more frequently be printing the glasses pages on A3 and then tasting note pages on A4 - in some ways this is equivalent to you scenario with card i.e. glasses printed on different paper (type vs size) than the tasting not pages. In this case it would be simpler (assuming possible) to specify the paper size for the glasses pages separately to the paper size for the rest, while still producing a single PDF with ordering as per #2; from this the glass pages and tasting note pages can then be more simply printed in two simple separate batches as pages 1..n and tasting notes as n+1..end rather than being interspersed.

However, the more common use is still likely to be A4-only, both due to lack of commonly available A3 printers and also convenience. In this case, I find that having the pages interspersed actually helps separating each persons set of pages while arranging positions at the table during setup. I would therefore suggest keeping this as the default behaviour, but add a simple switch at the start of the code, perhaps /PageOrderingAllGlassesFirst 0 which would allow someone to simply enable the non-interspersed ordering by setting to 1 if desired (I didn't immediately understand your proposed /PageOrderingNonDecanterLabelGlasses use, hence my alternate suggestion).

[jdaw1]

If the paper sizes are different then, currently, the software sorts by paper size in the outermost loop (well, unless over-ruled byPageOrdering!). All of which seems to be what you have requested.

Also PageOrderingNonDecanterLabelGlasses already exists, being used, for example, if a tasting is over multiple sessions. (See badly-written § of manual.)

[PhilW]

If the paper sizes are different then, currently, the software sorts by paper size in the outermost loop (well, unless over-ruled byPageOrdering!). All of which seems to be what you have requested.

Also PageOrderingNonDecanterLabelGlasses already exists, being used, for example, if a tasting is over multiple sessions. (See badly-written § of manual.)

ok; in which case my response is simplified to suggesting provision of the option for #1 or #2 controlled by a simply named user controllable parameter, and expressing a (minor) preference for #2 (as current) as the default.

[jdaw1]

I prefer the alternative. I just find it easier to have all of the placemats together and all of the TN sheets together.

[PhilW]

I prefer the alternative. I just find it easier to have all of the placemats together and all of the TN sheets together.

We have a difference of opinion; neither unusual nor problematic.

suggesting provision of the option for #1 or #2 controlled by a simply named user controllable parameter

Whichever method is determined as default, can we please have a simple clear parameter to allow straightforward selection of the other method for if/when preferred?

[jdaw1]

Whichever method is determined as default, can we please have a simple clear parameter to allow straightforward selection of the other method for if/when preferred?

There are parameters giving quite detailed control over the page order. Generally, for one-session tastings, the default is good. That starts with the page types that have page-ordering 1: glasses, TNs, vote recorders; the cork displays; and the pre-pours. These are sorted by paper size. Then glasses and TNs, sorted by NameNum (i.e., by person), and within that, innermostly, Glasses sheets in order, then TNs in sheet order. Then the vote recorders; then the cork displays; and then the pre-pours.

Next, with default page ordering 100, the place names (coming late to facilitate early folding); then with default page-order 200 the decanter labels, which need cutting and gluing; then (300) the stocky labels, as even if the same paper size, they do need a change of printer supplies.

But everything is flexible. So changing the page-ordering for the non-decanter-label glasses, PageOrderingNonDecanterLabelGlasses (an array the same length as GlassesOnSheets) to have 0s rather than 1s would make non-decanter-label glasses appear before anything else.

(Note the slight interaction with the paper-size sorting. If the glasses and TNs have the same page-order, they interleave. But the cork displays, for example, don’t interleave.)

[PhilW]

The name PageOrderingNonDecanterLabelGlasses is either confusing, or I need to RTFM... "non-decanter-label glasses" as opposed to, presumably "decanter-label glasses"?

[jdaw1]

as opposed to, presumably "decanter-label glasses"?

Well, yes. The decanter-label sheets, are just glasses sheets, without painting the Circlearrays, nor the water boxes, nor other inapposite decoration. The decanter labels are a variant of the glasses pages, rather than being a fully different page type.

E.g., see the first and penultimate pages of the placemats used on 26th and 27th Dec 2007.

Edit: now you’ve mentioned it, I suppose that I could do some renaming of parameters and whatnot to ‘pretend’ that the page types are different. That wouldn’t be too painful.

[jdaw1]

Rays: algorithm help please

For Chris Doty’s most recent tasting in his ThirstyThirdThursdays series, I made the placemats. /Rays was deffed to true.

For the first go (well, the first of the goes relevant for these purposes), the parameter RaysLinesPerGlass was at its default value of 48, so one line every 360°÷48 = 7½°. 

To the right of glass ii this looks good. But between ii and v this is a dog’s breakfast, with two problems visible.
• There are too many long-ish straight lines connecting ii and v.
• There is also a tangle, with a straight line coming straight out of v and colliding with ii, naughtily crossing lines. Yuck.


So I tried /RaysLinesPerGlass 60 def, so one line every 360°÷60 = 6°. 

Much better, and this was the value used in the actual placemats.


Also, to feed the mind, here’s 72, one line every 360°÷72 = 5°. 

Bad.


And 96, one line every 360°÷96 = 3¾°.

Not as bad as some, but not right.


And finally 120, one line every 360°÷120 = 3°. 

This seems to work.

[jdaw1]

Any algorithm requiring such fiddling is a bad algorithm. To feed the mind, it works approximately as follows:

• Make a list of ends, so a list of length RaysLinesPerGlass × number of glasses on the page.

• Next make a list of intersections including all three types: 
— The ends have a start point and start direction. So for some pairs of ends on different glasses, they intersect.
— Also compute the first intersection between an ‘end’ and a circle;
— And between ‘end’ and edge.

• Sort list of intersections by distance (to edge or circle) or length (end to intersection to other end).

• Go down this list, starting at the shortest. For the shortest intersection with both ends unpainted, paint, and mark ends as painted.

• Painting is a straight line to circle or edge; or a cubic Bézier, the ends being the ends, both middle controls being the intersection.


This doesn’t work. For two touching circles, lines might intersect, or might touch the other circle before intersecting. And there can be a spare end, that in seeking a partner crosses other lines.

So this entire algorithm is to be discarded. Please suggest better. What is wanted is an algorithm that works in the general cases, rather than in a hodgepodge sub-set of those.

[jdaw1]

An obvious improvement is to stop worrying about intersections. Two near-arbitrary ends can be connected. E.g., compute dist = distance between ends. Then the bézier’s middle two control points can be dist÷2 away from the two ends, travelling the obvious direction away from the circle. 

But, in the general case, distance is the wrong way to choose what to connect to what. E.g., see the following very small example with just two circles, each of which has two lines coming out, and the page being edgelessly infinite.

Using distance to choose what connects would cause red to be connected to red, forcing green to cross.

[PhilW]

Any algorithm requiring such fiddling is a bad algorithm.

My gut (not Dow 66) suggests that specification that for your current algorithm, using any of the diamond packing styles, RaysLinesPerGlass must be a multiple of 60 to ensure no problem.

I would attempt to re-state your problem as being to: find a solution (for the general case) for any number of circles in any position, to connect RaysLinesPerGlass points on each circle to any other point (except on one on it's own circle?) by a path without any path crossing another path and without traversing the inside of any circle, and then (optionally) allowing line deviation/spacing for space-filling is highly complex.

[jdaw1]

My gut (not Dow 66) suggests that specification that for your current algorithm, using any of the diamond packing styles, RaysLinesPerGlass must be a multiple of 60 to ensure no problem.

For every possible aspect ratio? Really?

highly complex.

Not the answer I really wanted. That is, not the answer that I wanted to be true.

[PhilW]

But, in the general case, distance is the wrong way to choose what to connect to what.

Agreed, though it seems a reasonable initial starting point. On selecting all subsequent lines, you could (theoretically) perform validation checks, such as to ensure that for any new enclosed areas formed bounded in part by the new line, that the total number of points enclosed by the existing lines and the new line are (a) even and (b) no more than 50% of those points are on any one circle; but this would seem to be becoming over-complex.

[jdaw1]

Thank you. Being forced to describe the problem helped a lot, as did the subsequent discussion. I now have an algorithm explanation to follow later.

[jdaw1]

The new algorithm works as follows.

• Create an array of ends of rays, of length NumRayEnds. This array is to hold multiple fields, including X and Y (start point), dX and dY (start direction), Angle (also start direction), and the glass number from which originating. Another field is an array of distances to other ray ends, each of which is of length NumRayEnds.

• Populate the distances, being a task O(n²). The definition of distance is slightly intricate. Compute the distance from start to start as the crow flies. The knot points will be half this crow distance from each end, of course in the direction implied by the relevant dX and dY. The ‘distance’ is deemed to be the sum of the distances between the knot points (the interesting bit of which is the central section, between the two interior know points).

• Create another field, sorted distances, pointing to the former array. (So for ray end i, let the first element of the sorted array be j, then the closest array end to i is j.)

• If i is also the closest array end to j, mark this pair as to be painted. (It probably will be painted.) Mark both i and j as painted, and repeat searching for new i and j that are the closest unpainted ends to each other.

• Repeat search till exhausted.

• It might be that j is closed to i, k closest to j, and i closest to k. So repeat the above, with a tolerance: if j closest to i, and i within Tolerance of being closest to j, repeat painting trick.

• Double tolerance, repeat. Repeat.

• Various i-j lines have been marked to be painted. That can still have intersections.


• So take all the lines connecting circles ii and v (WLOG). Compute the angles measured from the line connecting the centres of the circles; cut all the lines; separately sort the two lists of angles; re-connect. That detangles the two-circle problems.


So the earlier problem of lines not intersecting has gone. And some of the tangled lines have been de-tangled particularly those of the form shown in the small counter-example above, repeated below.

But that hasn’t eliminated all possible problems with tangling.

[PhilW]

Clarification needed on bullets 2/3/4 please (first half of 2 is fine; second half of two, and subsequent/consequent actions in 3/4 not understood).

In no way attempting to derail the current new method, I did have some further thoughts on possible alternate method; not fully formed, but elaborated below in case it includes/provokes any further useful ideas. Possible method:
(1) Consider the C circles as points (centre locations only) initially, with N points per circle required.
(2) Conceptually, fully interconnect all points directly, allowing page-edge wrapping.
(3) For each circle-circle connection, consider whether use of circles rather than points would mean there were no path between the circles; if so, remove that link. This would conceptually leave a partially direct connected map, with each circle likely to have at least three, but likely more connections. These are effectively a list of the non-crossing paths available, so now we have to simply define the "width" of those paths, i.e. the number of lines (roughly in parallel) joining the edges of each circle to another.
(4) For each circle, now assign a "width" to each line; this I haven't fully though through. An initial approach would be to start with the circle with the lowest number of circle-circle connections, and evenly assign N/num_connects to each one. Then iterate for each other circle with lowest number of currently undefined widths, until all are assigned.
(5) Now create circles with points. Connect first shortest path, and then assign all other connections based on widths rotationally. Repeat for all other circles.

Am not sure whether that is clear enough without either a lot more explanation or some pictures which I don't have time for right now; decided to post anyway in case provokes thought.

[jdaw1]

Clarification needed on bullets 2/3/4 please (first half of 2 is fine; second half of two, and subsequent/consequent actions in 3/4 not understood).

 

• Populate the distances, being a task O(n²). The definition of distance is slightly intricate. Compute the distance from start to start as the crow flies. The knot points will be half this crow distance from each end, of course in the direction implied by the relevant dX and dY. The ‘distance’ is deemed to be the sum of the distances between the knot points (the interesting bit of which is the central section, between the two interior know points).

The length of a cubic Bézier has no analytic form. And I don’t really care: what’s wanted is a sensible ranking. A cubic Bézier has four knot points, here labelled 0 1 2 3: the two ends, and two internal points. At knot 0 the direction of the curve is towards 1, and likewise at 3 towards 2.

So:
— Compute as-crow-flies 0-to-3.
— Knot point 1 must be directly away from the circle on which knot 0 sits. That specifies direction. Make the distance half the crow-flies distance.
— Likewise knot point 2 from 3.
— Deem distance to be sum of distances between knot points. Only 1-to-2 is non-trivial to calculate.

• Create another field, sorted distances, pointing to the former array. (So for ray end i, let the first element of the sorted array be j, then the closest array end to i is j.)

In effect we have a square grid of distances. Now create another array of arrays, called Sorted, and let’s consider Sorted(i). Populate this with 0, 1, 2, 3, !. Now sort it, such that Distance(i)(Sorted(i)(0)) ‰¤ Distance(i)(Sorted(i)(1)) ‰¤ Distance(i)(Sorted(i)(2)) ‰¤ !. So if j = Sorted(i)(0), then j is closest to i.

• If i is also the closest array end to j, mark this pair as to be painted. (It probably will be painted.) Mark both i and j as painted, and repeat searching for new i and j that are the closest unpainted ends to each other.

If the closest unpainted to i is j, and the closest unpainted to j is i, mark i”“j as to be painted (even if it might not be actually painted because of the later detangling).

[jdaw1]

(2) Conceptually, fully interconnect all points directly, allowing page-edge wrapping.

A port tasting on a torus?! Somebody, once, printed the placemats double-sided, but a torus is even sillier.

(1) Consider the C circles as points (centre locations only) initially, with N points per circle required.
!
(3) For each circle-circle connection, consider whether use of circles rather than points would mean there were no path between the circles; if so, remove that link. This would conceptually leave a partially direct connected map, with each circle likely to have at least three, but likely more connections. These are effectively a list of the non-crossing paths available, so now we have to simply define the "width" of those paths, i.e. the number of lines (roughly in parallel) joining the edges of each circle to another.

I’m having a complete failure of understanding.

(4) For each circle, now assign a "width" to each line; this I haven't fully though through. An initial approach would be to start with the circle with the lowest number of circle-circle connections, and evenly assign N/num_connects to each one. Then iterate for each other circle with lowest number of currently undefined widths, until all are assigned.

Are you estimating the lead eigenvector of the circle-connection matrix? Err, why? And is the edge one place or many?

(5) Now create circles with points. Connect first shortest path, and then assign all other connections based on widths rotationally. Repeat for all other circles.

Are the circles the glasses circles in which case I don’t understand or not in which case I still don’t understand?

[PhilW]

Thank you for the clarifications above; I now understand your proposed method. Ignore my suggested approach for now, until I have time to draw a few diagrams, or attend an offline and can wave my hands and/or draw on a napkin. Also, while what I am trying to propose would prevent tangling from occurring in the first place, if we can resolve tangling in your approach then mine is not required.

Going back to your description:

• It might be that j is closed to i, k closest to j, and i closest to k. So repeat the above, with a tolerance: if j closest to i, and i within Tolerance of being closest to j, repeat painting trick..

Is this possible, excepting the case of three equidistant locations?

• Various i-j lines have been marked to be painted. That can still have intersections.


• So take all the lines connecting circles ii and v (WLOG). Compute the angles measured from the line connecting the centres of the circles; cut all the lines; separately sort the two lists of angles; re-connect. That detangles the two-circle problems.


So the earlier problem of lines not intersecting has gone. And some of the tangled lines have been de-tangled particularly those of the form shown in the small counter-example above, repeated below.

But that hasn’t eliminated all possible problems with tangling.

I think your approach can be extended to perform the rest of the detangling:
(a) Determine initial list of all lines to be painted as per your method
(b) For each pair of circles in turn, consider every pair of lines which both have one end on each of these circles:
- Determine if the lines cross, and if so then perform detangle
(c) Now, for the whole page, consider every pair of lines in turn
- Determine whether the pair of lines crosses; if so, perform detangle on that pair
(d) If any detangling was performed, repeat (c) until done with no detangling required

Two additional notes on the above:
(i) To determine if the lines are tangled (in the full page case, where the lines are not connected to the same pair of circles at both ends) it will be necessary to account for quartic use in the path; using direct lines from end-knot-knot-end might be sufficient.
(ii) When detangling, if the two lines under consideration both have one end on the same circle, it is then the other points which must be swapped, irrespective of distance; otherwise after disconnection the reconnection should be based on nearest pair of free ends first.

[jdaw1]

I have just realised how to generate interesting and varied misbehaviours: /Arch, and /PostsAndLintel. Examples below, /Arch on left, /PostsAndLintel on right.

[jdaw1]

A few posts back, in summarising the algorithm, I omitted to mention that after painting all curves, remaining unpainted ends are drawn to the edge because I thought they’d be in the corner.

Also, the testing whether curves intersect circles is showing an occasional imperfection. The code tests at t = 0.01, â…›, ¼, â…œ, ½, ⅝, ¾, â…ž, and 0.99. Perhaps the sixteenths could be added, which would be easy. The alternative is, for each curve, for each circle, if the bounding boxes of circle and knot points overlap, take the hexic polynomial of distance squared, differentiate once, solve that quintic numerically for 0 < t < 1, and substitute back in to the hexic.

[jdaw1]

Some minor fixes implemented. Some bigger problems remain. These examples shown with RaysLinesToPaperEdge being true, and the margin marked with a grey box.

[jdaw1]

Blank post so images appear at start of page.

[jdaw1]

Blank post so images appear at start of page.