Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Rightclick on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
From: Joerg Lehmann <joergl@us...>  20041012 11:48:22

Hi Magnus, On 12.10.04, Magnus Lie Hetland wrote: [ snip ] > Right. After discovering that the functions were called topm etc. (and > not to_pm, as in the docs) I got this to work... The docs are already fixed  hopefully the next release will come soon. > But only after I created a line and got its start and end points and > subtracted their xcoordinates. I tried simply creating a length from > a number and then converting that to points, but got the wrong > answer... > > What I had was basically this the coordinates (i.e. my parameters, as > plain ints) and the result of somePath.begin() etc. and tried to mix > these... That didn't work well, even though I used the same numbers as > parameters when constructing somePath. I guess I'm just confused by > the unit system, but it seems odd that the numbers were interpreted > differently... Numbers are always interpreted as user lengths in the default_unit (normally cm). I'm not sure what went wrong in your case. Could you post an example? Jörg 
From: Magnus Lie Hetland <magnus@he...>  20041011 14:12:03

Hi! If I want to find the ratio between two lengths (instanses of unit.length), what's the "standard" way of doing that? It seems that (for some reason) direct division isn't allowed...  Magnus Lie Hetland Fallen flower I see / Returning to its branch http://hetland.org Ah! a butterfly. [Arakida Moritake] 
From: Joerg Lehmann <joergl@us...>  20041011 14:49:45

Hi Magnus, [oops, forgot to CC the list] On 11.10.04, Magnus Lie Hetland wrote: > If I want to find the ratio between two lengths (instanses of > unit.length), what's the "standard" way of doing that? It seems that > (for some reason) direct division isn't allowed... The standard procedure is to first convert the lengths into an arbitrary unit (using unit.topt or whatever you like) and then divide the resulting numbers. But in principle, we could support the division of two lengths  at least at the moment, I don't see any real reason why this should not be possible. Jörg 
From: Michael J Gruber <michaeljgruber@fa...>  20041011 15:36:28

Joerg Lehmann venit, vidit, dixit 20041011 16:48: > Hi Magnus, > > [oops, forgot to CC the list] > > On 11.10.04, Magnus Lie Hetland wrote: > >>If I want to find the ratio between two lengths (instanses of >>unit.length), what's the "standard" way of doing that? It seems that >>(for some reason) direct division isn't allowed... > > > The standard procedure is to first convert the lengths into an arbitrary > unit (using unit.topt or whatever you like) and then divide the > resulting numbers. But in principle, we could support the division of > two lengths  at least at the moment, I don't see any real reason why > this should not be possible. I submitted code which did that a while ago. I remember it was refused because this would force implicit "conversion of the units", i.e. application of scale factors at the time when __div__ is used. I'm not sure why this is a problem, but I'm not sure either whether I understand the lengths in PyX ;) Michael 
From: Joerg Lehmann <joergl@us...>  20041011 16:05:15

Hi Michael, On 11.10.04, Michael J Gruber wrote: > Joerg Lehmann venit, vidit, dixit 20041011 16:48: > >On 11.10.04, Magnus Lie Hetland wrote: > > > >>If I want to find the ratio between two lengths (instanses of > >>unit.length), what's the "standard" way of doing that? It seems that > >>(for some reason) direct division isn't allowed... > > > >The standard procedure is to first convert the lengths into an arbitrary > >unit (using unit.topt or whatever you like) and then divide the > >resulting numbers. But in principle, we could support the division of > >two lengths  at least at the moment, I don't see any real reason why > >this should not be possible. > > I submitted code which did that a while ago. I remember it was refused > because this would force implicit "conversion of the units", i.e. > application of scale factors at the time when __div__ is used. I'm not > sure why this is a problem, but I'm not sure either whether I understand > the lengths in PyX ;) Yes, I remember that you've suggested the same some time ago and that we have rejected your patch because of the implicit conversion which is necessary to calculate the ratio. But thinking about it again, I'm not sure whether this is a real problem. In fact, I don't think it is one. The only thing which clearly doesn't make sense is the multiplication of two lengths. So feel free to submit your patch again. Jörg 
From: Magnus Lie Hetland <magnus@he...>  20041012 09:26:33

Joerg Lehmann <joergl@...>: > > Hi Magnus, >=20 > [oops, forgot to CC the list] >=20 > On 11.10.04, Magnus Lie Hetland wrote: > > If I want to find the ratio between two lengths (instanses of > > unit.length), what's the "standard" way of doing that? It seems that > > (for some reason) direct division isn't allowed... >=20 > The standard procedure is to first convert the lengths into an arbitrar= y > unit (using unit.topt or whatever you like) and then divide the > resulting numbers. But in principle, we could support the division of > two lengths  at least at the moment, I don't see any real reason why > this should not be possible. Right. After discovering that the functions were called topm etc. (and not to_pm, as in the docs) I got this to work... But only after I created a line and got its start and end points and subtracted their xcoordinates. I tried simply creating a length from a number and then converting that to points, but got the wrong answer... What I had was basically this the coordinates (i.e. my parameters, as plain ints) and the result of somePath.begin() etc. and tried to mix these... That didn't work well, even though I used the same numbers as parameters when constructing somePath. I guess I'm just confused by the unit system, but it seems odd that the numbers were interpreted differently... > J=F6rg =20 Magnus Lie Hetland Fallen flower I see / Returning to its branch http://hetland.org Ah! a butterfly. [Arakida Moritake] 
From: Joerg Lehmann <joergl@us...>  20041012 11:48:22

Hi Magnus, On 12.10.04, Magnus Lie Hetland wrote: [ snip ] > Right. After discovering that the functions were called topm etc. (and > not to_pm, as in the docs) I got this to work... The docs are already fixed  hopefully the next release will come soon. > But only after I created a line and got its start and end points and > subtracted their xcoordinates. I tried simply creating a length from > a number and then converting that to points, but got the wrong > answer... > > What I had was basically this the coordinates (i.e. my parameters, as > plain ints) and the result of somePath.begin() etc. and tried to mix > these... That didn't work well, even though I used the same numbers as > parameters when constructing somePath. I guess I'm just confused by > the unit system, but it seems odd that the numbers were interpreted > differently... Numbers are always interpreted as user lengths in the default_unit (normally cm). I'm not sure what went wrong in your case. Could you post an example? Jörg 
From: Magnus Lie Hetland <magnus@he...>  20041013 10:03:32

Joerg Lehmann <joergl@...>: > [snip] > The docs are already fixed  hopefully the next release will come soon. Excellent. [snip] > Numbers are always interpreted as user lengths in the default_unit > (normally cm). I'm not sure what went wrong in your case. Could you pos= t > an example? Hm. I tried to recreate this with a simple example now, and it seemed to work... Although the difference between begin/end of the curve gave me tcoordinates and the number gave me (as you say) ucoordinates. I guess they happened to be in the same unit or something? Now... When preparing to put the example code into this email, I think I found the problem; it was just a bug in my code. I had used a/b instead of b/a, and immediately assumed there was a problem with the units. <ahem> :} But another quick question: How do you copy a path? Or  how do you render a path multiple times (possibly with transformations inbetween)? In my current toy project I've been using copy.deepcopy, but it does, perhaps, seem a bit wasteful. I keep rendering the same path again and again, with different transformations, and it's quite slow (possibly because I copy the path all the time). > J=F6rg =20 Magnus Lie Hetland Fallen flower I see / Returning to its branch http://hetland.org Ah! a butterfly. [Arakida Moritake] 
From: Joerg Lehmann <joergl@us...>  20041013 16:35:37

On 13.10.04, Magnus Lie Hetland wrote: > Joerg Lehmann <joergl@...>: > > > [snip] > > The docs are already fixed  hopefully the next release will come soon. > > Excellent. > > [snip] > > Numbers are always interpreted as user lengths in the default_unit > > (normally cm). I'm not sure what went wrong in your case. Could you post > > an example? > > Hm. I tried to recreate this with a simple example now, and it seemed > to work... Although the difference between begin/end of the curve gave > me tcoordinates and the number gave me (as you say) ucoordinates. I > guess they happened to be in the same unit or something? PyX returns true lengths if the corresponding length has already been converted internally to points. > Now... When preparing to put the example code into this email, I think > I found the problem; it was just a bug in my code. I had used a/b > instead of b/a, and immediately assumed there was a problem with the > units. <ahem> :} I see, but still: supporting length divisions is probably a good idea. > But another quick question: How do you copy a path? Or  how do you > render a path multiple times (possibly with transformations > inbetween)? In my current toy project I've been using copy.deepcopy, > but it does, perhaps, seem a bit wasteful. I keep rendering the same > path again and again, with different transformations, and it's quite > slow (possibly because I copy the path all the time). You could use the "transformed" method of the path which returns a copy of the path transformed according to the given transformation. If you always start from the same path, you should convert it to a normpath before to improve the performance. Alternatively, you could always stroke the same path but each time inserted in a transformed canvas. Jörg 
From: Michael J Gruber <michaeljgruber@fa...>  20041014 09:09:52
Attachments:
unit.py.diff

Joerg Lehmann venit, vidit, dixit 20041011 18:04: >>I submitted code which did that a while ago. I remember it was refused >>because this would force implicit "conversion of the units", i.e. >>application of scale factors at the time when __div__ is used. I'm not >>sure why this is a problem, but I'm not sure either whether I understand >>the lengths in PyX ;) > > > Yes, I remember that you've suggested the same some time ago and that we > have rejected your patch because of the implicit conversion which is > necessary to calculate the ratio. But thinking about it again, I'm not > sure whether this is a real problem. In fact, I don't think it is one. > The only thing which clearly doesn't make sense is the multiplication > of two lengths. > > So feel free to submit your patch again. Joerg Lehmann venit, vidit, dixit 20041013 18:34: > I see, but still: supporting length divisions is probably a good idea. OK OK :) A diff to current CVS is attached. It uses isinstance, so it's not polymorphic  that would require a bit more code, since the return type of __div__ must depend on the input types (we don't want lengthparam/numberparam to result in lengthparam/length(numberparam) ). Cheers, Michael 