API for computing tangent and normal vectors to segments and trails

[byorgey]

Opening a pull request so as to have a convenient place to discuss the code, and this feature generally, while I continue to work on it. Please do not merge yet.

[byorgey]

I'm particularly interested to hear what people think of this idiom, where we have a newtype wrapper that exists solely for its instances, and the user ends up writing things of the form

getSegment tr `atParam` 0.6

In this example getSegment is doing nothing but applying a newtype wrapper. It's a bit strange since the getSegment function itself does not really have a semantics; but on the other hand it seems to read fairly well (and lets us reuse the Parametric etc. classes for this). I was planning to use the same idiom with Tangent and Normal wrappers. I'm happy to hear comments, suggestions for alternative approaches, etc.

[jeffreyrosenbluth]

hmm, yes it is a bit strange and perhaps a tad confusing without knowing ahead of time that it's a newtype wrapper.
What about creating a type class:

class Parametric p => hasSegments p where segAtParam :: ...

then you could write

tr `segAtParam` 0.6

[byorgey]

That would work, but the downside is that feels like there's some duplication going on, e.g. we would also end up with classes HasTangent with tangentAtParam, and HasNormal with normalAtParam... basically duplicating the Parametric class each time. Note that I want to use the EndValues class as well (since e.g. we can compute the tangents at the endpoints of a segment exactly, without resorting to the general Bézier formula), so then we would have to duplicate that class as well... doesn't feel very nice.

However, this does suggest one possible compromise, as an aid to users: we could provide convenience functions e.g. segAtParam, tangentAtParam, normalAtParam, tangentAtStart, tangentAtEnd, etc. which are defined as e.g. segAtParam x p = getSegment x atParam p. So then we get to reuse the whole Parametric infrastructure and also make it a bit more intuitive for users.

[jeffreyrosenbluth]

Can't we assume if something has segments it also has tangents and normals.

Sent from my iPhone

On Sep 15, 2013, at 5:33 PM, Brent Yorgey notifications@github.com wrote:

That would work, but the downside is that feels like there's some duplication going on, e.g. we would also end up with classes HasTangent with tangentAtParam, and HasNormal with normalAtParam... basically duplicating the Parametric class each time. Note that I want to use the EndValues class as well (since e.g. we can compute the tangents at the endpoints of a segment exactly, without resorting to the general Bézier formula), so then we would have to duplicate that class as well... doesn't feel very nice.

However, this does suggest one possible compromise, as an aid to users: we could provide convenience functions e.g. segAtParam, tangentAtParam, normalAtParam, tangentAtStart, tangentAtEnd, etc. which are defined as e.g. segAtParam x p = getSegment x atParam p. So then we get to reuse the whole Parametric infrastructure and also make it a bit more intuitive for users.

—
Reply to this email directly or view it on GitHub.

[byorgey]

Yes, but the converse may not be true. E.g. 3D objects can be treated as parametric surfaces, and have normals, but they are not composed of segments.

[byorgey]

OK, this is ready to be merged if someone wants to take a look. I ended up adding functions like tangentAtParam etc., so the user doesn't have to know about the newtype wrappers in order to use it.

[jeffreyrosenbluth]

This looks good. Does anything need to be re-exported from TwoD.hs?

[byorgey]

Ah, good catch --- this is not 2D-specific so it should not be re-exported from TwoD.hs, but it should be re-exported from Diagrams.Prelude, which I just pushed: @bba31f0.