[PyX-devel] normpath parametrization

[Andre W. <wo...@us...>]

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
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/