Re: [PyX-devel] Curves with infinite curvature

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

Hello,

On 14.09.05, Joerg Lehmann wrote:
> On 14.09.05, Andre Wobst wrote:
> > On 12.09.05, Joerg Lehmann wrote:
> > > > On 12.09.05, Michael Schindler wrote:
> > > > > There is something else that judges against raising an exception, in
> > > > > favour of the "arbitrary marker value": We calculate curvatures and
> > > > > rotations ... always for a list of parameter values. If one of them
> > > > > makes problems, you will never find out which one of them it was and
> > > > > you cannot do anything against it. The outcome would be that the user
> > > > > (or the module that uses this feature) has to ask for one
> > > > > parameter value after the other in a try...except block.

> > Ok. I think we're in trouble here. An exception doesn't provide us
> > with a proper recovery strategy. (It's a well known limitation of an
> > exception system.) There are several ways out.
> > 
> > - We could raise an execption and mark it with further information.
> >   Still, since we processed an list of values, the whole system is
> >   complicated and inappropriate. We can raise only an single exception
> >   and should provide all information we collected. In some sence, the
> >   exception is a return value containing some results, which we were
> >   able to get and some error information. It's a no win situation
> >   compared to using a marker in the result.
> 
> In the framework of our present implementation it would be easy to put
> the parameter value leading to the problem in the exception. This has
> the drawback that when the caller has passed a list, he doesn't know the
> index in the list, which is suboptimal. On the other hand, we could
> capture the exception in the method decorator. There we still know the
> list index, which we could use to generate a new exception containing
> this information. Then the caller would get all the information he
> needs. 

I do not really understand this suggestion.
When doing parallel deformation, I have infinite curvatures (which is
equivalent to a parameter "velocity" of zero) quite regularly. This is
nothing the user should be bothered with, because the parallel
deformer will know how to deal with it. My question is: How will this
look in the code, when implementing that exception which tells me that
there were errors processing a list?
  try:
      curvatures = np.curvature_pt(somelist)
  except GeometricError:
      list_of_invalid_curvatures = ???

How do I access the return string/value of that GeometricException
here?

> > - We could return a marker. This marker could be clever in that sence,
> >   that it raises an exception as soon as it is accessed. (However you
> >   could do a "x is _marker" check without an excpetion.) It would be
> >   kind of a late evaluation exception raising similar to what we did
> >   with the _invalidcurrentpoint in earlier versions of the path system
> >   (cf.
> >   http://cvs.sourceforge.net/viewcvs.py/pyx/pyx/pyx/path.py?rev=1.228&view=markup)
> > 

> I don't like this idea too much. The main thing which bothers me, that
> we somehow mask an error, which actually has occured. In this sense,
> this is totally different from the _invalidcurrentpoint example. There
> is one argument in favour of it, namely the existence of NaN in many
> floating point implementations. This would set a precedence for a
> similar solution in PyX.

I prefer this option -- not so much for the curvatures, because they
are simply numbers (and we could use +"inf" or -"inf" which are easily
produced by saying float("inf") -- this is much better than Nan,
because we can divide by it).
When thinking of invalid transformations, this gets really reasonable.
Why not introduce a
  trafo.invalid
class in the trafo module? This could be returned without any
problems, and it raises an error, as André suggests.
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. 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.

> > - The third solution could be a callback function in case we step into
> >   an error. In other languages (list, smalltalk) a (more advanced)
> >   condition system is used in general in favour of excepts, but the
> >   question is, whether it's that easy to recover from an error by some
> >   callback/fallback/whatever.
> 
> This gets a definite -1 from me, as it strikes me as being totally
> unpythonic.

This sounds very complicated, again.

Michael.

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