From: Dani Marti <daniel.marti@up...>  20050913 16:43:22

Hi all, What is the most straightforward way to plot an ellipse (or something that looks like an ellipse, like a deformed circle)? Is any predefined path for an ellipse? Thanks a lot, dani 
From: Dani Marti <daniel.marti@up...>  20050913 16:43:22

Hi all, What is the most straightforward way to plot an ellipse (or something that looks like an ellipse, like a deformed circle)? Is any predefined path for an ellipse? Thanks a lot, dani 
From: Alan G Isaac <aisaac@am...>  20050913 20:52:41

On Tue, 13 Sep 2005, Dani Marti apparently wrote: > What is the most straightforward way to plot an ellipse > (or something that looks like an ellipse, like a deformed > circle)? Is any predefined path for an ellipse? Apologies if this does not go to your question. You can scale a circle or, if you need to know all the coordinates, use a parametric plot. fwiw, Alan Isaac 
From: Andre Wobst <wobsta@us...>  20050914 05:45:14

Hi, On 13.09.05, Dani Marti wrote: > What is the most straightforward way to plot an ellipse (or something > that looks like an ellipse, like a deformed circle)? Is any predefined > path for an ellipse? def elipse(x, y, a, b, angle): t = trafo.scale(unit.topt(a), unit.topt(b)).rotated(angle).translated(x, y) return path.circle_pt(0, 0, 1).transformed(t) Its fine as long as a and b are not close to zero. For this case two problems occur: First scale does not work as expected (for a or b being exactly zero). Jörg, do you remember what the idea was? I don't remember/understand it. (A solution could be to change the trafo.scale or to build our own transformation matrix.) The second problem is related to the transformed on a small closed object (when a and b are both almost zero, say 1e10). The later can be solved by ".normpath(epsilon=None).transformed(t).path()" instead of just ".transformed(t)". (Jörg, Michael: Here we have a second usecase for the recent addition of the epsilon=None feature ... ;)). Once the scale thing is cleared, I'll happily add an elipse to the PyX core. In the mean the function above will certainly do ... 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: Joerg Lehmann <joergl@us...>  20050914 08:14:44

On 14.09.05, Andre Wobst wrote: > Hi, > > On 13.09.05, Dani Marti wrote: > > What is the most straightforward way to plot an ellipse (or something > > that looks like an ellipse, like a deformed circle)? Is any predefined > > path for an ellipse? > > def elipse(x, y, a, b, angle): > t = trafo.scale(unit.topt(a), unit.topt(b)).rotated(angle).translated(x, y) > return path.circle_pt(0, 0, 1).transformed(t) Btw, this makes another class/factory function for our future paths module... > Its fine as long as a and b are not close to zero. For this case two > problems occur: First scale does not work as expected (for a or b > being exactly zero). Jörg, do you remember what the idea was? Then the transformation matrix becomes degenerate, which we somehow wanted to exclude at that time. Maybe, we shouldn't be too strict about that, at least if PostScript doesn't complain in such a case (I didn't check). But for the present case, this is pointless anyway. > I don't > remember/understand it. (A solution could be to change the trafo.scale > or to build our own transformation matrix.) The second problem is > related to the transformed on a small closed object (when a and b are > both almost zero, say 1e10). The later can be solved by > ".normpath(epsilon=None).transformed(t).path()" instead of just > ".transformed(t)". (Jörg, Michael: Here we have a second usecase for > the recent addition of the epsilon=None feature ... ;)). I don't know why this case should be too problematic. Who wants such an ellipse? Jörg 
From: Andre Wobst <wobsta@us...>  20050914 08:41:12

On 14.09.05, Joerg Lehmann wrote: > > On 13.09.05, Dani Marti wrote: > > > What is the most straightforward way to plot an ellipse (or something > > > that looks like an ellipse, like a deformed circle)? Is any predefined > > > path for an ellipse? > > > > def elipse(x, y, a, b, angle): > > t = trafo.scale(unit.topt(a), unit.topt(b)).rotated(angle).translated(x, y) > > return path.circle_pt(0, 0, 1).transformed(t) > > Btw, this makes another class/factory function for our future paths > module... Right. > > Its fine as long as a and b are not close to zero. For this case two > > problems occur: First scale does not work as expected (for a or b > > being exactly zero). Jörg, do you remember what the idea was? > > Then the transformation matrix becomes degenerate, which we somehow > wanted to exclude at that time. Maybe, we shouldn't be too strict about > that, at least if PostScript doesn't complain in such a case (I didn't > check). I didn't either. Maybe that's the point. Otherwise I don't see any reason for this restriction. Beside that the checks are strange, they're even wrong for the case of b=0, which lead to a circle instead of a line. Again, a marker issue here ... ;) > But for the present case, this is pointless anyway. Not really, it just shouldn't break. See below. > > I don't > > remember/understand it. (A solution could be to change the trafo.scale > > or to build our own transformation matrix.) The second problem is > > related to the transformed on a small closed object (when a and b are > > both almost zero, say 1e10). The later can be solved by > > ".normpath(epsilon=None).transformed(t).path()" instead of just > > ".transformed(t)". (Jörg, Michael: Here we have a second usecase for > > the recent addition of the epsilon=None feature ... ;)). > > I don't know why this case should be too problematic. Who wants such > an ellipse? Well, the ellipse should just work. Suppose you're using it in a graph style with flexible size given by the data values you put in. Like for circles in the first graphstyle example. It just shouldn't break. It doesn't even break for negative values so why should it for zero or something close to zero ... 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: Joerg Lehmann <joergl@us...>  20050914 11:34:59

On 14.09.05, Andre Wobst wrote: > On 14.09.05, Joerg Lehmann wrote: > > > On 13.09.05, Dani Marti wrote: > > > > What is the most straightforward way to plot an ellipse (or something > > > > that looks like an ellipse, like a deformed circle)? Is any predefined > > > > path for an ellipse? > > > > > > def elipse(x, y, a, b, angle): > > > t = trafo.scale(unit.topt(a), unit.topt(b)).rotated(angle).translated(x, y) > > > return path.circle_pt(0, 0, 1).transformed(t) > > > > Btw, this makes another class/factory function for our future paths > > module... > > Right. > > > > Its fine as long as a and b are not close to zero. For this case two > > > problems occur: First scale does not work as expected (for a or b > > > being exactly zero). Jörg, do you remember what the idea was? > > > > Then the transformation matrix becomes degenerate, which we somehow > > wanted to exclude at that time. Maybe, we shouldn't be too strict about > > that, at least if PostScript doesn't complain in such a case (I didn't > > check). > > I didn't either. Maybe that's the point. Otherwise I don't see any > reason for this restriction. Beside that the checks are strange, > they're even wrong for the case of b=0, which lead to a circle instead > of a line. Again, a marker issue here ... ;) According to PLRM, p. 189, transformation with determinant zero are "not very useful" and can lead to undefinedresult errors "during the execution of graphics and font operators". Oh well, not a very useful statement for a reference either. > Well, the ellipse should just work. Suppose you're using it in a graph > style with flexible size given by the data values you put in. Like for > circles in the first graphstyle example. It just shouldn't break. It > doesn't even break for negative values so why should it for zero or > something close to zero ... I really don't know. But I would tend to attempt preventing PS code which is not leading to errors. Jörg 
From: Andre Wobst <wobsta@us...>  20050914 11:59:57

On 14.09.05, Joerg Lehmann wrote: > > > > Its fine as long as a and b are not close to zero. For this case two > > > > problems occur: First scale does not work as expected (for a or b > > > > being exactly zero). Jörg, do you remember what the idea was? > > > > > > Then the transformation matrix becomes degenerate, which we somehow > > > wanted to exclude at that time. Maybe, we shouldn't be too strict about > > > that, at least if PostScript doesn't complain in such a case (I didn't > > > check). > > > > I didn't either. Maybe that's the point. Otherwise I don't see any > > reason for this restriction. Beside that the checks are strange, > > they're even wrong for the case of b=0, which lead to a circle instead > > of a line. Again, a marker issue here ... ;) > > According to PLRM, p. 189, transformation with determinant zero are "not > very useful" and can lead to undefinedresult errors "during the > execution of graphics and font operators". Oh well, not a very useful > statement for a reference either. In some sense, right. But it tells us, that we should not put something out, which has determinant 0. We can savely always point at someone else, when somebody somes with it. We basically have to ensure that the trafo can be inverted. (We should also keep in mind, that it's something else we're having in our variables than what we write into a file, but at least in PostScript we always write enough digits by the %g to never create spurious zeros, and for PDF I would just ignore the issue for the moment.) Beside that the sy=0 in trafo.scale silently leads to sy=sx which is still an error and has nothing to do with this discussion. > > Well, the ellipse should just work. Suppose you're using it in a graph > > style with flexible size given by the data values you put in. Like for > > circles in the first graphstyle example. It just shouldn't break. It > > doesn't even break for negative values so why should it for zero or > > something close to zero ... > > I really don't know. But I would tend to attempt preventing PS code > which is not leading to errors. +1 Hence there is such a statement in PLRM, I would suggest to introduce another epsilon for the determinante and a TrafoError to be raised on failure. It sounds a bit like overkill, but its (a) easy to implement, (b) fits into what we're doing elsewhere and (c) should never hurt. Still you can't create an trafo projection (with determinante != 1, i.e. with determinante = 0), but well, that's what's forbidden in PostScript. We can than think about the problem I had with the ellipse and according to the discussion with the arc connector, we should return a "closed line" for a or b being 0 and a circle of radius 0 for a and b being 0. (The being zero should be read as an almost zero taking into account the trafo._epsilon and/or the normpath._epsilon.) And that's it ... 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/ 