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

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: Magnus Lie Hetland <magnus@he...>  20040728 21:49:55

... while we're on the topic (sort of):  Constructive area geometry  Transparency/alpha levels (has been done using MetaPost; could perhaps be ported)  SVM output Oh, wait  that's three things... <wink>  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...>  20040728 20:10:54

Andre Wobst <wobsta@...>: > [snip] > Well, I have to look at MetaPost at some point. If you mean a the language/user level  indeed. Very relevant to PyX. But I guess, perhaps, you mean at the implementation/code level? Well... I guess it's still relevant (although I'm not sure I'd dare venture into that without a good lantern and a trusty sword by my side... Or something :]) > Don't we really want to create a transformation by setting 3 2d > input and output points? That's the canonical problem, I guess. > This is a linear problem. How is it in MetaPost? There's an example on page 32 of the User Manual; the transform T (called T' in the manual) is not yet defined: (0, 1) transformed T =3D (3, 4) (1, 1) transformed T =3D (7, 1) (1, 0) transformed T =3D (4, 3) The solugion to this gives the transform factors txx =3D 4 txy =3D 3 [called tyx in the manual] tyx =3D 3 tyy =3D 4 tx =3D 0 ty =3D 0 But the problem needn't be this straightforward; these equations must be fully integrated with the general equation stuff, of course. For example, on the same page in the manual, the following equations are used to specify that a given (as yet unknown) transform is shapepreserving: txx =3D tyy; tyx =3D txy This automatically only allows rotation, shifting and uniform scaling. This is used in a very neat example on page 33 of the manual (figure 28). > Is it allowed to define write P =3D t*p where the points P and p are > not defined as well as t is not defined? What does MetaPost with > such an equation? Does it store it for later evaluation I don't really know; for each nonlinear term you have to know (*or* be able to figure out through some other linear equation system) one of the two factors before you can start solving things, of course. But how you deal with this in general (i.e. how you know when to solve a certain subset of the equations but not the rest of the equations) I don't know. > (for example until p and P becomes known)? And what about having > several transformations: P =3D t2*t1*p? I would think that would be allowed (as long as you supplied more equations in addition) but I'm not sure. > And what about restricting a transformation to a rotation, for > example? That can certainly be done (see the example above). > I should take a look at MetaPost/MetaFont at some point. Sounds like a good move, indeed :) I guess one of the few reasons I haven't dropped MetaPost is that PyX doesn't quite implement all of its functionality (such as this) yet. :] (Also, it's nice to be able to use the output from MetaPost directly in pdflatex without a hickup; if PyX could restrict itself to the same subset of EPS, possibly with a switch, such as mps=3DTrue or something, that would be very nice :}) > Andr=E9 =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...>  20040728 19:54:02

Andre Wobst <wobsta@...>: > > (BTW: it is neither very complicated to change this at a later > point, nor would it be visible to the outside world. So I can live > this this issue quite well as it currently is  independing from > what you're telling me ;).) That's fine  as long as you know what you're doing (and you do, of course, know your code much better than me). :) I've just had a deeprooted fear and loathing for type checking instilled in me by Alex Martelli ;) [snip] > Right. Don't take the isinstance code too serios right now. I added > quite some isinstance checks and assert checks to help me getting it > running properly. Quite all right. > Andr=E9 =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...>  20040728 19:51:25

Andre Wobst <wobsta@...>: > > Hi, >=20 [snip] > Ok, lets do some ASCII art (is it art?): >=20 > /x'\ /a b\/x\ /e\ >   =3D    +   > \y'/ \c d/\y/ \f/ >=20 > 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. >=20 > You may, at a later point, find out, that you already know the value > of x, for example. Than the term becomes linear ... Ah, right. Indeed. Intuitively it just seems underdetermined if you're trying to find out the transform *and* the points, even if you know enough to make it, say, a quadratic problem (or something). In practical applications I guess you'd always(?) know enough about the points to get rid of such nonlinear terms. > And I think, that's what needs to be coded. Right. I have no idea (off the top of my head, at least) how one would deal with that; just a bit of bookkeeping, perhaps? ;) [snip] > Or just think what we can code right now after thinking about the > problem. I think its not that complex. Sounds good. > 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. Sounds like a clever move. > Once a or x becomes available by other means, the "nonlinear > variable" can be resolved and a linear equation is restored. Yeah  a bit of bookkeeping, still... > What's also needed are equations for 2d points etc., but those might > be build on top of the term class as well. I'm dealing with these email out of order, so I guess this part is already solved (by your vector equation code). > So I think, yes, we can really get this working ... Wohoo! :) [snip] > Andr=E9 >=20 > 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.) Heh. It works, for now; just thought I'd mention it. Perhaps the code can be made more generic at some later stage (so that I can, for example, multiply terms by a numberlike class without having to subclass int or the like). BTW: Unless you're targeting old Pythons (maybe you are?) you don't have to use types.IntType and the like; just use int (and float and long). e.g. isinstance(foo, (int, float, long)). (No big point, as types.IntType is simply int and so forth.) =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...>  20040728 19:42:48

Andre Wobst <wobsta@...>: > > Hi, >=20 > On 28.07.04, Andr=E9 Wobst wrote: > > Update of /cvsroot/pyx/pyx/test/experimental > > In directory sc8prcvs1.sourceforge.net:/tmp/cvsserv13287 > >=20 > > Modified Files: > > solve.py=20 > > Log Message: > > vector equations (can be mixed with scalar equations) > [snip] >=20 > I've just checked in another update to the experimental linear > equation solver. You can now mix all kind of vector and scalar > equations. Sounds very cool. This basically means that most of the needed (basic) geometry functionality is in place, then... (It still would be nice to have access to the first three dimensions of vectors as v.x, v.y and v.z but that's just a minor convenience.) It would be interesting to see what could be done with the transform equations... But even without them, stuff like "the difference between a and b is equal to the difference between c and d" and the like is very useful. I couldn't get the vector stuff from CVS it seems  maybe it's just the anonymous CVS caching that's a bit slow again. > But I'm not quite sure whether the "=3D=3D" notation is a good > idea, i.e. will work well in nontrivial code. My biggest concerns are > in the area of usuability, i.e. is it too implicit? Comments? (I replied to the "=3D=3D" part elsewhere.) > Andr=E9 =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...>  20040728 19:38:48

Joerg Lehmann <joergl@...>: > [snip] > IMHO it's too implicit. In particular, not having to explicitly specify > the solver is probably not a good idea.=20 I think using =3D=3D for anything with sideeffects (or even anything tha= t isn't interpretable as a boolean equality check) is quite unfortunate. It might *look* good, but still... (if x =3D=3D y: alwaysexecuted()...) Using a method or function may be a bit more verbose but still much better, IMO. We don't really have much to complain about; the Java people have to use foo.equals(bar) where we can use foo =3D=3D bar :) I think solver.equate(x, y) or something similar (e.g. "equals", "equal", "eq") would be better. If one was feeling adventurous, one could even do stuff like solver(x =3D y) but only for singlevariable lefthandsides, of course. It would be possible to do some property magic too... I'm pretty sure I could write code such that a.x =3D b.y a.y =3D b.x could be turned into a set of equations (by using wrapper classes around the objects returned by the properties, somewhat like bound methods). Just musing. > 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...>  20040728 17:52:49

Hi André, On 28.07.04, Andre Wobst wrote: [snip] > I've just checked in another update to the experimental linear > equation solver. You can now mix all kind of vector and scalar > equations. Nice! > But I'm not quite sure whether the "==" notation is a good > idea, i.e. will work well in nontrivial code. My biggest concerns are > in the area of usuability, i.e. is it too implicit? Comments? IMHO it's too implicit. In particular, not having to explicitly specify the solver is probably not a good idea. Jörg 
From: Andre Wobst <wobsta@us...>  20040728 17:02:14

Hi, On 28.07.04, André Wobst wrote: > Update of /cvsroot/pyx/pyx/test/experimental > In directory sc8prcvs1.sourceforge.net:/tmp/cvsserv13287 > > Modified Files: > solve.py > Log Message: > vector equations (can be mixed with scalar equations) [snip] I've just checked in another update to the experimental linear equation solver. You can now mix all kind of vector and scalar equations. But I'm not quite sure whether the "==" notation is a good idea, i.e. will work well in nontrivial code. My biggest concerns are in the area of usuability, i.e. is it too implicit? Comments? 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...>  20040728 06:23:26

Hi, On 27.07.04, Magnus Lie Hetland wrote: > So, here is a version which uses André'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 :). Hey, isn't that something for tryimportexcept? No isinstance available ... ;) > So, presto, we've got a bidirectional thingy. Note that the angle in > the transform is still a constant, though. As André 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. Well, I have to look at MetaPost at some point. Don't we really want to create a transformation by setting 3 2d input and output points? This is a linear problem. How is it in MetaPost? Is it allowed to define write P = t*p where the points P and p are not defined as well as t is not defined? What does MetaPost with such an equation? Does it store it for later evaluation (for example until p and P becomes known)? And what about having several transformations: P = t2*t1*p? And what about restricting a transformation to a rotation, for example? I should take a look at MetaPost/MetaFont at some point. 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...>  20040728 06:09:52

Hi, On 27.07.04, Magnus Lie Hetland wrote: > 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. First of all, I agree to you, that we should use tryexcept clauses instead of isinstance almost everywhere. But we do (maybe missuse) the class structure and isinstance in one place, where I think its worth to be discussed in order to make clear, whether its a design mistake from the very beginning. I'm not so sure. Let me explain it a little. It's related to the attribute system. Suppose you call the fill method or the draw method of a canvas and provide some additional attributes like colors, linewidths, linestyles, patterns, etc. (Additionally, the fill and draw methods can take some decorators, which might add other stuff (like arrows) and shorten the path (for the head of the arrow and the like). BTW Jörg, Michael: we wanted to restrict ourselfs to not really modify the original path anymore by decorators, which are now called deformers. Did anybody the coding for that? The decorated path should be simplified in that sense. We need to come back to that issue at some point. Maybe in Basel, Jörg? But back to the draw and fill attributes.) So what we did is, we introduced a strokestyle and fillstyle class, which is used as a mixin to certain attributes. The idea is, that a color can be used as a stroke as well as a fill style, while a line width is usefull when stroking only. Once we mixin the strokestyle and/or fillstyle class, we can use isinstance to check, whether the style is appropriate to be used at a given point. (Isn't that's what Jim Fulton always says, that __implements__ is something else that a position in a class hierarchy.) I know, that we created some restriction here: you can't derive a class from, say, the line width, which will not be a stroke attribute anymore. But I don't care (we really don't need to take care). I think, at this very point, the isinstance is the most simple check possible. We could define some "askwhatitis" functionality on attributes as a whole, but I'm not sure we really need this. (BTW: it is neither very complicated to change this at a later point, nor would it be visible to the outside world. So I can live this this issue quite well as it currently is  independing from what you're telling me ;).) (As a side remark: The merging an clearingfunctionality of the attributes is based on isinstance as well ...) > 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. Right. Don't take the isinstance code too serios right now. I added quite some isinstance checks and assert checks to help me getting it running properly. André  by _ _ _ Dr. André Wobst / \ \ / ) wobsta@..., http://www.wobsta.de/ / _ \ \/\/ / PyX  High quality PostScript figures with Python & TeX (_/ \_)_/\_/ visit http://pyx.sourceforge.net/ 