Re: [PyX-devel] Curves with infinite curvature

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

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.

> > 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.

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.

> 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.

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 


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript and PDF figures
 (_/ \_)_/\_/     with Python & TeX: visit http://pyx.sourceforge.net/