Reparameterize section

[fryguybob]

This is a minimal way to fix #217, putting this here for discussion.

[bergey]

Makes sense to me. Maybe it's worth a Haddock comment explaining the relationship between the parameters before & after splitting? Maybe on the instance for Trail' Line?

[fryguybob]

I'm putting this here as it is convenient at the moment and it may be a while before I can come back to this and I don't want to forget the points. I'm not convinced of the points I'm making here either, but I think I need to talk out loud about them.

Some choices that we could make for parameterization are to have bounds outside of [0,1], bounds always exactly [0,1], and/or parameters linearly related to distance along the curve. While the last property is nice and useful for the user, I would argue that we need to have parameterizations that match the "native" form for each sort of segment. These are not so much for the user as they are for the algorithm designer. It would be devastating to performance and accuracy if you had to do the sort of things that we do to approximate length along the curve for all the kinds of parametric things we want to do with trails. Given that we need this native view of our segments, we should optimize for use in algorithms. This is where I lean toward having the [0,1] bounds. Otherwise, you are constantly reaching for the lower and upper bound functions to adjust the step of the algorithm rather than just working with a normalized subcurve. But normalizing is throwing away some information in this case.

     0   1   2   3
   |...|...|...|...|   <- four segments

   |...|...|.|  *snip*  |.|...|  <- three segments and two segments
     a   b  c            d  e

If you have four segments and you split in the middle of segment 2, then the first side of that split is reparameterized to [0,1]. Segment c takes up one third of the new parameter space while in the original parameter space took up one eighth of the whole space. That means an even distribution of samples along the parameter space will focus on this shorter segment much more. As we subdivide more and more we could end up with some parts at the ends that accumulate a rather large share of the parameter space. If we didn't normalize and the original was lower bound of 0 and upper bound of 4, the new one would be 0 to 2.5. Even samples would match between the two. But, we can't really use the blind case of taking even samples if we care about having at least some samples from every segment. We have to adapt to make sure we take some points on both sides of every integer. Not only are the endpoints of the bounds important, but where they are is also important. This seems to me to complicate what would be a simple algorithm design. Normalizing avoids this problem.

Another phenomenon I have seen in the trails that I tend to work with is that shorter segments tend to have a smaller radius of curvature and longer segments have large radii. This fits nicely with normalizing as it focuses samples (when sampling evenly) on the detailed features.

None of this removes the need for having the mapping from parameter space to the subspaces parameter space. I feel like there might be a cleaner way to do it then including splitAtParam' in the class, but I'm not sure what it would be. There is also the issue of how to parameterize the space outside of the bounds 0 to 1 (as we allow access to this part of the space for extending).

Anyway, discuss.

[fryguybob]

I think this should be merged as it does the minimal thing to fix section and we can continue to think about the other implications later.