You can subscribe to this list here.
2002 
_{Jan}

_{Feb}
(13) 
_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}


2003 
_{Jan}

_{Feb}

_{Mar}
(2) 
_{Apr}

_{May}
(5) 
_{Jun}
(15) 
_{Jul}
(4) 
_{Aug}
(4) 
_{Sep}
(4) 
_{Oct}
(41) 
_{Nov}
(3) 
_{Dec}
(19) 
2004 
_{Jan}
(7) 
_{Feb}
(1) 
_{Mar}
(6) 
_{Apr}
(13) 
_{May}
(26) 
_{Jun}
(6) 
_{Jul}
(66) 
_{Aug}
(13) 
_{Sep}

_{Oct}
(21) 
_{Nov}
(12) 
_{Dec}
(24) 
2005 
_{Jan}
(7) 
_{Feb}
(24) 
_{Mar}
(9) 
_{Apr}
(5) 
_{May}

_{Jun}
(8) 
_{Jul}
(5) 
_{Aug}
(22) 
_{Sep}
(58) 
_{Oct}
(6) 
_{Nov}

_{Dec}
(2) 
2006 
_{Jan}
(1) 
_{Feb}
(11) 
_{Mar}
(12) 
_{Apr}
(8) 
_{May}
(12) 
_{Jun}
(30) 
_{Jul}
(6) 
_{Aug}
(2) 
_{Sep}
(6) 
_{Oct}
(1) 
_{Nov}
(1) 
_{Dec}
(1) 
2007 
_{Jan}

_{Feb}

_{Mar}
(1) 
_{Apr}
(2) 
_{May}

_{Jun}

_{Jul}
(8) 
_{Aug}
(3) 
_{Sep}

_{Oct}
(1) 
_{Nov}

_{Dec}

2008 
_{Jan}

_{Feb}

_{Mar}
(21) 
_{Apr}
(6) 
_{May}
(12) 
_{Jun}
(13) 
_{Jul}

_{Aug}

_{Sep}
(5) 
_{Oct}

_{Nov}
(4) 
_{Dec}

2010 
_{Jan}
(2) 
_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}
(6) 
_{Jul}
(4) 
_{Aug}

_{Sep}
(1) 
_{Oct}

_{Nov}

_{Dec}
(3) 
2011 
_{Jan}

_{Feb}

_{Mar}

_{Apr}
(7) 
_{May}
(26) 
_{Jun}
(1) 
_{Jul}
(40) 
_{Aug}

_{Sep}

_{Oct}
(15) 
_{Nov}

_{Dec}
(2) 
2012 
_{Jan}

_{Feb}
(14) 
_{Mar}

_{Apr}

_{May}
(24) 
_{Jun}

_{Jul}

_{Aug}
(2) 
_{Sep}

_{Oct}
(9) 
_{Nov}
(3) 
_{Dec}
(2) 
2013 
_{Jan}
(12) 
_{Feb}
(8) 
_{Mar}

_{Apr}

_{May}
(3) 
_{Jun}

_{Jul}
(9) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}
(1) 
2014 
_{Jan}
(4) 
_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 





1
(2) 
2

3
(1) 
4

5

6
(2) 
7
(2) 
8
(1) 
9
(21) 
10

11

12
(7) 
13

14
(17) 
15

16

17

18

19

20

21

22
(1) 
23
(1) 
24

25

26

27

28
(2) 
29

30
(1) 

From: SourceForge.net <noreply@so...>  20050909 15:08:11

Patches item #1286116, was opened at 20050909 17:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442888&aid=1286116&group_id=45430 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Wojciech Smigaj (smigaj) Assigned to: Nobody/Anonymous (nobody) Summary: Disabling drawing ticks Initial Comment: This patch esentially switches two lines in the painter.regular.paint() function so as to make it possible to disable drawing ticks by setting tickattrs=None in the class' constructor (as advised in the documentation). It makes Python check whether tickattrs is None *before* merging it with defaulttickattrs.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442888&aid=1286116&group_id=45430 
From: SourceForge.net <noreply@so...>  20050909 15:01:17

Patches item #1286112, was opened at 20050909 17:01 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442888&aid=1286112&group_id=45430 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Wojciech Smigaj (smigaj) Assigned to: Nobody/Anonymous (nobody) Summary: anchoredaxis.(v)tickpoint correction Initial Comment: This patch aims to make the functions anchoredaxis.tickpoint() and anchoredaxis.vtickpoint() work by adding the missing definition of positioner.vtickpoint() and removing spurious factors unit_t_pt. Test case (not overly sophisticated output; gives an error when interpreted using an unpatched version of PyX): from pyx import * from pyx.graph import axis def pathaxis_raw(path, axis, **kwargs): """creates an axis along a path""" aanchoredaxis = graph.axis.anchoredaxis(axis, "pathaxis") aanchoredaxis.setpositioner(graph.axis.positioner.pathpositioner(path, **kwargs)) aanchoredaxis.create(None) return aanchoredaxis c = canvas.canvas() zaxis = pathaxis_raw( path.path( path.moveto( 0, 0 ), path.lineto( 3, 4 ) ), graph.axis.linear( min=0, max=4 ) ) c.insert( zaxis.canvas ) graphpos = zaxis.tickpoint( 3 ) g = graph.graphxy( width=8, xpos=graphpos[0], ypos=graphpos[1] ) g.plot( graph.data.function( "y(x) = x**2", min=2, max=2 ) ) c.insert( g ) c.writePDFfile("ticktestcase") A word about the pathaxis_raw() function above: it is obviously a variant of pathaxis() returning an *anchoredaxis* instead of a *canvas* containing that axis. I wonder if it couldn't be included in PyX (perhaps with an altered name); I've found such a function very useful sometimes.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442888&aid=1286112&group_id=45430 
From: Joerg Lehmann <joergl@us...>  20050909 13:50:50

Hi! On 09.09.05, Andre Wobst wrote: > On 09.09.05, Michael Schindler wrote: > > Is an exception the right thing to use here? I tend to dislike the > > try...except notation and am not quite sure how efficient this is. > > On the other had, with the different return types "float" or "None" > > one always has to ask for the proper return type. > > Right. And in that sense such an specific exception is fine. And AFAIK > (at least as long as exceptions do not occur very often), it is fine > to use them. The overhead of the tryblock is small (again AFAIK). Python's exception handling is very efficient. Furthermore, it's good practice to use exceptions instead of returning arbitrary marker values like None in cases where a result cannot be obtained due to some "exceptional" (ahem) condition  at least, as a rule of thumb, there are always exceptions, of course ;) > Beside that one should keep in mind, that exceptions should better not > be used to do flow control in a program. I.e. they should not be used > as a regular feature when nothing special happens. [snip] Hey, there are even use cases for things like this, but I agree that this should not be done without real reason. Jörg 
From: Andre Wobst <wobsta@us...>  20050909 13:21:19

Hi, On 09.09.05, Michael Schindler wrote: > Is an exception the right thing to use here? I tend to dislike the > try...except notation and am not quite sure how efficient this is. > On the other had, with the different return types "float" or "None" > one always has to ask for the proper return type. Right. And in that sense such an specific exception is fine. And AFAIK (at least as long as exceptions do not occur very often), it is fine to use them. The overhead of the tryblock is small (again AFAIK). Beside that one should keep in mind, that exceptions should better not be used to do flow control in a program. I.e. they should not be used as a regular feature when nothing special happens. But to properly work around certain instablilities, which are inherent, an exception seems to be the Right Thing (tm). André  by _ _ _ Dr. André Wobst / \ \ / ) wobsta@..., http://www.wobsta.de/ / _ \ \/\/ / PyX  High quality PostScript and PDF figures (_/ \_)_/\_/ with Python & TeX: visit http://pyx.sourceforge.net/ 
From: Michael Schindler <mschindler@us...>  20050909 13:04:30

On 09.09.05, Andre Wobst wrote: > Hi, > > On 09.09.05, Michael Schindler wrote: > > > 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. > > > > What do you think of? We could look at the neighborhood and return a > > value that is expected to be the limiting rotation when we pass to > > the critial point. > > But there are cases, where we really have an unsteady behaviour. At > least for that cases, we should stop and raise a proper exception. I'm > not sure whether it makes sense to distinguish between the two cases. > It might not be worth the effort ... I'm not sure. Beside that, when > raising an exception, it might be wise to introduce a special > exception class here to enable the caller to handle this issue. This is a question to the Python coding masters: Is an exception the right thing to use here? I tend to dislike the try...except notation and am not quite sure how efficient this is. On the other had, with the different return types "float" or "None" one always has to ask for the proper return type. Michael.  "A mathematician is a device for turning coffee into theorems" Paul Erdös. 
From: Andre Wobst <wobsta@us...>  20050909 12:59:20

Hi, On 09.09.05, Michael Schindler wrote: > What do you think of a method > > normpath.normpath.is_good() > normpath.normsubpath.is_good() > > that wrap this check? I'm not yet convinced. Ususally you should just be able to iterate of the normpathitems and normsubpathitems and that's working well for empty lists. Of course, there are cases, where you want to access to neighboring normsubpathitems (for example in the smoother). However, it might be, that the solution could be quite different. For example, you could ask for an iterator over successive normsubpathitems. Or you could want something, which gives you the successive normsubpathitem. Whatever. We welly need to understand the usecases first. I think (at the moment ... ;)). André  by _ _ _ Dr. André Wobst / \ \ / ) wobsta@..., http://www.wobsta.de/ / _ \ \/\/ / PyX  High quality PostScript and PDF figures (_/ \_)_/\_/ with Python & TeX: visit http://pyx.sourceforge.net/ 
From: Andre Wobst <wobsta@us...>  20050909 12:54:16

Hi, On 09.09.05, Michael Schindler wrote: > > 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. > > What do you think of? We could look at the neighborhood and return a > value that is expected to be the limiting rotation when we pass to > the critial point. But there are cases, where we really have an unsteady behaviour. At least for that cases, we should stop and raise a proper exception. I'm not sure whether it makes sense to distinguish between the two cases. It might not be worth the effort ... I'm not sure. Beside that, when raising an exception, it might be wise to introduce a special exception class here to enable the caller to handle this issue. André  by _ _ _ Dr. André Wobst / \ \ / ) wobsta@..., http://www.wobsta.de/ / _ \ \/\/ / PyX  High quality PostScript and PDF figures (_/ \_)_/\_/ with Python & TeX: visit http://pyx.sourceforge.net/ 
From: Andre Wobst <wobsta@us...>  20050909 12:48:22

Hi, On 09.09.05, Michael Schindler wrote: > Good. I have checked it in similar to this. Unfortunately your patch > in one of the previous mails got mixed up, but your statement shows me > that I have guessed right. I'm sorry to have considerably caused the confusion. I was reading just Michaels patch and I didn't properly notice, that the original problem was about not creating the figures at all. I didn't ever stepped into this issue during a release, since I'm used to also build the dvi version. Beside that we had the confusion with eps and pdf figures (which was BTW new in version 0.8.1). Michael has properly adopted the Makefile and Michaels solutions (also regarding pdftex) are in place at the CVS for upcoming releases. At the mean we know how to work around the various problems. Sorry again for the confusion, André  by _ _ _ Dr. André Wobst / \ \ / ) wobsta@..., http://www.wobsta.de/ / _ \ \/\/ / PyX  High quality PostScript and PDF figures (_/ \_)_/\_/ with Python & TeX: visit http://pyx.sourceforge.net/ 
From: Michael Schindler <mschindler@us...>  20050909 12:46:04

Hello, In the deformer I often have to check if a normpath or normsubpath is indeed valid. Unfortunately, if things get too short, or something else is wrong, this will cause Exceptions. E.g. a routine returns an empty normsubpath and another wants to join this to something else. I often have to ask things like np = ... a normpath nsp = ... a normsubpath if ns.normsubpaths and ns.normsubpaths.normsubpathitems do something if nsp.normsubpathitems: do something What do you think of a method normpath.normpath.is_good() normpath.normsubpath.is_good() that wrap this check? Michael  "A mathematician is a device for turning coffee into theorems" Paul Erdös. 
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. 
From: Michael Schindler <mschindler@us...>  20050909 11:09:08

Hello Jörg, On 09.09.05, Joerg Lehmann wrote: > On 09.09.05, Michael Schindler wrote: > > >>> b = normpath.normsubpath([a], 1.0e5) > > >>> print b > > normsubpath([normcurve_pt(0, 0, 1, 1, 1, 1, 1, 0), normline_pt(1, 0, 0, 0)], closed=1) > > > > The normsubpath, when just created, is closed !!! > > Yup, you're passing 1.0e5 to the closed argument of the normsubpath > constructor. Don't do that :) Use > > b = normpath.normsubpath([a], epsilon=1.0e5) > > instead. Thanks! Stupid mistake! Michael.  "A mathematician is a device for turning coffee into theorems" Paul Erdös. 
From: Joerg Lehmann <joergl@us...>  20050909 11:02:19

Hi Michael! On 09.09.05, Michael Schindler wrote: > I have found a strange behaviour that I so not understand looking at > the code: > > >>> import pyx > >>> pyx.version.version > '0.8+' > >>> from pyx import * > >>> from pyx import normpath > >>> a = normpath.normcurve_pt(0,0, 1,1, 1,1, 1,0) > >>> b = normpath.normsubpath([a], 1.0e5) > >>> print b > normsubpath([normcurve_pt(0, 0, 1, 1, 1, 1, 1, 0), normline_pt(1, 0, 0, 0)], closed=1) > > The normsubpath, when just created, is closed !!! > Can you help me here? Yup, you're passing 1.0e5 to the closed argument of the normsubpath constructor. Don't do that :) Use b = normpath.normsubpath([a], epsilon=1.0e5) instead. Jörg 
From: Michael Schindler <mschindler@us...>  20050909 10:52:45

Hello Jörg, André, I have found a strange behaviour that I so not understand looking at the code: >>> import pyx >>> pyx.version.version '0.8+' >>> from pyx import * >>> from pyx import normpath >>> a = normpath.normcurve_pt(0,0, 1,1, 1,1, 1,0) >>> b = normpath.normsubpath([a], 1.0e5) >>> print b normsubpath([normcurve_pt(0, 0, 1, 1, 1, 1, 1, 0), normline_pt(1, 0, 0, 0)], closed=1) The normsubpath, when just created, is closed !!! Can you help me here? 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: 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: Michael Schindler <mschindler@us...>  20050909 09:23:31

[sorry, I forgot to send this to the list, here it comes:] 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. 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. > 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. > 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. > 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. Michael.  "A mathematician is a device for turning coffee into theorems" Paul Erdös. 
From: Michael Schindler <mschindler@us...>  20050909 09:22:52

[sorry, I forgot to send this to the list, here it comes:] 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) > > > > 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. 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. > 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. What do you think of? We could look at the neighborhood and return a value that is expected to be the limiting rotation when we pass to the critial point. Michael.  "A mathematician is a device for turning coffee into theorems" Paul Erdös. 
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: 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: Michael Schindler <mschindler@us...>  20050909 07:57:56

On 08.09.05, Andrea Riciputi wrote: > On Sep 7, 2005, at 7:33 PM, Andre Wobst wrote: > Probably we don't understand each other. What I said (or at least > tried to) is that in the Makefile that comes with 0.8.1 tarball the > pdf version of the manual *does not* depend on the eps target. The > original Makefile reads: > > >manual.pdf: $(src) > > while it should read: > > >manual.pdf: $(src) eps > > Correcting the Makefile in this way solves the problem. Good. I have checked it in similar to this. Unfortunately your patch in one of the previous mails got mixed up, but your statement shows me that I have guessed right. Michael.  "A mathematician is a device for turning coffee into theorems" Paul Erdös. 