Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
Close
From: Joerg Lehmann <joergl@us...>  20050909 08:22:58

Hi Michael! On 09.09.05, Michael Schindler wrote: > I have hit a problem concerning the geometry things of the normpaths. > Consider a Bezier curve that contains a point with infinite curvature. > This is very easy to produce by setting e.g. the last two points to > the same coordinates > > n = normcurve_pt(0,0, 1,1, 1,0, 1,0) > > The curveradius_pt returns "None" for parameter value 1. But the > trafo/rotation does something quite unexpected. The tangent vector > > n.rotation([0.999999])[0].apply_pt(1, 0) > > seems to converge against (1, 0) while adding more "9"s to the > parameter. However, the tangent at the parameter value 1 is (1, 0). > > My question now is, how well do we want to really reproduce the true > underlying geometry? We should return "None" for the rotation at such > points also. I think, we should return the correct rotation instead of None. Geometrically, everything is welldefined, it's only that we commit some numerical error because the length of (dx/dt, dy/dt) goes to zero. But we should be able to treat this case better. Jörg 
From: Michael Schindler <mschindler@us...>  20050909 08:07:04

Hello, I have hit a problem concerning the geometry things of the normpaths. Consider a Bezier curve that contains a point with infinite curvature. This is very easy to produce by setting e.g. the last two points to the same coordinates n = normcurve_pt(0,0, 1,1, 1,0, 1,0) The curveradius_pt returns "None" for parameter value 1. But the trafo/rotation does something quite unexpected. The tangent vector n.rotation([0.999999])[0].apply_pt(1, 0) seems to converge against (1, 0) while adding more "9"s to the parameter. However, the tangent at the parameter value 1 is (1, 0). My question now is, how well do we want to really reproduce the true underlying geometry? We should return "None" for the rotation at such points also. Michael.  "A mathematician is a device for turning coffee into theorems" Paul Erdös. 
From: Joerg Lehmann <joergl@us...>  20050909 08:22:58

Hi Michael! On 09.09.05, Michael Schindler wrote: > I have hit a problem concerning the geometry things of the normpaths. > Consider a Bezier curve that contains a point with infinite curvature. > This is very easy to produce by setting e.g. the last two points to > the same coordinates > > n = normcurve_pt(0,0, 1,1, 1,0, 1,0) > > The curveradius_pt returns "None" for parameter value 1. But the > trafo/rotation does something quite unexpected. The tangent vector > > n.rotation([0.999999])[0].apply_pt(1, 0) > > seems to converge against (1, 0) while adding more "9"s to the > parameter. However, the tangent at the parameter value 1 is (1, 0). > > My question now is, how well do we want to really reproduce the true > underlying geometry? We should return "None" for the rotation at such > points also. I think, we should return the correct rotation instead of None. Geometrically, everything is welldefined, it's only that we commit some numerical error because the length of (dx/dt, dy/dt) goes to zero. But we should be able to treat this case better. Jörg 
From: Joerg Lehmann <joergl@us...>  20050909 09:16:46

Hi Michael, [ sorry, I forgot to CC the list before, here it goes again ] n 09.09.05, Michael Schindler wrote: > On 09.09.05, Joerg Lehmann wrote: > > On 09.09.05, Michael Schindler wrote: > > > On 09.09.05, Joerg Lehmann wrote: > > > > Hi Michael! > > > > > > > > On 09.09.05, Michael Schindler wrote: > > > > > I have hit a problem concerning the geometry things of the normpaths. > > > > > Consider a Bezier curve that contains a point with infinite curvature. > > > > > This is very easy to produce by setting e.g. the last two points to > > > > > the same coordinates > > > > > > > > > > n = normcurve_pt(0,0, 1,1, 1,0, 1,0) > > > > > > > > I think, we should return the correct rotation instead of None. > > > > > > That is my problem. If you have infinite curvature, there is no > > > geometrically defined rotation. Because the curvature is the change of > > > the normal vector along the curve length, projected onto the tangent > > > vector (or equally the other way round), you see that both vectors > > > change infinitely fast. Thus, they do not exist in this point. > > > > Maybe I'm missing the point, but for me the rotation doesn't have > > anything to do with the curvature, but is solely defined in terms of > > the tangent. > > Correct. The tangent is not defined in such point. Ok, this sounds reasonable. > This is what I have learned some years ago in a lecture on > differential geometry: Consider a parameterization of a curve. The > parameterization can be Cinfty. But: if the length "velocity" (dx/dt, > dy/dt) is zero somewhere, you can easily create a cusp in that curve. > So, the curve is not smooth anymore, and in that cusp the tangent > vector is not continuous: From both sides the tangents approach > different values. Ah, ok, the limits from above and below do not agree. But in the output, there is no cusp because we do not see the behaviour for param > 1. Hmm... > > So I would assume that we take the limiting case of the rotation defined > > by the tangent as param>1. This you can easily calculate via l'Hopital > > and it gives you (1, 0) in the present case. > > In the present case we have only one side to do this. It would be very > nice if already this worked. Nevertheless, the problem remains if the > parameterization velocity vanishes somewhere in the middle. Can this happen in the case of Bézier curves? > > Having said all that, I just want to remark that Ghostscript also > > isn't quite a fan of a Bézier curve with two identical control points. > > Just try to stroke the above normpath and view the resulting EPS > > file... > > Well, my ghostscript does not complain. But the tangent does not seem > to be (1, 0) at the end. Ah, sorry, of course it works, there was another problem. And yes, the tangent does not looks like being (1, 0) at then end, although this is the limit from below. I'm really getting confused now. > > So, maybe we're discussing a point which is quite academical anyway. > > I tapped into this while writing the parallel deformer where infinte > curvatures are a big issue. I suspected something like this... Jörg 
From: Michael Schindler <mschindler@us...>  20050909 10:39:28

Hello Jörg, On 09.09.05, Joerg Lehmann wrote: > On 09.09.05, Michael Schindler wrote: > > > This is what I have learned some years ago in a lecture on > > differential geometry: Consider a parameterization of a curve. The > > parameterization can be Cinfty. But: if the length "velocity" (dx/dt, > > dy/dt) is zero somewhere, you can easily create a cusp in that curve. > > So, the curve is not smooth anymore, and in that cusp the tangent > > vector is not continuous: From both sides the tangents approach > > different values. > > Ah, ok, the limits from above and below do not agree. But in the output, > there is no cusp because we do not see the behaviour for param > 1. > Hmm... > > > In the present case we have only one side to do this. It would be very > > nice if already this worked. Nevertheless, the problem remains if the > > parameterization velocity vanishes somewhere in the middle. > > Can this happen in the case of Bézier curves? Very easily: n = normcurve_pt(0,0, 1,1, 0,1, 1,0) has a cusp at parameter 0.5, where the tangent switches from (0,1) to (0,1). > > > So, maybe we're discussing a point which is quite academical anyway. > > > > I tapped into this while writing the parallel deformer where infinte > > curvatures are a big issue. > > I suspected something like this... It is even that bad that I consider giving up the "None" business for the curvature radius. But then, after thinking about it for a while, I consider it better to throw something like "None" rather than an "inf" or "inf" value. For the latter it would be very convenient to calculate a curvature. One can divide by it and gets 0. On the other hand, when calculating with "inf" one soon gets "inf" everywhere, and the output will then be an invalid postscript. This would be really worse than thowing Exceptions here and there, when a "None" occurs where it should not. André asked me why there is a curveradius and not a curvature method. I answered that we need a length here, because lengths (and not inverse lengths) are natural to PyX. But I am not so convinced of this anymore because I need to convert the curvradius here and there in the deformers. Michael.  "A mathematician is a device for turning coffee into theorems" Paul Erdös. 
From: Joerg Lehmann <joergl@us...>  20050909 10:50:14

Hello Michael! On 09.09.05, Michael Schindler wrote: > > Can this happen in the case of Bézier curves? > > Very easily: > > n = normcurve_pt(0,0, 1,1, 0,1, 1,0) > > has a cusp at parameter 0.5, where the tangent switches from (0,1) to > (0,1). Ok. Maybe we could just raise an exception when the "speed" (dx/dt, dy/dt) is lower than the epsilon of the normcurve_pt instance. > > > > So, maybe we're discussing a point which is quite academical anyway. > > > > > > I tapped into this while writing the parallel deformer where infinte > > > curvatures are a big issue. > > > > I suspected something like this... > > It is even that bad that I consider giving up the "None" business for > the curvature radius. But then, after thinking about it for a while, I > consider it better to throw something like "None" rather than an "inf" > or "inf" value. For the latter it would be very convenient to > calculate a curvature. One can divide by it and gets 0. On the other > hand, when calculating with "inf" one soon gets "inf" everywhere, and > the output will then be an invalid postscript. This would be really > worse than thowing Exceptions here and there, when a "None" occurs > where it should not. I'm not such a fan of None, tough. IMO, it would be better to raise an exception instead. > André asked me why there is a curveradius and not a curvature method. > I answered that we need a length here, because lengths (and not > inverse lengths) are natural to PyX. But I am not so convinced of this > anymore because I need to convert the curvradius here and there in the > deformers. We could only have curvature_pt, but if it's useful why not add it. I think it would be a good idea to do so. Jörg 
From: Andre Wobst <wobst@dp...>  20050909 12:37:09

Hi, I'm sorry I couldn't join the discussion earlier. On 09.09.05, Joerg Lehmann wrote: > Ok. Maybe we could just raise an exception when the "speed" (dx/dt, > dy/dt) is lower than the epsilon of the normcurve_pt instance. In principle I'm +1 to that, but we should have a look to the details first. For example, a speed is not a length, and the epsilon might be too big. But as soon as we know, the curvature is instable, we need to avoid returning something wrong. > > It is even that bad that I consider giving up the "None" business for > > the curvature radius. But then, after thinking about it for a while, I > > consider it better to throw something like "None" rather than an "inf" > > or "inf" value. For the latter it would be very convenient to > > calculate a curvature. One can divide by it and gets 0. On the other > > hand, when calculating with "inf" one soon gets "inf" everywhere, and > > the output will then be an invalid postscript. This would be really > > worse than thowing Exceptions here and there, when a "None" occurs > > where it should not. > > I'm not such a fan of None, tough. IMO, it would be better to raise an > exception instead. I'm mostly against inf/inf, since this is a feature of certain floating point representations. There is (1) no guaranty this being plattform independend and (2) you can't easily create a +/inf (at least in a platform invariant way). Sure, there are some generic ways for IEEE maschines, but you just need to go to a typical vector maschine, and all this breaks horrible. > > André asked me why there is a curveradius and not a curvature method. > > I answered that we need a length here, because lengths (and not > > inverse lengths) are natural to PyX. But I am not so convinced of this > > anymore because I need to convert the curvradius here and there in the > > deformers. > > We could only have curvature_pt, but if it's useful why not add it. I > think it would be a good idea to do so. +1 Yes. I would like that very much. And it's typical usecase is internal numerics where we're in _ptmode all the time. It would certainly help to clean up various codes ... André  by _ _ _ Dr. André Wobst, http://www.wobsta.de/ / \ \ / ) EMail: wobst@... / _ \ \/\/ / www: http://www.dpgtagungen.de/ (_/ \_)_/\_/ Telefon: 070083742635 aka 0700VERHANDL(UNGEN) Aus dem Festnetz der Deutschen Telekom fallen Gebühren bis zu 0.122 EUR pro Minute an. Informieren Sie sich bei Ihrer Telefongesellschaft über anfallenden Gebühren beim Anruf einer 0700er Nummer. 