Re: [PyX-devel] Curves with infinite curvature

[Joerg L. <jo...@us...>]

Hi André,

parallelism...

On 14.09.05, Andre Wobst wrote:
> Hi,
> 
> On 14.09.05, Joerg Lehmann wrote:
> > > - 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. 
> 
> Right, but that's not the point. Whenever we pass parts of the list to
> normsubpathitems etc., we just also need to catch the exception and
> correct the list index where the error occur. This would be a clean
> and easy solution.
> 
> There are just to small issues here: The first is, that the we throw
> away solutions we just calculated. This is highly contra-productive,
> since we wanted the lists to be used to improve the performance. The
> second is, that it would be difficult for the caller to use. Whenever
> a problem occurs it must resolve the (local) issue before doing the
> (global) calculation.

Yep, that's a point against this.

> I expect that it'll be most easy to for the caller to use a single
> item list all the time. For that case we do not even need the index,
> but we would get it in the exception. The index will always be 0.

Yep.

> Ok, let's analyse the use-cases. We'll step into the problem for the
> curveradius, the rotation, the trafo and the tangent (and the
> curvature, once we'll introduce it) only. Usually the exception might
> not be catched at all, so it doesn't really matter. The only
> interesting point is, when we want to recover from such an situation.
> Any case outside of the parallel deformer, where we expect that to
> happen? Maybe we should just live with it. I'm not sure.

As I wrote in my previous mail, the defomer is a very comprehensive
use case, which we should take into account.

> > > - 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 didn't even thought about this point, but this more or less supports
> the idea instead of being against it. So why not?

Yes, it supports the marker idea (hey, I tried to find arguments for all
options).


> > > I think the second option is by far the most easiest one for our
> > > use-case of invalid curvatures/transformations etc. We could make it a
> > > general feature of the marker instance we're planing in favor of the
> > > existing helper.nodefault to raise an exception on access. That's by
> > > the way something such a marker is for ...
> > 
> > No. Internally, we should no how to deal with our markers. There is
> > really no need to protect us from ourselves.
> 
> Question is, whether _marker and _invalid is the same.

See my other mail. This has to be discussed.

> > All in all, I would still favour the first option, as long as there are
> > not more arguments against it. Alternatively, you can try to convince me
> > of the merits of the second solution :-)
> 
> My major concern is, that for cases where we want to recover from such
> an situation, the exception solution will lead to a typical useage
> scenario with a single item list. That would at least be strange. And
> that's also what Michael started the discussion with ...

Yep, Michael put forward some good arguments, so I would accept the
second option with marker != None.

        Jörg