Re: [PyX-devel] Curves with infinite curvature

[Michael S. <m-s...@us...>]

On 14.09.05, Andre Wobst wrote:
> Hi,
> 
> On 14.09.05, Joerg Lehmann wrote:
> > You would access it like this
> > 
> >     try:
> >         curvatures = np.curvature_pt(somelist)
> >     except GeometricError, e:
> >         list_of_invalid_curvatures = e.invalid_indices
> > 
> > Or alternatively, we could generate a new list exception containing
> > the separate exceptions:
> > 
> >     try:
> >         curvatures = np.curvature_pt(somelist)
> >     except PathExceptionList, ies:
> >         for index, e in ies:
> >             # index is the index of the exception
> >             # e is the corresponding PathException
> 
> Ah ... you want to return a full set of invalid indices. That's at
> least better in terms of redoing calculations (especially when the
> fallback does something completely different, which might be likely in
> certain use-cases). I was thinking to return a single index for the
> first problematic point only ...
> 
> >    http://mail.python.org/pipermail/python-dev/2004-February/042421.html
> 
> I've seen the different behaviour of sqrt of negative values myself
> already (switching between Mac and Linux). You just have to get used
> to it.
> 
> > Btw, I just picked NaN because this is the thing which is most
> > resembling the marker thing. Inf would be less since from a mathematical
> > point of view, you could think of a compactified version of the real
> > numbers (in which -Inf doesn't fit, though), so Inf would be just a
> > number.
> > 
> > > When thinking of invalid transformations, this gets really reasonable.
> > > Why not introduce a
> > >   trafo.invalid
> > > class in the trafo module? 
> > 
> > Hmm. And what would you return for the curvatures?
> 
> I think we should have a generic invalid marker.
> 
> > > This could be returned without any
> > > problems, and it raises an error, as André suggests.
> > 
> > Would trafo.scale(0, 0).inverse() return trafo.invalid?
> 
> Hmmm. Maybe. Yes, I think so. I think its best to return invalid here
> too. Just fetch a ArithmeticError and that's it. Still, a plattform
> might not raise the ArithmeticError (ZeroDivisionError). Than we can't
> do much in this case ...
> 
> > > The next thing is that there was this invalid scaling in a recent
> > > PyX-user thread: trafo.scale(0, 0) looks like a perfect candidate for
> > > trafo.invalid. 
> > 
> > André would argument against this, I suppose. And me as well, for the
> > reason given by yourself:
> 
> Right. I'm against it. There are trafos which can't be inverted. But
> they are perfect affine trafos.

This is right, but inverting a trafo is still an open problem. In
trafo.py at the moment an exception is raised:

  raise UndefinedResultError, "transformation matrix must not be
  singular"

The comment "# shouldn't be zero, but" indicated that something is not
completely finished here.

> > > The only question here is -- as always -- the question
> > > of thresholds. Meybe there is a possibility to check this at least for
> > > normpaths, when writing them.

> > Coming back to the original question, you probably have in mind the
> > simplicity of the deformer implementation. If I understand you
> > correctly, you say that an exception-based system makes the code more
> > involved. This is certainly a point to take into account.

Yes.

> Right. We do want to handle the invalid case at the point we're
> accessing it. We should not have the burden to always have to
> prehandle that case. That's why an exception is not very useful.

Yes.

> > Initially, I
> > mainly objected to using None as a marker. Against some more specialized
> > marker, I would only mildly object, though. And certainly, your deformer
> > code represents a rather comprehensive use case for the path system.
> > 
> > So, we could introduce something like trafo.invalid but we would also
> > need a marker for the infinite curvature case. Alternatively, we could
> > just live with a single notdefined marker.

+0.5 for both: trafo.invalid (as a more specialized marker) and _marker
(or notdefined or helper.notdefined ...) for the curvature/radius
case.

> I'm at least +0 for a generic notdefined marker. Which -- for the sake
> of easy to use -- should raise exceptions on access like the old
> invalidcurrentpoint did. It's just handy. And I would also like to
> have a 
>
> Sorry. I wanted to say, that I still think, that we could use this
> notdefined in keyword arguments as well. The point is, that we should
> never use this marker but only check by "... is notdefined". Then
> we're back at the naming issue. For the use case in this thread
> "notdefined" seems appropriate. For the keyword arg "_marker" is more
> common. We might just create two instances for that. Fine. The last
> question I would than ask, whether we want it underscored or not (in
> the helper module). I would not underscore it, although this is would
> be different from "_marker". BTW did we reach a final decision whether
> to have a single _marker in helper or whether we should create such a
> class/instance/whatever in every module. I would like to have a single
> instance ...

An underscore would rather prevent users from using it. They should
not.

Michael.

-- 
"A mathematician is a device for turning coffee into theorems"
  Paul Erdös.