[metapost] turning number -- the neverending story?

Boguslaw Jackowski B_Jackowski at GUST.org.pl
Tue Jan 10 11:07:43 CET 2012


DL> The algorithm discussed on this list (and which I think is the
DL> one used by current MP) is different from the one originally
DL> used in MP, and that one is different from the one used by MF.

Is this algorithm described somewhere in details?

DL> Far more important to me is the polygonal pen problem.
DL> Since the polygonal code has bugs, so did winding number.

I believed that the code for polygonal pens has been already
thoroughly debugged. Isn't that true? (Initially, it contained
terrible errors that were able to hang MP).

Incidentally, the behavior I reported a few years ago, still manifests:

beginfig(100) draw (0,0)--(5cm,0) withpen pensquare scaled 3mm; endfig; % diagonal ends
beginfig(101) draw (0,0)--(5cm,0) withpen pencircle scaled 3mm; endfig; % vertical ends

Is it a documented feature?

BJ> Dan, are you able to sketch guidelines for handling singular cases?

DL> I can enumerate the singular cases and suggest default actions.
DL> Let me take some time and write up a descriptions of cases and
DL> the issues involved.

Marvelous! Thanks!

BJ> It seems to me that you have the subject carefully thought over.
BJ> Or, maybe, you know papers concerning this subject?
DL> Not yet, but I have been thinking about writing one.

Would be excellent -- I keep my fingers crossed for the
"accomplishment of the thinking about" :)

BJ>The only peculiarity of the path is that the precontrols and
BJ>postcontrols coincide (i.e., it is actually a so called b-spline).

DL> I doubt this peculiarity has anything to do with this problem.

BJ> Hmmm... Why, then, if you move randomly all nodes of the
BJ> curve from my example, e.g.,
BJ>    + (uniformdeviate 100, uniformdeviate 100) +
BJ> the turning number still remains equal to 0?

DL> I get always 0 also after changing the controls to
DL>   ..z2 and z2+(eps,eps)..
DL> This "proves" it is not the equality of controls that matters.

I proposed a misleading modification. Sorry.

In this case, moving nodes by

     (uniformdeviate 100, uniformdeviate 100)

may likely produce 8-shaped loops, so one can rightly
expect then the turning number equal to 0 -- sometimes;
but sometimes the result is -1.

Let me quote again the whole example, prudently modified:

%%%% FILE turnnum-err.mp
  if known mitered:
  save a,i,p,q; pair p; path q; p=right scaled 100; a=-90;

  i:=0; z0=origin;
  for f:=0, 1, 2, 2, -1, -1, 0, 0:
   i:=i+1; z[i]=z[i-1] +
    (uniformdeviate30, uniformdeviate30) +
    p rotated (f*a);

%  q:=z1 .. controls z2 and (z2+(epsilon,epsilon)) .. % turning number = -1
  q:=z1 .. controls z2 and (z2+0(epsilon,epsilon)) .. % turning number = 0
  z3 .. controls z4 ..
  z5 .. controls z6 ..
  z7 .. controls z8 .. z1 & cycle;

  show turningnumber q;

  if known mitered:
   draw q;

%%%% END OF FILE turnnum-err.mp

The results seem to be stable.

Cheers -- Jacko

  Bogus\l{}aw Jackowski: B_Jackowski at GUST.ORG.PL
  Hofstadter's Law: It always takes longer than you expect, even
                    when you take into account Hofstadter's Law.

More information about the metapost mailing list