[metapost] (no subject)
Boguslaw Jackowski
B_Jackowski at GUST.org.pl
Thu Jun 30 13:54:03 CEST 2011
Jacko:
> 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.
Dan:
> 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...).
Dan:
> 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.
Larry:
> 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;
end.
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.
Jacko:
> 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?
Larry:
> 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.
Dan:
> 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