Re: [PyX-user] Ratio between lengths

[Michael J Gruber <michaeljgruber@fa...>]

Joerg Lehmann venit, vidit, dixit 2004-10-11 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 2004-10-13 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

[PyX-user] Ratio between lengths

[Magnus Lie Hetland <magnus@he...>]

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]

Re: [PyX-user] Ratio between lengths

[Joerg Lehmann <joergl@us...>]

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

Re: [PyX-user] Ratio between lengths

[Michael J Gruber <michaeljgruber@fa...>]

Joerg Lehmann venit, vidit, dixit 2004-10-11 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

Re: [PyX-user] Ratio between lengths

[Joerg Lehmann <joergl@us...>]

Hi Michael,

On 11.10.04, Michael J Gruber wrote:
> Joerg Lehmann venit, vidit, dixit 2004-10-11 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

Re: [PyX-user] Ratio between lengths

[Magnus Lie Hetland <magnus@he...>]

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
x-coordinates. 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]

Re: [PyX-user] Ratio between lengths

[Joerg Lehmann <joergl@us...>]

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 x-coordinates. 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

Re: [PyX-user] Ratio between lengths

[Magnus Lie Hetland <magnus@he...>]

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 t-coordinates and the number gave me (as you say) u-coordinates. 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
in-between)? 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]

Re: [PyX-user] Ratio between lengths

[Joerg Lehmann <joergl@us...>]

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 t-coordinates and the number gave me (as you say) u-coordinates. 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
> in-between)? 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

Re: [PyX-user] Ratio between lengths

[Michael J Gruber <michaeljgruber@fa...>]

Joerg Lehmann venit, vidit, dixit 2004-10-11 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 2004-10-13 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