On 14.09.05, Michael Schindler wrote:
> 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?
You would access it like this
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:
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
> > > - 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")
That's impossible since it is only existent on certain platforms. Python
doesn't guarantee the existence of NaN, inf, etc. See the standard
quoute on this topic by Tim Peters:
Note that this shows that in this case, even the Python
documentation/standard doesn't define whether to return something like a
marker (NaN) or to raise an exception (ValueError). Note also, that the
OP in the referenced thread expected Python to raise an exception when
math.sqrt(-1) is being called - an expectation which Tim Peters didn't
explicitely object to. Note finally that this means that the present PyX
code may already raise exceptions on other platforms when it doesn't do
so on Linux.
> -- this is much better than Nan,
> because we can divide by 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
> When thinking of invalid transformations, this gets really reasonable.
> Why not introduce a
> class in the trafo module?
Hmm. And what would you return for the curvatures?
> This could be returned without any
> problems, and it raises an error, as André suggests.
Would trafo.scale(0, 0).inverse() return trafo.invalid?
> 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
André would argument against this, I suppose. And me as well, for the
reason given by yourself:
> 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. 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.