[metapost] MetaFont: Unexpected behavior of intersections times

[Nicola]

In article <BANLkTi=rfM4mAY-1XD7JgoC-exeFh80kpA at mail.gmail.com>,
 luigi scarso <luigi.scarso at gmail.com> wrote:

> The following metafont code
> 
> %%%%%%%%%
> batchmode;
> message "p1:=(33.09007380767,-33.8895224139) .. controls
> (33.370612519531,-33.905534970703) and (33.65115125,-33.9215475) ..
> (33.93169,-33.93756);";
> path p[];
> p1:=(33.09007380767,-33.8895224139) .. controls
> (33.370612519531,-33.905534970703) and (33.65115125,-33.9215475) ..
> (33.93169,-33.93756);
> 
> p2:=(38.1058,-34.00049) .. controls (36.39993,-34.00049) and
> (34.44913,-34.0004125) .. (32.79190125,-33.86743875);
> numeric t,u; (t,u) = p1 intersectiontimes p2;
> show t,u;
> message "" ;
> 
> 
> message "p1:=(33.09007380767,-33.8895224139);";
> p1:=(33.09007380767,-33.8895224139) ;
> p2:=(38.1058,-34.00049) .. controls (36.39993,-34.00049) and
> (34.44913,-34.0004125) .. (32.79190125,-33.86743875);
> numeric t,u; (t,u) = p1 intersectiontimes p2;
> show t,u;
> message "" ;
> 
> message "p1:=(33.93169,-33.93756);";
> p1:=(33.93169,-33.93756);
> p2:=(38.1058,-34.00049) .. controls (36.39993,-34.00049) and
> (34.44913,-34.0004125) .. (32.79190125,-33.86743875);
> numeric t,u; (t,u) = p1 intersectiontimes p2;
> show t,u;
> message "" ;
> 
> bye.
> %%%%%%%%%
> gives as output
> 
> This is METAFONT, Version 2.718281 (TeX Live 2009/Debian) (base=mf
> 2011.1.30)  2 APR 2011 13:33
> **a
> (a.mf
> p1:=(33.09007380767,-33.8895224139) .. controls 
> (33.370612519531,-33.9055349707
> 03) and (33.65115125,-33.9215475) .. (33.93169,-33.93756);
> >> -1
> >> -1
> p1:=(33.09007380767,-33.8895224139);
> >> 0
> >> 0.94043
> p1:=(33.93169,-33.93756);
> >> -1
> >> -1
>  )
> 
> Is it corrected ?
> Given that p1 is inside p2, perhaps in this case intersectiontimes
> correctly doesn't find any  intersection --- there are infinite
> intersections. But I'm a bit surprised .

Rounding errors? Intersectiontimes can deal with multiple intersections, but 
MetaFont certainly cannot deal with quantities at that precision. Besides, 
intersectiontimes might become numerically unstable when paths are nearly 
parallel (but since I do not know the algorithm precisely I'm just guessing).

Nicola