## [PyX-user] Points and geometry

 [PyX-user] Points and geometry From: Magnus Lie Hetland - 2004-07-23 14:58:45 ```Hi! I'm writing a little code snippet that does some point calculations (midpoint between two points, random shifts etc.) It seems to me that having a point type (class) would be useful (I'm used to the MetaPost way ;) but I guess maybe there is a way of doing this gracefully in Pyx as well... Should I fiddle with the numbers directly? Use a path element? Perhaps gather the points in a path? Use boxes with zero extent? What's the 'Pyx Way' here? - M -- Magnus Lie Hetland "Canned Bread: The greatest thing since sliced http://hetland.org bread!" [from a can in Spongebob Squarepants] ```

 [PyX-user] Points and geometry From: Magnus Lie Hetland - 2004-07-23 14:58:45 ```Hi! I'm writing a little code snippet that does some point calculations (midpoint between two points, random shifts etc.) It seems to me that having a point type (class) would be useful (I'm used to the MetaPost way ;) but I guess maybe there is a way of doing this gracefully in Pyx as well... Should I fiddle with the numbers directly? Use a path element? Perhaps gather the points in a path? Use boxes with zero extent? What's the 'Pyx Way' here? - M -- Magnus Lie Hetland "Canned Bread: The greatest thing since sliced http://hetland.org bread!" [from a can in Spongebob Squarepants] ```
 Re: [PyX-user] Points and geometry From: Andre Wobst - 2004-07-26 15:34:25 ```Hi, On 23.07.04, Magnus Lie Hetland wrote: > [...] It seems to me that > having a point type (class) would be useful (I'm used to the MetaPost > way ;) but I guess maybe there is a way of doing this gracefully in > Pyx as well... As we started PyX we decided to not introduce a point data type in order to lower the users overhead. Thus you directly use plain numbers (or a PyX length) at various places like in path.moveto() or text.text() instead of first constructing points. We not even started to group together coordinates in tuples (you could think of path.line((x1, y1), (x2, y2)), but we actually decided to use path.line(x1, y1, x2, y2)). So we do not have a proper representation of a point. A path, however, is a pure mathematical object. Especially the normpath (any path can converted to) supports quite some numerical operations (splitting, calcuation of intersection points, etc.). Futhermore the (affine) transformations are mathematical objects. While they also support the transformation of a point by the apply method didn't we introduce a point class here either. > Should I fiddle with the numbers directly? Use a path element? Perhaps > gather the points in a path? Use boxes with zero extent? What's the > 'Pyx Way' here? As I said, I think none of the existing classes should be (miss-)used for your needs. They all do not fit well. A path element is a path element, not a point. Sometimes it might be usefull as a return value, but it still is not a point. You might build up a path, when you want to construct a path in the end, but its not the correct representation of a list of points, because a path also defines, what's "in between" the points. The boxes are something very different (at least I think we'll move them towards the following): A box is an ordinary canvas having a predefined boundary. In the end, boxes will be the primary source for performing clipping operations. Of course, the aligment functionality will be usefull for objects with any kind of border as it is today already for the boxes we have. The connector functionality might become less restricted to boxes in the future. We'll see. So, in the end, we might think about introducing a point class and numerics on points. Especially when we want create some features found in MetaPost. I'm quite open to this discussion. I was asked about MetaPost like features several times already. I'm also willing to spend time on developing the fundamentals, but I think we should start with independend classes in the first. Later on it might become clear, that one should integrate the point class etc. more directly into PyX (i.e. add support into the path class etc.). A related question might be, if the point class (and related things) should support PyX lengths. In favor of PyX I think one should try to do so ... André -- by _ _ _ Dr. André Wobst / \ \ / ) wobsta@..., http://www.wobsta.de/ / _ \ \/\/ / PyX - High quality PostScript figures with Python & TeX (_/ \_)_/\_/ visit http://pyx.sourceforge.net/ ```
 Re: [PyX-user] Points and geometry From: Magnus Lie Hetland - 2004-07-26 21:37:54 ```Andre Wobst : > > Hi, >=20 [snip] > As I said, I think none of the existing classes should be (miss-)used > for your needs. I see. Now that I think about it I believe I actually considered writing some geometry code (including support for points etc.) for Pyx (or, in fact, in general) a while back... Never got around to it, but it might be worth a second look, I guess. My need then was also MetaPost-like features, but more specifically equations (or something as similar to that as possible) and affine transforms of points (also usable in the equations). [snip] > So, in the end, we might think about introducing a point class and > numerics on points. Especially when we want create some features found > in MetaPost. I'm quite open to this discussion. I might throw together some really basic code and we can see how well it works, maybe? (Provided I get around to it; not necessarily a top priority and I'm currently on vacation :) > I was asked about MetaPost like features several times already. I'm > also willing to spend time on developing the fundamentals, but I > think we should start with independend classes in the first. Sure. I'm sure there are several packates for geometry available already; worth investigating, although starting a special-purpose module probably carries a very low cost (and it will most likely have to be integrated with PyX at some point anyway). Using numarray or the like might be useful, perhaps... (Maybe not; but at least they have support for vectors and matrices.) Are the affine transforms in PyX usable for this sort of thing or would one be better off writing a new transform system for the point module? > Later on it might become clear, that one should integrate the point > class etc. more directly into PyX (i.e. add support into the path > class etc.). A related question might be, if the point class (and > related things) should support PyX lengths. In favor of PyX I think > one should try to do so ... I agree. But that could, perhaps be done as a later step? > Andr=E9 --=20 Magnus Lie Hetland "Canned Bread: The greatest thing since sliced http://hetland.org bread!" [from a can in Spongebob Squarepants] ```
 Re: [PyX-user] Points and geometry From: Andre Wobst - 2004-07-27 06:24:01 ```Hi, On 26.07.04, Magnus Lie Hetland wrote: > I might throw together some really basic code and we can see how well > it works, maybe? (Provided I get around to it; not necessarily a top > priority and I'm currently on vacation :) Sure. [snip] > Are the affine transforms in PyX usable for this sort of thing or > would one be better off writing a new transform system for the point > module? I think the transformations already available could be usefull in such a package (its not necessary to reinvent the wheel). OTOH it might be usefull to get the trafo code on hand ... so one might first start to copy the trafo module and adjust the code to whatever is needed. André -- by _ _ _ Dr. André Wobst / \ \ / ) wobsta@..., http://www.wobsta.de/ / _ \ \/\/ / PyX - High quality PostScript figures with Python & TeX (_/ \_)_/\_/ visit http://pyx.sourceforge.net/ ```