[metapost] arclength() tolerances

[Franck Pastor]

Le 3 avr. 2014 à 10:32, Taco Hoekwater <taco at elvenkind.com> a écrit :

> Hi Hartmut,
> 
> On 02 Apr 2014, at 21:10, Hartmut Henkel <hartmut_henkel at gmx.de> wrote:
> 
>> Hi,
>> 
>> in metapost there seem to be absolute tolerance values for iterative
>> algorithms like arclength() even in the double numbersystem:
> 
> Yes, the arc_test() routine (the core or arclength/arctime) uses a predefined 
> tolerance of unity/4096. While it is clear to me why it needs a tolerance
> setting, it is not clear why that precise value, nor does lowering it actually
> help, it just makes mp run slower:
> 
> With tolerance=1E-8:
> 
> 0.031477030364784685, 31415.995269569834
> real	0m1.606s
> user	0m1.601s
> sys	0m0.003s
> 
> With tolerance=1E-9:
> 
> 0.031477030364784685, 31415.995269569834
> 
> real	1m40.888s
> user	1m40.820s
> sys	0m0.034s
> 
> Maybe there is some intrinsic error in the approximation code? One of the
> more important reasons why I will quit developing metapost is that I do not 
> really understand any of this computational stuff, nor can I easily grasp the
> theory behind it when attempting to educate myself.
> 
> Best wishes,
> Taco

About arclength, I remembered having read something about it somewhere, but couldn't find it until just now. It was in a TUG article written by the Asymptote authors: http://www.math.ualberta.ca/~bowman/publications/asyTUG.pdf

p. 289: "Robust arc length and arc time computations were implemented with adaptive Simpson integration, which was determined to be more efficient than Bézier subdivision."

Maybe the Simpson integration should be the way to go? (Don't know enough about this subject to judge about it.)

Best regards,

Franck Pastor