pyx-devel — PyX development

Re: [PyX-devel] Re: [PyX-checkins] pyx/test/experimental solve.py,1.2,1.3

[Magnus L. H. <ma...@he...>]

Andre Wobst <wo...@us...>:
>
> Hi,
>=20
> On 28.07.04, Magnus Lie Hetland wrote:
> > Joerg Lehmann <jo...@us...>:
> > >
> > [snip]
> > > IMHO it's too implicit. In particular, not having to explicitly spe=
cify
> > > the solver is probably not a good idea.=20
> >=20
> > I think using =3D=3D for anything with side-effects (or even anything=
 that
> > isn't interpretable as a boolean equality check) is quite unfortunate.
> > It might *look* good, but still... (if x =3D=3D y: alwaysexecuted()..=
.)
>=20
> Thanks, J=F6rg, Magnus. I was not satisfied myself. The comparison make=
s
> me troubles as well ... see the id comparision and the XXX comment,
> where I check for zero using "is", which works, since all integer
> constants below 100 are predefined and used by reference. In the
> beginning I liked the idea, but its probably a bad idea.

Comparing numbers usin 'is' is probably not a good idea, as this
behavior isn't (AFAIK) defined as part of the language -- it's an
implementation detail that might change.

> > If one was feeling adventurous, one could even do stuff like
> >=20
> >   solver(x =3D y)
> >=20
> > but only for single-variable left-hand-sides, of course.
>=20
> I do not quite understand. What's the result of an assignment?

No, no -- the above is just the use of a keyword argument.

[snip]
> Beside that, I think where might be usecases, where you store a term.
> Say:
>=20
> x =3D scalar()
> y =3D scalar()
> z =3D scalar()
>=20
> A =3D x + 5*y
> B =3D A + y
> C =3D A + z
>=20
> solver.eq(B, C)
>=20
> I don't know whether this will make sense, but you can do so.

This looks just fine to me.

[snip]
> You can currently do so with the "=3D=3D" logic.

Yeah, I meant specifically fiddling with things so you could use '=3D'
(which you normally couldn't do -- not in the same way you do with
'=3D=3D').

[snip]
> Now you can write:
>=20
> a =3D=3D point(0, 1)
>=20
> Guess, what b becomes? ... ;-)

Hehe.

BTW: I wrote pt to work like a sequence, and thus have a
constructor of the type pt([1, 2 ,3]) and not pt(1, 2, 3). This was
motivated by a similar discussion about the new set type. I guess it
is sort of echoed by the discussion of the use of explicit lists in
the decorator specifications in PyX. Just food for thought...

> 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-devel] Another geometry version

[Magnus L. H. <ma...@he...>]

Andre Wobst <wo...@us...>:
>
> Hi,
>=20
> On 29.07.04, Magnus Lie Hetland wrote:
> > > PyX is able to create PostScript files to be used whereever you wan=
t.
> > > Even on a printer ... ;-)
> >=20
> > But then again -- PyX also uses TeX; you've just hidden it better ;)
>=20
> Wasn't that point related to the discussion about integration of
> ghostscript to allow for various output formats? Beside that I thought
> that TeX is linked into MetaPost directly instead of running it as an
> external program. I would call linking programs together a better
> integration.

Not sure. I don't think it uses TeX as a library, at least (as a TeX
library doesn't really exist, although there is work on one now). I
think it simply executes TeX in the background. My point was that you
have to use TeX again afterward and include the MetaPost graphics to
get a document with properly embedded fonts etc. You do that bit
automatically.

Oh, well. I was just poking fun (in response to your sarcasm mode) and
don't really know what I'm talking about here ;)

> 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-devel] Two other things that might be nice...

[Magnus L. H. <ma...@he...>]

Andre Wobst <wo...@us...>:
>
[snip]
> Sounds like something to be build finite size canvas aka canvas with a
> border aka boxes (in the future). I'll try to keep it in mind.

Sounds good.

[snip]
>=20
> I.e. you calculate yourself what curves/colors occur when a partially
> transparent objects is painted on to of some existing material.

Yes.

> You're free to do so. Well, its more difficult than in MetaPost I
> guess.

I don't know; MetaPost isn't especially good here -- it just would be
good to have some sort of automation here, if possible. Just
fantasizing, really :]

If you do SVG output, you could add transparency and the like, which
would only work in SVG...? (It supports animation and the like too,
off course; and filters... Hm.)

> > > I'm sorry, what's SVM?
> >=20
> > Dang. It's "support vector machine", but that's not what I meant to
> > say (I'm just used to typing it).
>=20
> As I found out myself before ...

:)

> About SVG: Its already on the TODO list (for about half a year or so).
> This means, yes, SVG support would be great. Its something we should
> try to implement to catch up with the future.

Excellent.

> > But I guess supporting lots of output formats isn't all that useful,
> > really, as long as there are converters out there.
>=20
> I'm not that sure. Why do you use pdftex instead of TeX+dvips+ps2pdf?
> Why is there even a market share for such a program like pdftex?

Many reasons, I guess. Shorter pipeline; very robust and nice-looking
PDF output (as opposed to, at least in the more naive versions,
dvips+ps2pdf or dvipdf). Also special-purpose PDF stuff and new
functionality with hanging punctuation and microtypography (which is
not, AFAIK, available in TeX).

In my case I guess there are two reasons; my desired output format is
PDF (PS is hardly used for docs anymore) so using pdftex seems obvious
(now that it exists already ;). And: I've used dvips + ps2pdf before,
and had some bad luck (or low skill? ;) ending up with nasty bitmapped
fonts and the like, similar to many of the horrible 'old skool' PDF
latex files you find around the Web, which don't display properly --
and display very slowly at that.

Now... If your point was: "Of course one needs pdftex. This
illustrates why PyX should output the relevant formats itstelf instead
of using external converters" I agree with that.

> > Perhaps one could add a back-end for different output formats, and us=
e
> > command-line converter tools per default, until custom output routine=
s
> > were produced?
>=20
> Personally I'm not convinsed to make use of external programs to claim
> to support pdf, png, gif, jpeg etc. output. It's just a lie.

Sure. But if you're open about it, and call it a utility framework
(so people don't have to write external shell scripts to do this sort
of thing) it's not lying. You could just describe what it really is.
Using external programs as output plug-ins.

OpenOffice allows you to use XSLT stylesheets as "save as"-plug-ins.
Very nifty IMO. One could, of course, invoke a separate XSLT processor
afterward. No big deal.

> > Or perhaps a simple drawing API could be used at the bottom, and
> > several back-ends could be used... (Hm. Drifting back to my old
> > project PIDDLE here, I guess ... ;)
>=20
> Well, we don't have bitmap output and PyX isn't designed that way to
> support it even in the far future.

No, I didn't really mean bitmap output. I just meant thinking about
abstracting away the core drawing stuff. Then one could plug in other
drawing modules with very simple APIs (such as the extremely few
Piddle methods). On the other hand, the back-end could simply
implement a PostScript interpreter and use that as the API <wink>.

> Our objects know themselfs what they need to do in order to be
> inserted into a vector graphics format like PostScript, PDF, etc.
> ... so it's not like PIDDLE.

No, I see. Does this mean that adding stuff like PDF and SVG is going
to be Hard Work(tm)?

> Anyway, we need to extract, what special features are in those
> different vector graphic formats we want to support and try to fit
> it into a unique API.

Yeah, I guess that's exactly what I was thinking about. Then, if
someone would like to write, say, an Antigrain object (or whatever)
using that API, it would (or might?) work. Or not?

> Things like strokecolors and fillcolors, which PDF has, but
> PostScript doesn't. I think (J=F6rg and I discussed it), we want only
> one color for both, stroking and filling. Just to give you an idea,
> what we're thinking about and what our problems are ...

Sure. Lowest common denominator is fine. That's what Piddle does,
anyway.

We worked a bit at finding a really small API, and, in fact, the API
(if you use the default implementations of the various curves and arcs
in terms of polygons) consists only of the following four methods:

  drawLine
  drawPolygon
  drawImage
  drawString

There is a fill parameter allowing you to fill things and the like,
though.

Not directly applicable, I guess, but still...

I guess it's just a matter of where the line is drawn between PyX and
the rest of the world anyway. One could always generate other output
formats based on what PyX outputs.

> In the end it's clear that PostScript, PDF and SVG are close enough to
> at least dream about support them all. In that sense we restrict
> ourself to quite a limited scope ...

Sure. PostScript, PDF and SVG are all part of the same happy family.
PDF is a dumbing down of PostScript with a more ugly syntax, and SVG
wraps that the PDF syntax in XML attributes... (And adds lots of
stuff, of course.) ;)

I don't know of any other formats that are as closely related to these
as they are to each other; restricting yourselves to this threesome
seems like a reasonable decision.

And just to repeate a thought from before: I think it would be very
nice if you allowed the use of some of the extra features in SVG even
if they won't work with PostScript and PDF. If I know I want SVG
output I won't care if (say) transparency isn't supported in PS and
PDF...

Anyway, PyX r teh pwnz0r! ;)

--=20
Magnus Lie Hetland     "Canned Bread: The greatest thing since sliced
http://hetland.org      bread!" [from a can in Spongebob Squarepants]

Re: [PyX-devel] Another geometry version

[Andre W. <wo...@us...>]

Hi,

On 29.07.04, Magnus Lie Hetland wrote:
> > PyX is able to create PostScript files to be used whereever you want.
> > Even on a printer ... ;-)
> 
> But then again -- PyX also uses TeX; you've just hidden it better ;)

Wasn't that point related to the discussion about integration of
ghostscript to allow for various output formats? Beside that I thought
that TeX is linked into MetaPost directly instead of running it as an
external program. I would call linking programs together a better
integration.


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/

Re: [PyX-devel] Another geometry version

[Magnus L. H. <ma...@he...>]

Andre Wobst <wo...@us...>:
>
> Hi,
>=20
> On 29.07.04, Magnus Lie Hetland wrote:
> > > PS: <sarcasm> Isn't MetaPost always a hickup? It does not even prod=
uce
> > > viewable/printable files (i.e. embedding the fonts it uses). </sarc=
asm>
> >=20
> > Heh. I only use it together with pdflatex, and then it works
> > wonderfully.
>=20
> I'm still in sarcasm mode: MetaPost is a tool suitable for a single
> niche, i.e. to be used together with TeX and Co. However, MetaPost
> does not create PostScript files (at least PostScript files containing
> text). (I know, there is mproof, but what's that an ugly solution.)
>=20
> PyX is able to create PostScript files to be used whereever you want.
> Even on a printer ... ;-)

But then again -- PyX also uses TeX; you've just hidden it better ;)

> 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-devel] Another geometry version

[Andre W. <wo...@us...>]

Hi,

On 29.07.04, Magnus Lie Hetland wrote:
> > PS: <sarcasm> Isn't MetaPost always a hickup? It does not even produce
> > viewable/printable files (i.e. embedding the fonts it uses). </sarcasm>
> 
> Heh. I only use it together with pdflatex, and then it works
> wonderfully.

I'm still in sarcasm mode: MetaPost is a tool suitable for a single
niche, i.e. to be used together with TeX and Co. However, MetaPost
does not create PostScript files (at least PostScript files containing
text). (I know, there is mproof, but what's that an ugly solution.)

PyX is able to create PostScript files to be used whereever you want.
Even on a printer ... ;-)


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/

Re: [PyX-devel] Two other things that might be nice...

[Andre W. <wo...@us...>]

Hi,

On 29.07.04, Magnus Lie Hetland wrote:
> CAG is a 2D-version of constructive solid geometry. Basically the use
> of set operations on areas (or closed (or, perhaps, even open?)
> paths). The Java 2D API has it (although I've never really used that
> much).
> 
> Basically you can do stuff like "take this circle here, remove the
> part that overlaps with this other circle here, and then use the union
> of that and this rectangle here" and so forth. Can make it quite easy
> to build up complex paths.

Sounds like something to be build finite size canvas aka canvas with a
border aka boxes (in the future). I'll try to keep it in mind.

> > >   - Transparency/alpha levels (has been done using MetaPost; could
> > >     perhaps be ported)
> > 
> > Transparency in PostScript? Have to take a look at it. I know that
> > there are some tricks, but those are quite problematic.
> 
> Sure. Here's some material on faking transparency with MetaPost,
> though:
> 
>   http://www-math.univ-poitiers.fr/~phan/metalpha.html

I.e. you calculate yourself what curves/colors occur when a partially
transparent objects is painted on to of some existing material. You're
free to do so. Well, its more difficult than in MetaPost I guess.

> > I'm sorry, what's SVM?
> 
> Dang. It's "support vector machine", but that's not what I meant to
> say (I'm just used to typing it).

As I found out myself before ...

About SVG: Its already on the TODO list (for about half a year or so).
This means, yes, SVG support would be great. Its something we should
try to implement to catch up with the future.

> But I guess supporting lots of output formats isn't all that useful,
> really, as long as there are converters out there.

I'm not that sure. Why do you use pdftex instead of TeX+dvips+ps2pdf?
Why is there even a market share for such a program like pdftex?

> Perhaps one could add a back-end for different output formats, and use
> command-line converter tools per default, until custom output routines
> were produced?

Personally I'm not convinsed to make use of external programs to claim
to support pdf, png, gif, jpeg etc. output. It's just a lie.

> Or perhaps a simple drawing API could be used at the bottom, and
> several back-ends could be used... (Hm. Drifting back to my old
> project PIDDLE here, I guess ... ;)

Well, we don't have bitmap output and PyX isn't designed that way to
support it even in the far future. Our objects know themselfs what
they need to do in order to be inserted into a vector graphics format
like PostScript, PDF, etc. ... so it's not like PIDDLE. Anyway, we
need to extract, what special features are in those different vector
graphic formats we want to support and try to fit it into a unique
API. Things like strokecolors and fillcolors, which PDF has, but
PostScript doesn't. I think (Jörg and I discussed it), we want only
one color for both, stroking and filling. Just to give you an idea,
what we're thinking about and what our problems are ...

In the end it's clear that PostScript, PDF and SVG are close enough to
at least dream about support them all. In that sense we restrict
ourself to quite a limited scope ...


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/

Re: [PyX-devel] Two other things that might be nice...

[Magnus L. H. <ma...@he...>]

Andre Wobst <wo...@us...>:
>
> Hi,
>=20
> On 28.07.04, Magnus Lie Hetland wrote:
> > ... while we're on the topic (sort of):
> >=20
> >   - Constructive area geometry
>=20
> What do you want? Please explain in a few words ...

CAG is a 2D-version of constructive solid geometry. Basically the use
of set operations on areas (or closed (or, perhaps, even open?)
paths). The Java 2D API has it (although I've never really used that
much).

Basically you can do stuff like "take this circle here, remove the
part that overlaps with this other circle here, and then use the union
of that and this rectangle here" and so forth. Can make it quite easy
to build up complex paths.

> >   - Transparency/alpha levels (has been done using MetaPost; could
> >     perhaps be ported)
>=20
> Transparency in PostScript? Have to take a look at it. I know that
> there are some tricks, but those are quite problematic.

Sure. Here's some material on faking transparency with MetaPost,
though:

  http://www-math.univ-poitiers.fr/~phan/metalpha.html

> >   - SVM output
>=20
> I'm sorry, what's SVM?

Dang. It's "support vector machine", but that's not what I meant to
say (I'm just used to typing it). What I *did* mean was SVG.

(SVG, of course, has support for nice things like transparency
already...)

But I guess supporting lots of output formats isn't all that useful,
really, as long as there are converters out there.

Perhaps one could add a back-end for different output formats, and use
command-line converter tools per default, until custom output routines
were produced?

Or perhaps a simple drawing API could be used at the bottom, and
several back-ends could be used... (Hm. Drifting back to my old
project PIDDLE here, I guess ... ;)

> > Oh, wait -- that's three things... <wink>
>=20
> As soon as you want to take one of it yourself ... ;-)

Right. :]

> 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-devel] Another geometry version

[Magnus L. H. <ma...@he...>]

Andre Wobst <wo...@us...>:
>
> Hi,
>=20
> On 28.07.04, Magnus Lie Hetland wrote:
> > (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 sam=
e
> > subset of EPS, possibly with a switch, such as mps=3DTrue or somethin=
g,
> > that would be very nice :})
>=20
> We'll probably support direct PDF output much sooner. Next week? No,
> probably not. But within a few month I (and J=F6rg) should find some
> time to finish it. Originally I thought about having this for 0.7
> already. I'm not that sure whether we can make that. 0.7 needs to be
> release on not to far future ...

One solution would be to use epstopdf or something externally; you
already do this sort of thing with TeX, so... (I've used this solution
in my own programs.)

> Andr=E9
>=20
> PS: <sarcasm> Isn't MetaPost always a hickup? It does not even produce
> viewable/printable files (i.e. embedding the fonts it uses). </sarcasm>

Heh. I only use it together with pdflatex, and then it works
wonderfully.

--=20
Magnus Lie Hetland     "Canned Bread: The greatest thing since sliced
http://hetland.org      bread!" [from a can in Spongebob Squarepants]

Re: [PyX-devel] Two other things that might be nice...

[Andre W. <wo...@us...>]

Hi,

On 28.07.04, Magnus Lie Hetland wrote:
> ... while we're on the topic (sort of):
> 
>   - Constructive area geometry

What do you want? Please explain in a few words ...

>   - Transparency/alpha levels (has been done using MetaPost; could
>     perhaps be ported)

Transparency in PostScript? Have to take a look at it. I know that
there are some tricks, but those are quite problematic.

>   - SVM output

I'm sorry, what's SVM?

> Oh, wait -- that's three things... <wink>

As soon as you want to take one of it yourself ... ;-)


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/

Re: [PyX-devel] Another geometry version

[Joerg L. <jo...@us...>]

Hi Magnus,

On 28.07.04, Magnus Lie Hetland wrote:
> Andre Wobst <wo...@us...>:
> >
> [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 :])

Fortunately, we already have some dungeon experience aquired in other
parts of the TeX code. In particular, you need some mighty global
variable protection shield...

[snip]
> (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=True or something,
> that would be very nice :})

... or use the PDF output, which however is not yet totally finished.

        Jörg

Re: [PyX-devel] Another geometry version

[Andre W. <wo...@us...>]

Hi,

On 28.07.04, Magnus Lie Hetland wrote:
> (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=True or something,
> that would be very nice :})

We'll probably support direct PDF output much sooner. Next week? No,
probably not. But within a few month I (and Jörg) should find some
time to finish it. Originally I thought about having this for 0.7
already. I'm not that sure whether we can make that. 0.7 needs to be
release on not to far future ...


André

PS: <sarcasm> Isn't MetaPost always a hickup? It does not even produce
viewable/printable files (i.e. embedding the fonts it uses). </sarcasm>

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/

Re: [PyX-devel] Re: [PyX-checkins] pyx/test/experimental solve.py,1.2,1.3

[Andre W. <wo...@us...>]

Hi,

On 28.07.04, Joerg Lehmann wrote:
> > "=="
> IMHO it's too implicit. In particular, not having to explicitly specify
> the solver is probably not a good idea. 

I think, having only one solver (as in MetaPost) is not that
problematic. OTOH, yes, you may make use of several solvers. But then
I think we should do the bookkeeping, whether a variable is already
defined (currently by the is_set() method), local within each solver.
Could be usefull ... I'm not sure.

AFAIRC in MetaPost there is a possibility to "redefine" the value of a
variable and "resolve" the equations. Might be a task for several
solvers. This would be much more elegant IMHO (compared to the
MetaPost way; MetaPost doesn't have (several) solver instances.)


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/

Re: [PyX-devel] Re: [PyX-checkins] pyx/test/experimental solve.py,1.2,1.3

[Andre W. <wo...@us...>]

Hi,

On 28.07.04, Magnus Lie Hetland wrote:
> Joerg Lehmann <jo...@us...>:
> >
> [snip]
> > IMHO it's too implicit. In particular, not having to explicitly specify
> > the solver is probably not a good idea. 
> 
> I think using == for anything with side-effects (or even anything that
> isn't interpretable as a boolean equality check) is quite unfortunate.
> It might *look* good, but still... (if x == y: alwaysexecuted()...)

Thanks, Jörg, Magnus. I was not satisfied myself. The comparison makes
me troubles as well ... see the id comparision and the XXX comment,
where I check for zero using "is", which works, since all integer
constants below 100 are predefined and used by reference. In the
beginning I liked the idea, but its probably a bad idea.

> If one was feeling adventurous, one could even do stuff like
> 
>   solver(x = y)
> 
> but only for single-variable left-hand-sides, of course.

I do not quite understand. What's the result of an assignment? Anyway,
once we do not use x == y, we should allow for x = y as well. Its
becoming even less symmetric: Currently you need to set x and y to be
scalar instances (or variable instances). In your case this becomes
assymetric. You would need to initialize just x.

Beside that, I think where might be usecases, where you store a term.
Say:

x = scalar()
y = scalar()
z = scalar()

A = x + 5*y
B = A + y
C = A + z

solver.eq(B, C)

I don't know whether this will make sense, but you can do so.

> It would be possible to do some property magic too... I'm pretty sure
> I could write code such that
> 
>   a.x = b.y
>   a.y = 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.

You can currently do so with the "==" logic. That's because the
components of a vector ar scalars and you can formulate scalar
eqations and vector equations. So you can currently write:

a = vector(2)
b = vector(2)

a[0] == b[1]
a[1] == b[0]

Note I have not (yet) a getattr on the vectors for "x", "y", "z". But
right, thats trivial to be added.

Now you can write:

a == point(0, 1)

Guess, what b becomes? ... ;-)


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/

[PyX-devel] Two other things that might be nice...

[Magnus L. H. <ma...@he...>]

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

Re: [PyX-devel] Another geometry version

[Magnus L. H. <ma...@he...>]

Andre Wobst <wo...@us...>:
>
[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
shape-preserving:

  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 non-linear 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]

Re: [PyX-devel] A general comment

[Magnus L. H. <ma...@he...>]

Andre Wobst <wo...@us...>:
>
> (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 deep-rooted 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]

Re: [PyX-devel] Re: [PyX-user] Some geometry thoughts

[Magnus L. H. <ma...@he...>]

Andre Wobst <wo...@us...>:
>
> 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 non-linear.
>=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 non-linear 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 book-keeping, 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 non-linear terms might be hidden in some additional
> "non-linear 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 "non-linear
> variable" can be resolved and a linear equation is restored.

Yeah -- a bit of book-keeping, 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 number-like 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]

Re: [PyX-devel] Re: [PyX-checkins] pyx/test/experimental solve.py,1.2,1.3

[Magnus L. H. <ma...@he...>]

Andre Wobst <wo...@us...>:
>
> Hi,
>=20
> On 28.07.04, Andr=E9 Wobst wrote:
> > Update of /cvsroot/pyx/pyx/test/experimental
> > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv13287
> >=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 non-trivial 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]

Re: [PyX-devel] Re: [PyX-checkins] pyx/test/experimental solve.py,1.2,1.3

[Magnus L. H. <ma...@he...>]

Joerg Lehmann <jo...@us...>:
>
[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 side-effects (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 single-variable left-hand-sides, 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]

Re: [PyX-devel] Re: [PyX-checkins] pyx/test/experimental solve.py,1.2,1.3

[Joerg L. <jo...@us...>]

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 non-trivial 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

[PyX-devel] Re: [PyX-checkins] pyx/test/experimental solve.py,1.2,1.3

[Andre W. <wo...@us...>]

Hi,

On 28.07.04, André Wobst wrote:
> Update of /cvsroot/pyx/pyx/test/experimental
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv13287
> 
> 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 non-trivial code. My biggest concerns are
in the area of usuability, i.e. is it too implicit? Comments?


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/

Re: [PyX-devel] Another geometry version

[Andre W. <wo...@us...>]

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 try-import-except? 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
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/

Re: [PyX-devel] A general comment

[Andre W. <wo...@us...>]

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 try-except 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 mix-in 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 mix-in 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
"ask-what-it-is" 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 clearing-functionality 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
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/

Re: [PyX-devel] Another geometry version

[Andre W. <wo...@us...>]

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
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/