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}

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

_{Mar}

_{Apr}
(1) 
_{May}

_{Jun}
(4) 
_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}
(2) 
_{Dec}
(6) 
2016 
_{Jan}
(4) 
_{Feb}
(10) 
_{Mar}
(4) 
_{Apr}
(3) 
_{May}

_{Jun}

_{Jul}

_{Aug}
(3) 
_{Sep}
(4) 
_{Oct}
(2) 
_{Nov}

_{Dec}

2017 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}
(4) 
_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 





1

2

3

4

5

6
(1) 
7
(2) 
8

9

10

11

12

13
(1) 
14
(3) 
15

16

17

18

19

20

21

22
(8) 
23
(1) 
24

25

26

27
(13) 
28
(10) 
29
(23) 
30
(4) 
31

From: Andre Wobst <wobsta@us...>  20040727 20:18:19

Hi Magnus, On 27.07.04, Magnus Lie Hetland wrote: > Luckily, I couldn't quite stop playing around with this... As for me. I was offline the last hours I noticed you posting just now. I'll take a look at your ideas tomorrow. In the mean I've posted an updated version of my solve.py ... André  by _ _ _ Dr. André Wobst / \ \ / ) wobsta@..., http://www.wobsta.de/ / _ \ \/\/ / PyX  High quality PostScript figures with Python & TeX (_/ \_)_/\_/ visit http://pyx.sourceforge.net/ 
From: Andre Wobst <wobsta@us...>  20040727 20:13:18

Hi, On 27.07.04, Magnus Lie Hetland wrote: > I know the curves are > nonlinear... I just (naïvely ;) thought that, perhaps, through some > transformational magic the problem could be solved within the same > framework of linear equations. I don't think so. The intersection of two bezier curves is solved numerically. (Or may be by solving a polynom of grad three.) In case you want to take a look into MetaPost (I would like to learn more about that). Is it really possible to say: transform a path by a not yet completely defined transformation, so that an intersection point with another path is located at a y coordinate with a certain value? I just think you can't transform a path with a not yet completely defined transformation. It becomes too complicated. But, of course, what you can do for sure is to transform a point by a not yet completely defined transformation. This is how you can define a transformation by saying this point goes into this and a second one into another one etc. > [snip] > > Say p and p' are (2d) points, and t is a transformation (i.e. a 2x2 > > matrix + a 2d vector). Then you can write > > > > p' = t(p) > > > > Once you say p' and p are lazy vectors (i.e. they contain 2 variables) > > as well as t is a lazy transformation (i.e. it contain 6 variables), > > than the equation above is nonlinear. There are nonlinear terms in > > matrix times vector when they both contain variables. > > Right  you're basically saying that this isn't linear in the > elements of the transform? But if we freeze the transform it is linear > in p' and p...? Ok, lets do some ASCII art (is it art?): /x'\ /a b\/x\ /e\   =    +   \y'/ \c d/\y/ \f/ If you do not define the transformation matrix (i.e. the variables a, b, c, and d) and you also keep the point p, i.e. x and y, variable, the left hand side contains terms like a*x, which is nonlinear. You may, at a later point, find out, that you already know the value of x, for example. Than the term becomes linear ... And I think, that's what needs to be coded. > This seems quite muddled. I'm not very tempted to read the MetaPost > source code to find out how they do it either; I guess maybe I can > snoop around and see if I find some other pointers on how to do this > sort of thing. Or just think what we can code right now after thinking about the problem. I think its not that complex. Those nonlinear terms might be hidden in some additional "nonlinear variable" in a code along the lines I've started. Should be possible. Just replace a*x by AX and keep on going. Once a or x becomes available by other means, the "nonlinear variable" can be resolved and a linear equation is restored. What's also needed are equations for 2d points etc., but those might be build on top of the term class as well. So I think, yes, we can really get this working ... I've worked on my solver code a bit further. You can find an updated version enclosed. It solves equations "on the fly" and it also tries to solve equations as soon as possible (it searches for decoupled systems of equations). I've just checked it into the CVS under test/experimental/solve.py as well ... André PS: I've also seen your comment about isinstance. Right. Currently I'm using it in this solver code to differenciate in __add__ etc. between the different types. Not yet perfect, right ... ;) (I've the Python Cookbook and read about isstring, yes.)  by _ _ _ Dr. André Wobst / \ \ / ) wobsta@..., http://www.wobsta.de/ / _ \ \/\/ / PyX  High quality PostScript figures with Python & TeX (_/ \_)_/\_/ visit http://pyx.sourceforge.net/ 
From: Magnus Lie Hetland <magnus@he...>  20040727 17:52:28

Luckily, I couldn't quite stop playing around with this... My first thought was to rewrite everything, writing custom stuff to integrate the linear equation solving stuff and my lazy points. I guess that is still an option, but I decided to do a very simple version instead. So, here is a version which uses Andr=E9's linear equation stuff (although I've switched to numarray  it's what I use; and numarray 1.0 is out now, so... Hooray for that :). A point is simply a list of variables. By using ordinary list notation, such as p[0] one gets at these variables (their values are available through p[0].value and so forth) but by using the syntactic sugar p.x (or p.y or p.z) one gets (or sets) their values. For general dimensions beyond the third, use p.get(dim) or p.set(dim, val) (or, equivalently, p[dim].value and p[dim].value =3D val). The lsys class is a simple wrapper that handles left and right hand sides with more than one element (for multidimensional equations). There is precious little one can do directly with points at the moment (such as addition/multiplication) but adding that should be easy. I've added a single transformation as an example: """ def rotated(point, a): assert len(point) =3D=3D 2 # To keep it simple :) return (point[0]*cos(a)point[1]*sin(a), point[1]*cos(a)+point[0]*sin(a)) """ Note that this works with the *variables*, not their *values*. Thus, one can use this transform either way in an equation: """ from geom import * from math import pi a =3D pt() b =3D pt() c =3D pt() eqs =3D lsys() a.x =3D 0 a.y =3D 10 eqs.eq(a, rotated(b, pi/2)) eqs.eq(c, rotated(a, pi/2)) eqs.solve() print b.x, b.y # Prints out 10.0 0.0 print c.x, c.y # Prints out 10.0 0.0 """ So, presto, we've got a bidirectional thingy. Note that the angle in the transform is still a constant, though. As Andr=E9 pointed out, if the angle is to be a variable, we'd end up getting equations with sin() and cos(), and that's not exactly pleasant. So, this code is still sort of hackish, but it's a starting point that actually works... And that's always good, isn't it? :) =20 Magnus Lie Hetland "Canned Bread: The greatest thing since sliced http://hetland.org bread!" [from a can in Spongebob Squarepants] 
From: Magnus Lie Hetland <magnus@he...>  20040727 17:42:09

Joerg Lehmann <joergl@...>: > [snip] > You're right, this should not be the case. Sometimes, however, we > introduced some checks such that the user doesn't get hit by some > strange error when he calls writeEPSfile. Checks are good. I guess I'm just saying that more flexible (i.e. signaturebased) checks could be used instead. > For instance, we check whether the arguments passed to some canvas > methods are of a certain type. I don't think this is necessarily > bad. See for instance the insert and set method of the > canvas._canvas class for two examples. The best solution here, IMO, (in an ideal world ;) would be to use either (1) interfaces or (2) protocol adaptation. There are PEPs for both, but I'm not sure whether either will ever become standard Python. (I guess interfaces have the best chance, even though adaptation is much cooler ;) If the API is simple one could check manually (as with the helper functions for strings etc.; you could write similar ones to check whether something seems to be a good canvas). I guess in these cases a simple isinstance might be easier. After all, we *do* have multiple inheritance, so one could always just subclass the needed class as if it were an interface. > > Such typebased discrimination <wink> is in most cases necessary; if > > an object can do the job, just let it. > > > > (Often, using polymorphism directly, i.e. simply calling a method on > > the given object, would be better than using an if statement checking > > properties on the object. That's not feasible in special cases such a= s > > this, where you have to deal with numbers and strings and the like, o= f > > course.) >=20 > Again, you're right  which unfortunately does not mean that the code i= s > perfect in this sense  it developped over quite some time... So if > there are some points where you think the present code can be improved > in this regard, feel free to point them out (or just send a patch). The reason I noticed this was that I saw plenty of isinstance() calls in the linear equation code  might be inconvenient if one wanted to mix in multidimensional points between the variables and numbers it already knows about, because, basically, the "aren't allowed" in there. No big deal, though. If it turns out to be problematic, I can always fiddle a bit with the code, I guess :) > J=F6rg =20 Magnus Lie Hetland "Canned Bread: The greatest thing since sliced http://hetland.org bread!" [from a can in Spongebob Squarepants] 
From: Joerg Lehmann <joergl@us...>  20040727 17:02:34

On 27.07.04, Magnus Lie Hetland wrote: [snip] > OK, let's take a look at that as an example... Ok, but as I said, the code in CVS is completely different. Maybe I should have picked another example... > First of all, it uses helper.isstring and helper.isnumber, both of > which use the Leap Before You Look idiom  I have no quarrels with > them. That is not type checking/type based polymorphism. This is how > it *should* be done <wink> > > The only use of isintance here is: > > if isinstance(l, length): > self.length = l.length > elif helper.isstring(l): > # ... > > Why is this check necessary? Why not use something like this (possibly > wrapped in helper.islength or something, if desired): > > try: > self.length = l.length > except AttributeError: > if helper.isstring(l): > # ... > > Then, if I decided to implement my own lengthlike class which > supplied the required length attribute (which is, after all, all > that's required) it would work nicely. > > The only thing you achieve by using isintance instead is to close the > door in my face  "no wannabe lengths permitted". You're right, this should not be the case. Sometimes, however, we introduced some checks such that the user doesn't get hit by some strange error when he calls writeEPSfile. For instance, we check whether the arguments passed to some canvas methods are of a certain type. I don't think this is necessarily bad. See for instance the insert and set method of the canvas._canvas class for two examples. > Such typebased discrimination <wink> is in most cases necessary; if > an object can do the job, just let it. > > (Often, using polymorphism directly, i.e. simply calling a method on > the given object, would be better than using an if statement checking > properties on the object. That's not feasible in special cases such as > this, where you have to deal with numbers and strings and the like, of > course.) Again, you're right  which unfortunately does not mean that the code is perfect in this sense  it developped over quite some time... So if there are some points where you think the present code can be improved in this regard, feel free to point them out (or just send a patch). Jörg 
From: Magnus Lie Hetland <magnus@he...>  20040727 16:46:58

Joerg Lehmann <joergl@...>: > [snip] > Another typical use of isinstance is to implement some type based > polymorphism. For instance, if you pass some object to a function and > this function checks in which way he can deal with this object. Sure  but in Python the Right Thing(tm) in most cases isn't typebase polymorphism, but signaturebased polymorphism. If something quacks like a duck, you treat it like a duck. It doesn't really have to *be* a duck. (Someone might have implemented a duckrobot, for example, and it would be impolite not to let them use that instead :) > Here, I have to admit, I'm not always sure about the Python way of > doing things like that... A typical example was the constructor of > the unit.length class (only in the released PyX versions), which was > able to convert nearly anything to a length. In CVS we already got > rid of that... OK, let's take a look at that as an example... First of all, it uses helper.isstring and helper.isnumber, both of which use the Leap Before You Look idiom  I have no quarrels with them. That is not type checking/type based polymorphism. This is how it *should* be done <wink> The only use of isintance here is: if isinstance(l, length): self.length =3D l.length elif helper.isstring(l): # ... Why is this check necessary? Why not use something like this (possibly wrapped in helper.islength or something, if desired): try: self.length =3D l.length except AttributeError: if helper.isstring(l): # ... Then, if I decided to implement my own lengthlike class which supplied the required length attribute (which is, after all, all that's required) it would work nicely. The only thing you achieve by using isintance instead is to close the door in my face  "no wannabe lengths permitted". Such typebased discrimination <wink> is in most cases necessary; if an object can do the job, just let it. (Often, using polymorphism directly, i.e. simply calling a method on the given object, would be better than using an if statement checking properties on the object. That's not feasible in special cases such as this, where you have to deal with numbers and strings and the like, of course.) > J=F6rg =20 Magnus Lie Hetland "Canned Bread: The greatest thing since sliced http://hetland.org bread!" [from a can in Spongebob Squarepants] 
From: Joerg Lehmann <joergl@us...>  20040727 16:25:37

Hi Magnus, On 27.07.04, Magnus Lie Hetland wrote: > Just a general comment on the use of isinstance  I think it's best > avoided when possible. Type checking breaks polymorphism... Signature > checking or the "leap before you look" paradigm are, IMO, more > Pythonic. Just noticed a few isintance calls in the code here and > there  just thought I'd pipe in. Feel free to ignore :) In general, you're right  and there are probably some places where avoiding isinstance would be better. However, there are some places where this is not so easy, and a simple isinstance is clearer than code which tries to generalize even the special case. Sometimes we also check for instances of a specific class to throw an exception already quite early. In principle this is not necessary, but believe me, it helps when you now early on that you did something wrong... Another typical use of isinstance is to implement some type based polymorphism. For instance, if you pass some object to a function and this function checks in which way he can deal with this object. Here, I have to admit, I'm not always sure about the Python way of doing things like that... A typical example was the constructor of the unit.length class (only in the released PyX versions), which was able to convert nearly anything to a length. In CVS we already got rid of that... Jörg 
From: Magnus Lie Hetland <magnus@he...>  20040727 16:07:20

Just a general comment on the use of isinstance  I think it's best avoided when possible. Type checking breaks polymorphism... Signature checking or the "leap before you look" paradigm are, IMO, more Pythonic. Just noticed a few isintance calls in the code here and there  just thought I'd pipe in. Feel free to ignore :)  Magnus Lie Hetland "Canned Bread: The greatest thing since sliced http://hetland.org bread!" [from a can in Spongebob Squarepants] 
From: Magnus Lie Hetland <magnus@he...>  20040727 15:43:32

Just somewhat related  the constraint package of logilab: http://www.logilab.org/projects/constraint/documentation It only works with finite domains and isn't very fast, I believe. Might still be a source of inspiration; I don't know :}  Magnus Lie Hetland "Canned Bread: The greatest thing since sliced http://hetland.org bread!" [from a can in Spongebob Squarepants] 
From: Magnus Lie Hetland <magnus@he...>  20040727 15:27:11

Andre Wobst <wobsta@...>: > [snip] > BTW: I didn't wrote a linear equation solver, but what I did was > exactly a "variable class" and the "linear equations behind the > scenes", i.e. building up linear terms. To actually solve the linear > equations I used Numeric in my sample code already. I noticed that when I looked at the code :) I've actually seens some similar code somewhere else before (the code I mentioned earlier)  and I've written similar things too (also related to logic programming and the like). Seems like (possibly) a reasonable approach. > > Certainly. It would also be neat to be able to use parametrized curve= s > > in the same system, as in MetaPost; but I guess it's not quite that > > critical, as you already have support for finding intersections > > in PyX. >=20 > Finding intersections etc. is usually a nonlinear operation. But you > can define points by that ... sure. I guess it will be similar to > MetaPost in that respect (though I'm not quite sure right now). I don't know how MetaPost does it either. I know the curves are nonlinear... I just (na=EFvely ;) thought that, perhaps, through some transformational magic the problem could be solved within the same framework of linear equations. I guess finding out how MetaPost actually does this might be quite useful. [snip] > Say p and p' are (2d) points, and t is a transformation (i.e. a 2x2 > matrix + a 2d vector). Then you can write >=20 > p' =3D t(p) >=20 > Once you say p' and p are lazy vectors (i.e. they contain 2 variables) > as well as t is a lazy transformation (i.e. it contain 6 variables), > than the equation above is nonlinear. There are nonlinear terms in > matrix times vector when they both contain variables. Right  you're basically saying that this isn't linear in the elements of the transform? But if we freeze the transform it is linear in p' and p...? > So I think what one has to do is to postpone this nonlinear equation > until the nonlinear terms are solved by other constraints. I guess, > thats what MetaPost does as well ... as soon as p or t gets defined > somewhere else, the equation above becomes linear. Well, you certainly can't solve an underdetermined set of equations anyway, whether they're linear or not :) I guess the problem will be writing it up as a set of linear equations (i.e. in matrix form). What you're saying is that we can't really do this before either p, p' of t has been determined by other means? This seems quite muddled. I'm not very tempted to read the MetaPost source code to find out how they do it either; I guess maybe I can snoop around and see if I find some other pointers on how to do this sort of thing. Does anyone know of any other systems/sources of information than MetaPost? > > Anyway, writing a system like this based on linear equations is a > > bit more work than a oneway functionbased one. I'll have a look > > but I can't promise anything. >=20 > Sure, nobody does. But we might have a starting point now ... and > maybe somebody is really interested in this. Well, I'd be very interested in having it available :] > Its not top priority for me, but well, on the other hand, I already > like it ... we can get something really funny quite quickly I guess. I guess. The problem is laying the foundation in such a way as not to proclude the kind of future development we might want (e.g. full linear equation solver linked to parametric curves and transforms) without falling into the paralyzing trap of hypergeneralization (which I know all to well  and I've got the scars to prove it ;) I'll think a bit about whether it's possible to a very simple thing here (a "Smallest Thing That Could Possibly Work" kind of thing)  beyond what we already have, of course. > Andr=E9 =20 Magnus Lie Hetland "Canned Bread: The greatest thing since sliced http://hetland.org bread!" [from a can in Spongebob Squarepants] 
From: Andre Wobst <wobsta@us...>  20040727 12:10:43

Hi, On 27.07.04, Magnus Lie Hetland wrote: > > > Equal(b, a + Point(10, 0)) > > > > I just couldn't resist: A linear equation solver can be easily build > > like this. > > I know  I've thought about this myself in the past, and I've even > found code that does this sort of thing. I don't remember exactly > where, but it had a variable class and did all the linear equations > behind the scenes. > > Also, numarray (and Numeric) has support for the equation solving > part; I guess they could be optional mechanisms for speed, if this is > indeed the way to go. BTW: I didn't wrote a linear equation solver, but what I did was exactly a "variable class" and the "linear equations behind the scenes", i.e. building up linear terms. To actually solve the linear equations I used Numeric in my sample code already. > Certainly. It would also be neat to be able to use parametrized curves > in the same system, as in MetaPost; but I guess it's not quite that > critical, as you already have support for finding intersections > in PyX. Finding intersections etc. is usually a nonlinear operation. But you can define points by that ... sure. I guess it will be similar to MetaPost in that respect (though I'm not quite sure right now). > > My grasp tells me, that a transformation contains another set of > > variables (6 for a 2d>2d affine transformation). When multiplying > > with a (lazy) point (two variables) the system becomes nonlinear. > > I'm kind of confused at the moment ... ;) > > Hm. No, I don't think so... If you say that one point, transformed by > an affine transform, equals another point, all you have is a linear > set of two equations in two variables  no? Say p and p' are (2d) points, and t is a transformation (i.e. a 2x2 matrix + a 2d vector). Then you can write p' = t(p) Once you say p' and p are lazy vectors (i.e. they contain 2 variables) as well as t is a lazy transformation (i.e. it contain 6 variables), than the equation above is nonlinear. There are nonlinear terms in matrix times vector when they both contain variables. So I think what one has to do is to postpone this nonlinear equation until the nonlinear terms are solved by other constraints. I guess, thats what MetaPost does as well ... as soon as p or t gets defined somewhere else, the equation above becomes linear. > Anyway, writing a system like this based on linear equations is a bit > more work than a oneway functionbased one. I'll have a look but I > can't promise anything. Sure, nobody does. But we might have a starting point now ... and maybe somebody is really interested in this. Its not top priority for me, but well, on the other hand, I already like it ... we can get something really funny quite quickly I guess. André  by _ _ _ Dr. André Wobst / \ \ / ) wobsta@..., http://www.wobsta.de/ / _ \ \/\/ / PyX  High quality PostScript figures with Python & TeX (_/ \_)_/\_/ visit http://pyx.sourceforge.net/ 
From: Magnus Lie Hetland <magnus@he...>  20040727 11:27:24

Andre Wobst <wobsta@...>: > > Hi, >=20 > I'm moving my posting to pyxdevel ... I think its a much better place > to post the following code. (Magnus, you're listing here, don't you? I > think I remember your name from when I looked at the subscriber list > quite some time ago.) Sure. I didn't quite remember myself, which is why I used pyxuser... But, yes, I'm on pyxdevel as well. > On 27.07.04, Andre Wobst wrote: > > Beside that my main concern is, whether its enough to stick on this > > strict assignments. This is quite a limitation. We can't compete to > > MetaPost by that (but we want, don't we?). I'm not sure whether its > > possible to cook it all down to an Equalityfunction: > >=20 > > Equal(b, a + Point(10, 0)) >=20 > I just couldn't resist: A linear equation solver can be easily build > like this. I know  I've thought about this myself in the past, and I've even found code that does this sort of thing. I don't remember exactly where, but it had a variable class and did all the linear equations behind the scenes. Also, numarray (and Numeric) has support for the equation solving part; I guess they could be optional mechanisms for speed, if this is indeed the way to go. > Find some code enclosed. You may consider to go along that line > (just in case you want to spend some time on this issue). I might. This is sort of an issue that crops up every now and then for me (i.e. every time I want to create a figure, basically ;) > I think, a 2dpoint can be build on top of this already by combining > two variables. Certainly. It would also be neat to be able to use parametrized curves in the same system, as in MetaPost; but I guess it's not quite that critical, as you already have support for finding intersections in PyX. > The same for higher dimension points. I'm not totally sure whether a > transformation can be easily integrated in that concept. Well, if we use a general matrixbased version, it's all good. (Haven't looked at your code  it might work just as well.) That is, an affine transform are basically just added terms to the linear equations. And it would be *very* useful to allow them... E.g. "this point rotated around that point by 60 degrees equals this point rotated around that point by 30 degrees" and the like. > My grasp tells me, that a transformation contains another set of > variables (6 for a 2d>2d affine transformation). When multiplying > with a (lazy) point (two variables) the system becomes nonlinear. > I'm kind of confused at the moment ... ;) Hm. No, I don't think so... If you say that one point, transformed by an affine transform, equals another point, all you have is a linear set of two equations in two variables  no? Not sure what you mean by "multiplying with a [...] point" here, though. I may be missing something :] Anyway, writing a system like this based on linear equations is a bit more work than a oneway functionbased one. I'll have a look but I can't promise anything. > Andr=E9 =20 Magnus Lie Hetland "Canned Bread: The greatest thing since sliced http://hetland.org bread!" [from a can in Spongebob Squarepants] 
From: Andre Wobst <wobsta@us...>  20040727 09:11:13

Hi, I'm moving my posting to pyxdevel ... I think its a much better place to post the following code. (Magnus, you're listing here, don't you? I think I remember your name from when I looked at the subscriber list quite some time ago.) On 27.07.04, Andre Wobst wrote: > Beside that my main concern is, whether its enough to stick on this > strict assignments. This is quite a limitation. We can't compete to > MetaPost by that (but we want, don't we?). I'm not sure whether its > possible to cook it all down to an Equalityfunction: > > Equal(b, a + Point(10, 0)) I just couldn't resist: A linear equation solver can be easily build like this. Find some code enclosed. You may consider to go along that line (just in case you want to spend some time on this issue). I think, a 2dpoint can be build on top of this already by combining two variables. The same for higher dimension points. I'm not totally sure whether a transformation can be easily integrated in that concept. My grasp tells me, that a transformation contains another set of variables (6 for a 2d>2d affine transformation). When multiplying with a (lazy) point (two variables) the system becomes nonlinear. I'm kind of confused at the moment ... ;) André  by _ _ _ Dr. André Wobst / \ \ / ) wobsta@..., http://www.wobsta.de/ / _ \ \/\/ / PyX  High quality PostScript figures with Python & TeX (_/ \_)_/\_/ visit http://pyx.sourceforge.net/ 