[Pyx-user] path parametrization

 [Pyx-user] path parametrization From: Andre Wobst - 2004-05-03 06:22:17 ```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. CON: 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. CON: 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. Since pyx-devel kept silent after my posting last week, I'm now asking our users. 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/ ```

 [Pyx-user] path parametrization From: Andre Wobst - 2004-05-03 06:22:17 ```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. CON: 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. CON: 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. Since pyx-devel kept silent after my posting last week, I'm now asking our users. 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/ ```
 Re: [Pyx-user] path parametrization From: Gert Ingold - 2004-05-03 12:17:59 ```Dear Andre, I do not have a clear opinion about which solution is the best (although I tend to agree with whatever Jörg's opinion is ;-) But let me make a couple of remarks which may be helpful in coming to a decision. - There might be situations where defining a point by means of a path length outside the allowed interval could come handy. On the other hand, such situations could be handled differently. - Close to the starting and end point, a kind of snapping might be useful to avoid spurious results. - These two situations could be distinguished by a snapping radius but probably this is not that simple to implement. - Probably one can live with the "snapping" solution but then a warning (not an exception!) would be nice which could help the user to under- stand the reason for a (possibly undesired) snapping. There are of course two sides to such warnings. Right now, PyX does not assist the ordinary user very much in the debugging process. On the other hand, too many warnings may not be desired either. A possible solution is to introduce a verbosity level. But this wouldn't help in making PyX faster, would it :-( Even though these remarks may not be too helpful, they might encourage other readers on the list to post their opinion. Best regards, Gert -- Gert-Ludwig Ingold | Institut fuer Physik | email: Ingold@... Universitaet Augsburg | Phone: +49-821-598-3234 D-86135 Augsburg | Fax : +49-821-598-3222 Germany | WWW homepage: http://www.physik.uni-augsburg.de/theo1/ingold ```