[PyX-devel] normpath parametrization From: Andre Wobst - 2004-04-28 13:51 ```Hi, at the last PyX developer meeting we had a discussion about the parametrization of normpaths. First, let me briefly summarize the current status and the things, we've already decided: A normpath consists of a list of subnormpaths. Each subnormpath is either closed or not. A subnormpath consists of a list of normpathitems (in the current code you can find normpathel, but we decided to switch from -el to -item). There are only two kind of normpathitems, namely normline and normcurve. The line or curve of a normpathitem is parametrized by a parameter with range 0 to 1 (0 is the starting point of the normpathitem and 1 the end point). Each subnormpath has an epsilon, which is an accuracy (the length of the maximal deviation of certain operations). A normpathitem is not allowed to be shorter than epsilon. Thus you can convert an arc length of the subnormpath into a parameter and vice versa without numerical instabilities. The integer part of the parametrization of the subnormpath selects a normpathitem. The fractional part of the parametrization is the parameter within this normpathitem. In our old design, the parametrization of the normpath was build by summing the parametrizations of the subnormpaths. This leads to an uncontinuous behaviour when jumping from one subnormpath to the next (there was another epsilon involved here). We already decided, that we will use a tuple for this parametrization in the future. The first number of this tuple will be an integer selecting a subnormpath. The second number is the parameter for the selected subnormpath. Now there is a dispute on what to do with a parameter at the subnormpath when this parameter is out of bound. There are different possibilities. Let me tell you three of them, we have discussed, although only two are still in discussion (the other was rejected by the developers): 1) We could raise an error, when the parameter is outside the valid range. But we immediately step into a problem: we would need another epsilon, which allows for small exceedings of the parameter range (to gain stabilitly). Note, that this is a different epsilon than the accuracy of a subnormpath mentioned above, since increasing the accuracy (lowering the epsilon of the subnormpath) should not automatically tighten the allowed parameter range exceedings. Thus the developers have already rejected this solution. 2) We could cut the parameter to the allowed parameter range. Using a parameter outside of the allowed parameter range to the left or to the right would lead to the starting or end point, respectively. PRO: You won't step out of the path. CONTRA: You parametrize the start and end point of the path, although the parameter might be far out of bounds. 3) We could ignore range exceedings completely. A parameter outside of the allowed parameter range will usually give you a point not at the path. PRO: A invalid parameter results in a point outside of the path. CONTRA: It does it without any warning. I'm not telling you, which version is favoured by which developer, but we all would like to see any kind of comments to this issue. Thanks for reading ... André -- by _ _ _ Dr. André Wobst / \ \ / ) wobsta@..., http://www.wobsta.de/ / _ \ \/\/ / PyX - High quality PostScript figures with Python & TeX (_/ \_)_/\_/ visit http://pyx.sourceforge.net/ ```