[metapost] (no subject)

Boguslaw Jackowski B_Jackowski at GUST.org.pl
Thu Jun 30 13:54:03 CEST 2011

> Still, I believe that estimating the distance of a point from a path
> is les "whimsical" operation than, say, computing the number of square
> roots of a quadratic.

> My point is that this is no different than turningnumber:
> estimating the distance to a path is not computationally
> any easier (or more robust or less whimsical) that estimating
> the "distance" from one direction to another. There are no
> puzzling cases except for paths where these are very close.

Perhaps a spoken discussion (supported by beer, or whiskey, or bourbon,
or mineral water ;) is needed. Are you going to visit Europe in the next 
year? Twentieth BachoTeX meeting may be a good occasion. :) (well,
I remember the unfortunate Larry's visit to Poland -- he was stopped
at the border because of some idiotic regulations...).

> Read back in the archives when we disussed path
> intersection. One of the examples included was path
> (call it P), which was a subpath of another (call
> it Q). Clearly P and intersect, but the
> intersetiontimes primitive said they did not,
> presumably because of the inherent problems of
> fixed precision computation.

> Reference please! This sort of thing alarms me.

I cannot fancy an example of not intersecting path
and its genuine subpath...

The only example that comes to my mind is something of kind:

path p,q,r;
p:=(0,0){up}..{down}(100,0); % just an arc
q:=subpath (2/5,3/5) of p;
r:=subpath (3/5,4/5) of p;
show q intersectiontimes r;
show point 1 of q;
show point 0 of r;

The log file reads:

This is METAFONT, Version 2.718281
>> (-1,-1)
>> (64.8003,47.99994)
>> (64.80087,47.99976) )

which, on the other hand, is not surprising.

> Don't understand... You'd need to _approximate_
> cubic path by quadratic ones which seems to be a rather
> cumbersome and complex task. Can it be done robustly?

> Remember always that every linear or quadratic
> bezier path is canonicly a cubic bezier path! No
> approximation is involved.

It is an elementary operation known as "degree elevation":
given a spline of n-th degree you can trivally express
it as a spline of (n+1)-th degree.

But what I do not understand is that we work with cubic splines, hence
the only way of simple "degree lowering" is differentiation.

> The winding number of the differetiated path
[with respect to the point (0,0)]
> (the quadratics) equals the _turningnumber_ of the original path
> (consisting of cubics) and Larry proposed that one might use the
> former to compute the latter.

I believe I'm blind or silly or I completely mistunderstand you both
(Dan and Larry) -- I cannot see the (simple) relation between cubic and 
its derivative quadratic ... Assume, for example, that we have
a square ABCD, and that its sides are approximated by "canonical"
cubic splines (represented in MF/MP by the "--" operator), which,
in this case, are just linear functions:
   A + (B-A)*t     for t in [0,1]
   B + (C-B)*(t-1) for t in [1,2]
   C + (D-C)*(t-2) for t in [2,3]
   D + (A-D)*(t-3) for t in [3,4]
Therefore, its derivative is:
   B-A  for t in (0,1) (observe that the intervals now are open)
   C-B  for t in (1,2)
   D-C  for t in (2,3)
   A-D  for t in (3,4)
so, the derivative of the original curve is constant
over the interior of the intervals and undefined at
their ends...

Of course, rotating from B-A to C-B to C-D to A-D yields
360 degrees. From what I understood reading MF sources,
the algorithm implemented in MF makes somehow use of
this property, am I right?

But I'm not able (at the moment) to express the property
in a mathematically precise form. Sorry for being obstinate --
as I explained, I'm practicing math too irregularly...

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