siddhartha-gadgil on master
helpers for timing (compare)
siddhartha-gadgil on master
"require" correction slight refactoring (compare)
siddhartha-gadgil on master
helpers for curves being pants … (compare)
siddhartha-gadgil on master
figures for pants length 2 (compare)
siddhartha-gadgil on master
reduced laziness to run in REPL (compare)
siddhartha-gadgil on master
segment lengths 1 and 2 bound (compare)
siddhartha-gadgil on master
parallel normal path enumeration (compare)
siddhartha-gadgil on master
margulis constant corrected (compare)
siddhartha-gadgil on master
Updates to function shortPathsD… Merge pull request #98 from sha… (compare)
siddhartha-gadgil on master
introducing compact types More compact types Merge pull request #97 from sha… (compare)
siddhartha-gadgil on master
speedup by memoizing hash (compare)
I do not remember what I wote. But some things to try are:
By the way, @Chinmaya-Kausik please address me here by my Gitter handle to maximize the chance I am alerted.
Copying the above with double dollars.
I do not remember what I wote. But some things to try are:
By the way, @Chinmaya-Kausik please address me here by my Gitter handle to maximize the chance I am alerted.
I do remember explaining my method (since there was no explicit algorithm in the paper and the algorithm in the paper referenced seemed a bit involved), but I'm not sure if its correctness was discussed at all.
the algorithm in the other paper referenced*
What we expect, I will work out and add soon.
Okay, I think I've double checked and the issue seems to hold, so we should not expect any answer from this algorithm. There is a much more involved algorithm in a paper by Lazarus and Rivaud, but I never tried to read it.
LazyList
of iterations.
However, you seem to suggest that the wrong answer is returned, which will not happen in an infinite loop unless @anotherArka put a safeguard for this situation which halts and gives an error or wrong answer.
It turns out that I coded in this algorithm and I actually just make it terminate after loopLength + 2 iterations.
@Chinmaya-Kausik Are you saying that we get into an infinite loop when we try to make things canonical?
When attempting to do this by hand, that is what seems to happen, yes.
If this is the case, we should check the paper if canonical as paths is enough.
I'll take a look
And making it canonical at basepoint causes the whole process to loop.
Yes, that's exactly what seems to happen here.
To clarify - there are only two (adjacent) edges and two vertices and a right turn on the basepoint is a left turn on the other vertex and a left on the basepoint is a right on the other vertex.
That is a good example - simple enough that one can see what is happening. The only question is whether intersection numbers are correct when we take canonical as paths
I checked Erickson and Whittlesey's definition of canonical forms - they seem to require that the cyclic sequence of turns is canonical, so that the curve is canonical as a loop.
What if in the cases where canonicising does not end, we create a list of loops it generates and stop when it generates one loop twice. Then take the intersection number between all such possible pairs of loops then take the minimum of them. Will it be same as the GIN?
Yes, such details I'm not sure of - I don't know if the proofs themselves allow for things to work out. Also, a bigger issue is that the algorithm they describe sounds very similar to ours (to me it seems that it's merely a different way of organizing what we are doing), and they seem to claim that it works.