pyx-devel — PyX development

Re: [PyX-devel] Re: [PyX-checkins] pyx/pyx canvas.py,1.269,1.270

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

Hi,

On 31.08.04, Andre Wobst wrote:
> On 30.08.04, Jörg Lehmann wrote:
> > apply deformers when drawing a path. Note that it is not clear
> > whether we first apply a trafo and then a deformer or vice versa
> 
> One could argue, that a transformation is not that different from a
> deformer ...
> 
> I do not yet claim, that we should do so, but we might at least
> discuss this point of view. It would automatically lead to a solution
> to this problem ...

Good point. I actually like this idea. We just have to derive
trafo.trafo from deformer.deformer and supply trafo.trafo with a 
deform method.

        Jörg

[PyX-devel] Re: [PyX-checkins] pyx/pyx canvas.py,1.269,1.270

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

Hi,

On 30.08.04, Jörg Lehmann wrote:
> apply deformers when drawing a path. Note that it is not clear
> whether we first apply a trafo and then a deformer or vice versa

One could argue, that a transformation is not that different from a
deformer ...

I do not yet claim, that we should do so, but we might at least
discuss this point of view. It would automatically lead to a solution
to this problem ...


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] PyX sprint last weekend

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

Hi,

you might be interested in my small note I just posted at
http://wobsta.blogspot.com/ about a PyX developer meeting with Jörg
last weekend.


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] [ pyx-Bugs-986123 ] Axis labels look weird

[SourceForge.net <no...@so...>]

Bugs item #986123, was opened at 2004-07-06 20:01
Message generated for change (Comment added) made by wobsta
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=986123&group_id=45430

Category: None
Group: None
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Axis labels look weird

Initial Comment:
When I create an XY graph and specify an axis label that is more than one word long, sometimes the 
two words overlap. Here is ahat I have found so far:
(Axis label specified: What it looks like)

"X values" - Looks normal
"Y values" - Looks normal
"solution variable" - Two words overlap
"variable" - Looks normal
"variableABCDEFGHIJ" - Looks normal
"variable ABCDEFGHIJ" - Looks like: variabl***CDEF GHIJ (where the *** indicates where the "e" and 
"AB" overlap)
"solution-variable" - Looks normal
"solution_variable" - Gives the following error:
Traceback (most recent call last):
   ...
    mycanvas.writeEPSfile(filename)
  File "/users/mont/PyX-0.6.3/pyx/canvas.py", line 367, in writeEPSfile
    abbox = bbox is not None and bbox or self.bbox()
  File "/users/mont/PyX-0.6.3/pyx/canvas.py", line 129, in bbox
    abbox = cmd.bbox()
  File "/users/mont/PyX-0.6.3/pyx/deco.py", line 71, in bbox
    pbbox = self.path.bbox()
  File "/users/mont/PyX-0.6.3/pyx/graph/graph.py", line 418, in bbox
    self.finish()
  File "/users/mont/PyX-0.6.3/pyx/graph/graph.py", line 368, in finish
    self.domethods[0]()
  File "/users/mont/PyX-0.6.3/pyx/graph/graph.py", line 310, in dolayout
    axis.finish(self.axespos[key])
  File "/users/mont/PyX-0.6.3/pyx/graph/axis/axis.py", line 344, in finish
    ac = self.painter.paint(axispos, self)
  File "/users/mont/PyX-0.6.3/pyx/graph/axis/painter.py", line 486, in paint
    _title.paint(self, axispos, axis, ac=ac)
  File "/users/mont/PyX-0.6.3/pyx/graph/axis/painter.py", line 305, in paint
    title = self.texrunner.text_pt(x, y, axis.title, titleattrs)
  File "/users/mont/PyX-0.6.3/pyx/text.py", line 1133, in text_pt
    return self.text(unit.t_pt(x), unit.t_pt(y), expr, *args, **kwargs)
  File "/users/mont/PyX-0.6.3/pyx/text.py", line 1115, in text
    self.execute(expr, self.defaulttexmessagesdefaultrun + self.texmessagesdefaultrun + texmessages)
  File "/users/mont/PyX-0.6.3/pyx/text.py", line 944, in execute
    raise TexResultError("unhandled TeX response (might be an error)", self)
pyx.text.TexResultError: unhandled TeX response (might be an error)
The expression passed to TeX was:
  \ProcessPyXBox{\gdef\PyXHAlign{0.50000}\setbox0\hbox{$\vcenter{\vrule 
width0pt}$}\lower\ht0\hbox{{solution_variable}}%
  }{53}%
  \PyXInput{57}%
After parsing the return message from TeX, the following was left:
  *! Missing $ inserted.<inserted text>                 $<to be read again>                    _<argument> 
...h0pt}$}\lower \ht 0\hbox {{solution_
                   variable}}\ProcessPyXBox #1#2->\setbox \PyXBox =\hbox {{#1                                       
         }}\PyXDimenHAlignLT =\PyXHAl...<*> }{53}         %!
Extra }, or forgotten $.<argument> ...ower \ht 0\hbox {{solution_variable}                                               
   }\ProcessPyXBox #1#2->\setbox \PyXBox =\hbox {{#1
                                            }}\PyXDimenHAlignLT =\PyXHAl...<*> }{53}         %! Extra }, or forgotten 
$.<argument> ...wer \ht 0\hbox {{solution_variable}}
                                           \ProcessPyXBox #1#2->\setbox \PyXBox =\hbox {{#1                            
                    }}\PyXDimenHAlignLT =\PyXHAl...<*> }{53}         %! Extra }, or forgotten 
$.\ProcessPyXBox #1#2->\setbox \PyXBox =\hbox {{#1}                                                 
}\PyXDimenHAlignLT =\PyXHAl...<*> }{53}
       %! Extra }, or forgotten $.\ProcessPyXBox #1#2->\setbox \PyXBox =\hbox {{#1}}                           
                       \PyXDimenHAlignLT =\PyXHAl...<*> }{53}
    %

My e-mail address is ale...@ni...


----------------------------------------------------------------------

>Comment By: André Wobst (wobsta)
Date: 2004-08-27 22:48

Message:
Logged In: YES 
user_id=405853

We can't reproduce this bug. I'm closing it for the moment.
Please reopen it to provide us with further information.

----------------------------------------------------------------------

Comment By: André Wobst (wobsta)
Date: 2004-07-07 08:18

Message:
Logged In: YES 
user_id=405853

I expect this problem to be related to the text output itself. Could you try 
to run hello.py, which can be found at the example directory. You may 
substitute the string "hello, world!" by something you used before 
("variable ABCDEFGHIJ") to reproduce your problem. In case you find the 
same behaviour it would be a much better suitable (e.g. minimal) 
example to further investigate your problem.

----------------------------------------------------------------------

Comment By: Gert Ingold (gertingold)
Date: 2004-07-07 07:36

Message:
Logged In: YES 
user_id=809523

I cannot reproduce the problem with "variable ABCDEFGHIJ" under
PyX 0.6.3. Do you have a minimal example?

The problem with "solution_variable" is not a PyX bug but
related
to TeX which expects the underscore in math mode where it would
indicate a subscript (see also FAQ 4.3.3). To avoid this
problem,
the underscore has to be escaped with a backslash, i.e. you
should
use "solution\_variable". See also FAQ 2.4 concerning the use
of raw strings in Python.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=986123&group_id=45430

Re: [PyX-devel] Re: GlyphInterchangeFormat

[Michael S. <m-s...@us...>]

Hi,

As far as I know this is what people use:

1. For the interpolation problem: Curves passing through given points:

   (A) smooth curves built by piecewise polynoms (parameterized by the
       spacial coordinates). This requires to solve quite large systems
       of linear equations -- not a problem in principle, but the
       outcome is often poor because the polynoms are too restrictive.
> IIRC Michael Schindler played with some smooth curve thru some given
> points before already. I'm not sure whether any code is laying around
> somewhere, which could be usefull in that respect. But in principle
> you're right: it might be added on top of the existing PyX.

       for the case of equal spacing this problem needs no numeric
       solver, and I am planning to implement this as a
       graph.style.curve

   (B) parametric curves. In principle one gets non-linear equations
       for the parameter values  -- a really hard problem.
       This requires a lot of information on the specific geometric
       case.

       Especially, using boundary constraints like a certain tangent
       of a curve or so is not straight-forward formulated in terms of
       a general parameterization.
       This is maybe what Magnus Lie Hetland asks for.
> > The curve construction reminds me of a feature (or set of features)
> > from MetaPost that I believe is not available in PyX, but which can be
> > quite nice... Basically, it's the spline stuff that tries to fit a
> > curve to the points you give (without you having to give the Bezier
> > contour points explicitly). Also, you can give such (very useful)
> > constraints as the direction of the curve at a given point, and the
> > spline will adapt to that. I assume this could quite easily be built
> > on *top* of PyX -- I just thought it might be nice to have it as an
> > integrated part of the path mechanism? (I don't know the details of
> > the splines used by MP/MF, but they look fine, IMO.)
       I do not know how metafont is doing that, but I think MF knows
       some generic cases and uses a kind of "optimal"
       parameterization -- depending on the problem it has to solve.
       I do not even think that it is really an interpolating program
       -- rather a mixture of interpolating and optimisation...

       Another example is finding the outline of brushes or enlarging
       arbitrarily shaped boxes.
> > And another thing... I have no idea how it's done in MP (in MF I can
> > sort of understand it) but MP allows you to use custom-made paths as
> > brushes in other parhts. Very nice for calligraphic-like looks, for
> > example. (I guess one heavy-handed way of doing it would be simply to
> > replicate the brush all along the path, with the appropriate spacing
> > calcilated somehow, perhaps even dynamically along the path.)


2. Optimization problem: Approximating curves

   (C) Mainly used are extended bezier curves that have a
       well-specified starting and ending point and try to pass
       through several other points on their way. To me this never
       looked very useful ...

Maybe there is the "quadrature of the circle": The bezier curves
depend linearly on their endpoints. For them one can build up a linear
system of equations -- again with some (linear) constraints ...
This would merge the advantages of the (ordinary) splines and the
parametric curves ...
Does anyone know the name of this method or where to find this?
I would say that this might be the most promising way to build a
general algorithm in PyX for these non-standard path operations.

Michael.

-- 
"A mathematician is a device for turning coffee into theorems"
  Paul Erdös.

Re: [PyX-devel] Re: GlyphInterchangeFormat

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

Hi,

On 03.08.04, Magnus Lie Hetland wrote:
> The curve construction reminds me of a feature (or set of features)
> from MetaPost that I believe is not available in PyX, but which can be
> quite nice... Basically, it's the spline stuff that tries to fit a
> curve to the points you give (without you having to give the Bezier
> contour points explicitly). Also, you can give such (very useful)
> constraints as the direction of the curve at a given point, and the
> spline will adapt to that. I assume this could quite easily be built
> on *top* of PyX -- I just thought it might be nice to have it as an
> integrated part of the path mechanism? (I don't know the details of
> the splines used by MP/MF, but they look fine, IMO.)

IIRC Michael Schindler played with some smooth curve thru some given
points before already. I'm not sure whether any code is laying around
somewhere, which could be usefull in that respect. But in principle
you're right: it might be added on top of the existing PyX.

> And another thing... I have no idea how it's done in MP (in MF I can
> sort of understand it) but MP allows you to use custom-made paths as
> brushes in other parhts. Very nice for calligraphic-like looks, for
> example. (I guess one heavy-handed way of doing it would be simply to
> replicate the brush all along the path, with the appropriate spacing
> calcilated somehow, perhaps even dynamically along the path.)

You're talking about pens, not fill patterns, right?

I looked at this topic a few months ago after somebody asked me about
it. In MetaPost you can do two kind of pen shapes: a polygon pen shape
and a elliptic pen shape. For the first MetaPost calculates the
boundary of the area to be stroked (i.e. filled, once the outline is
calculated). While this is already a interesting part to program, the
elliptic curve is quite different. MetaPost does not calculate a
outline for that case (it would be an interesting challange, which
seems to be related to the enlargment of arbitrary shaped boxes as we
started to experiment in one of the test/experimental files some time
ago). What metapost does is to draw the path with a circular pen (i.e.
that's what PostScript does for a finite linewidth and round setting
of linecap and linejoin). However, this drawing does not happen on the
original path, but on a transformed path, where the transformation is
the one to make the elliptic pen circular. To finally get the correct
result, the transformation from the circular pen to the elliptic one
is applied to the stroked path. That way you can stroke the path with
a elliptic pen, but you can't calculated the outline. (AFAIK that's
one of the problems people have to create outline fonts out of
Metafont fonts.)

> Sorry to turn yet another thread into one about possible features...
> These are just a couple of things that came up when I took a stab at
> implementing big, flexible braces (such as these:
> http://just.letterror.com/ltrwiki/GlyphInterchangeFormat) in PyX.

No problem. It's always interesting to look around ...


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: GlyphInterchangeFormat

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

Andre Wobst <wo...@us...>:
>
> Hi,
> 
> I just got some interesting links from a friend:

That is indeed rather interesting.

The curve construction reminds me of a feature (or set of features)
from MetaPost that I believe is not available in PyX, but which can be
quite nice... Basically, it's the spline stuff that tries to fit a
curve to the points you give (without you having to give the Bezier
contour points explicitly). Also, you can give such (very useful)
constraints as the direction of the curve at a given point, and the
spline will adapt to that. I assume this could quite easily be built
on *top* of PyX -- I just thought it might be nice to have it as an
integrated part of the path mechanism? (I don't know the details of
the splines used by MP/MF, but they look fine, IMO.)

And another thing... I have no idea how it's done in MP (in MF I can
sort of understand it) but MP allows you to use custom-made paths as
brushes in other parhts. Very nice for calligraphic-like looks, for
example. (I guess one heavy-handed way of doing it would be simply to
replicate the brush all along the path, with the appropriate spacing
calcilated somehow, perhaps even dynamically along the path.)

Sorry to turn yet another thread into one about possible features...
These are just a couple of things that came up when I took a stab at
implementing big, flexible braces (such as these:
http://just.letterror.com/ltrwiki/GlyphInterchangeFormat) in PyX.

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

[PyX-devel] Re: GlyphInterchangeFormat

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

Hi,

I just got some interesting links from a friend:

On 03.08.04, Rolf Niepraschk wrote:
> The GlyphInterchangeFormat (or GLIF) is a simple and clear XML 
> representation of a single glyph. It is a major part of the RoboFab 
> project, and it is the foundation of the UnifiedFontObject. GLIF files 
> usually have a ".glif" extension.
> 
> ==> http://just.letterror.com/ltrwiki/GlyphInterchangeFormat
> 
> RoboFab is a library of python code for manipulation and storage of font 
> and glyph related data. RoboFab implements a new font file format, the 
> UnifiedFontObject(s) or .ufo for short.
> 
> ==> http://just.letterror.com/ltrwiki/RoboFab
> 
> The UnifiedFontObject (or UFO) is a two headed beast. It is both a file 
> format (see specification below) and a python scripting interface (see 
> short description below) for dealing with font related data. Here's some 
> general info: http://www.letterror.com/code/robofab/ufo.html
> 
> ==> http://just.letterror.com/ltrwiki/UnifiedFontObject
> 
> 
> ...Rolf
> -- 
> || Rolf Niepraschk c/o Physikalisch-Technische Bundesanstalt    ||
> || Abbestr. 2-12; D-10587 Berlin, Germany                       ||
> || Tel/Fax: ++49-30-3481-316/490, email: Rol...@pt... ||


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 02.08.04, Andre Wobst wrote:
> some fancy examples would be great as well ...

Something like the enclosed one, which looks pretty well, but
unfortunately it does use the solver to calculate the crossing point
between two lines only ...


André

PS: Do not forget to fetch the latest version of solve.py before
    trying the example since I broke some multiplication logic due to
    the vector*matrix multiplication yesterday and the linear equation
    solver used an integer matrix by accident.

-- 
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 01.08.04, Magnus Lie Hetland wrote:
> > One structually missing thing is the "redefinition" of an equation,
> > but this should not be hard to add it to the solver.
> 
> No -- and in a pinch, you could basically just build a new solver with
> one equation redefined.

I thought about that as well before, but there seems to be a problem:
If you create several solver instances (which is trivial, of course),
you can't store the solver results in the scalars itself. You would
loose to know, whether a scalar is a constant or it got set by another
solver (and should be overwritten?). We can find some way out of this
problem, but it might be quite obscure to the user ...

Beside that there are quite some other things to be discussed. Just a
few which come into my mind immediately: In MetaPost you can define
equations, which over-determine the problem. You can do so by
none-scalar equations and I think it's a bad idea to do so, but this
might be discussed with people, who are used to the MetaPost equation
solver. I'm not sure whether this is a often used feature and whether
we should spend time on that at all.

Currently the integration in PyX is not thought about. We have at
least to think about the interfaces to the path stuff, the
transformations and the PyX lengths. And we might think about the
basic functionality. Currently I've tried to implement some
school-like vector algebra. For example we do have vectors and we can
do scalar products between vectors. Multiplying a vector by another
vector will lead to a scalar product. One could also think about
introducing dual vectors, so that multiplying a dual vector by a
vector will be a scalar product, but multiplying a vector by a dual
vector will be a dyadic product and result in a matrix. While there
would be *some* people how would like that (I think, I would join that
portion), it might be inappropriate to our goals using the system for
geometrical operations. So, yes, I think we should stick on what we
already have (up to introducing a full transformation), but I'm not
totally sure.

Beside that we'll need to complete the tests and some fancy examples
would be great as well ...


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

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

Andre Wobst <wo...@us...>:
>
[snip]
> Coming back to our MetaPost like equations I've just checked in yet
> another version, where there are scalars, vectors, and matrices now.
> You can define a matrix by equations like in MetaPost, i.e. which
> points should be transformed into which points (except for the missing
> translation; a matrix is not a full affine transformation,

It can be... If you use homogenous coordinates :)

> but building a trafo class on top of a matrix and a vector should be
> quite easy).

Yeah -- or just hiding the homogenous coordinates behind the scenes.

> You can also calculate the invers of a matrix by multiplying it to
> another matrix and set the result to the uniform matrix ... so in
> principle we should be able to do most of the things you can do in
> MetaPost now.

Sounds veeery goood !-)

> One structually missing thing is the "redefinition" of an equation,
> but this should not be hard to add it to the solver.

No -- and in a pinch, you could basically just build a new solver with
one equation redefined.

> 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

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

Hi,

On 30.07.04, Magnus Lie Hetland wrote:
> [snip]
> > >   point([1, 2, 3])
> > > 
> > > or
> > > 
> > >   point((1, 2, 3))
> > > 
> > > is completely irrelevant (as long as you stay away from the
> > > naughtiness of type checking ;).
> > 
> > I'm not so sure. To me it makes a difference.
> 
> Not unless you're doing type checking ;)
> 
> I'm talking from the perspective of the function, not the caller. The
> function should simply treat the argument as a sequence, and not
> bother with how it is implemented.

Sure, that's right. My points were not related to the isinstance
discussion we actually started at.

> The only use of tuples, IMO (as a Python type, not as a concept -- you
> could easily use a list to model a mathematical tuple, where each
> position has a specific meaning and so forth) is that they are
> hashable, and thus can be used as keys in dicts, members of sets and
> so forth. You have the same dichotomy (list vs. tuple) in the set
> implementation (with set and frozenset).

I see, the hasability is an important point. I pretty much like your
comparision to set and frozenset. It looks like a very reasonable
point of view ...

> What do you mean? Would you like to use several iterable objects as
> arguments to list(), for example? What would that mean? Something like
> list(chain(iter1,iter2,iter3))? (The chain function is available in
> the itertools module.)

I meant list(*chain(iter1, iter2, iter2)). I would really like to be
able to write list(*iter1, *iter2, *iter3). Suppose we have the
line function line(x1, y1, x2, y2) as it is defined in PyX. Having a
function point(...) returning a list (x, y), it would be great if we
could just write line(*point(...), *point(...)). Currently you have to
write line(*(point() + point()), which I don't understand why ...

Coming back to our MetaPost like equations I've just checked in yet
another version, where there are scalars, vectors, and matrices now.
You can define a matrix by equations like in MetaPost, i.e. which
points should be transformed into which points (except for the missing
translation; a matrix is not a full affine transformation, but
building a trafo class on top of a matrix and a vector should be quite
easy). You can also calculate the invers of a matrix by multiplying it
to another matrix and set the result to the uniform matrix ... so in
principle we should be able to do most of the things you can do in
MetaPost now. One structually missing thing is the "redefinition" of
an equation, but this should not be hard to add it to the solver.


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

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

Andre Wobst <wo...@us...>:
>
[snip]
> >   point([1, 2, 3])
> >=20
> > or
> >=20
> >   point((1, 2, 3))
> >=20
> > is completely irrelevant (as long as you stay away from the
> > naughtiness of type checking ;).
>=20
> I'm not so sure. To me it makes a difference.

Not unless you're doing type checking ;)

I'm talking from the perspective of the function, not the caller. The
function should simply treat the argument as a sequence, and not
bother with how it is implemented.

> A tuple is something, where the items do have a fixed, specific
> position and the meaning of the items might be different depending
> on their position.

That is the philosophical reasoning, yes. I still think tuples are
pretty bogus. You could easily use lists to represent the same
thing... *Or* you could have fixed-length lists. *Or* you could have
mutable tuples. I don't know...

Anyway, it really shouldn't have anything to do with how the function
is implemented, as long as it doesn't realy on any functionality
present in tuples but not elsewhere (and I can't think of any).

> Hence a crucial feature of tuples is to be immutable in their
> length.

Sure. I can see how that can be useful -- sort of. Although not very
much.

> Well, they are immutable in their values as well, but this keeps to
> be strange to me. It's kind of unpythonic ... well. I don't know.

I think so too. When I wrote the chapter on sequences in my Python
book I had real problems justifying the existence of tuples. I tried
to ask Alex Martelly (who was one of my tech editors) and he didn't
have any good explanations either.

The only use of tuples, IMO (as a Python type, not as a concept -- you
could easily use a list to model a mathematical tuple, where each
position has a specific meaning and so forth) is that they are
hashable, and thus can be used as keys in dicts, members of sets and
so forth. You have the same dichotomy (list vs. tuple) in the set
implementation (with set and frozenset).

> Vectors, where each component is a value for a certain dimension is
> not a very good example for that discussion, I think. At least when
> all dimensions are equal to each other like in an Euclid space. May be
> the theory of relativity with its four component vectors is a
> resonable example even for a vector being a tuple, not a list ...

Sure. But that's still just (IMO) the thing you're *modeling* using
the specific object (a tuple or a list). I *don't* see why using a
tuple is any better, unless you really need it to be static/frozen
(which, in most cases, you really don't).

And I really, really think this is not something a function such as
this should care about. It should simply accept any iterable object.

Now -- it may be that we're discussing two different things... I'm
arguing that a list and a tuple as arguments should be seen as
equivalent; you may, perhaps, be arguing that positional arguments
(i.e. point(1, 2, 3)) is the way to go? I'm not really very opposed to
that. I just brought the (somewhat "standard") point(seq) syntax as an
alternative.

> Beside that, you're right. We should forget about type checking and
> than it usually becomes unimportant.
>=20
> > The real difference is between this
> > and
> >=20
> >   point(1, 2, 3)
> >=20
> > Even the numarray arrays use the first form, as do, really, all
> > sequence types, including tuples.
>=20
> In my redesign I'm only left with a single vector class. Here I'm
> using the list like version to create a constant and a plain number to
> specify a variable vectors dimension.

OK.

> I'm not sure whether you'll like this syntax in the end, but the
> user is left with just a scalar and a vector. Period. That's nice, I
> think, but we can discuss those details and the naming again once we
> see how it works out.

Indeed.

> > I'm just saying that the "standard" constructor for sequence
> > types admits a single iterable objects as its argument.
>=20
> BTW: How invented this stange *single* iterable object. I would really
> like to be allowed to use several of them. This limitation is annoying
> and unnecessary to me. (I haven't thought very hard about that, but I
> really don't see any reasoning why this limitation exist.)

What do you mean? Would you like to use several iterable objects as
arguments to list(), for example? What would that mean? Something like
list(chain(iter1,iter2,iter3))? (The chain function is available in
the itertools module.)

> 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] Great!

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

Andre Wobst <wo...@us...>:
>
> I've already started something *really* cool yesterday evening, but
> didn't yet finished it.  Don't worry, I'm almost there, I think. So
> stay tuned ... ;-)

How exciting :)

> > > BTW, the name point (for a constant vector) vs. vector (for a
> > > variable vector) might be worth a discussion.
> >=20
> > Yeah, I thought about that when I read the code, but didn't comment o=
n
> > it. Doesn't sound completely obvious to me. (*Must* they be two
> > separate classes?)
>=20
> No, you're right! This was an important point to me. I'm working along
> that line. So thanks, this discussion helps me a lot ...

Great!

> 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

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

Hi,

On 29.07.04, Magnus Lie Hetland wrote:
> > I'm not totally convinced, but I might need to think a bit. But I
> > can't resist to answer right now (also I may change my mind after some
> > thoughts): A point having two variables is a 2d-object, a point with 3
> > variables is a 3d-object. And each position as a special meaning (i.e.
> > x, y, z). So here we have a tuple, not a list.
> 
> Same thing, IMO. I think tuples in Python are really worthless in most
> cases. The only thing they'd buy us here would be immutability. (One
> could argue that that would be a good thing here, in accordance with
> the Value pattern.)
> 
> But that doesn't really matter, IMO. Whether you do
> 
>   point([1, 2, 3])
> 
> or
> 
>   point((1, 2, 3))
> 
> is completely irrelevant (as long as you stay away from the
> naughtiness of type checking ;).

I'm not so sure. To me it makes a difference. A tuple is something,
where the items do have a fixed, specific position and the meaning of
the items might be different depending on their position. Hence a
crucial feature of tuples is to be immutable in their length. Well,
they are immutable in their values as well, but this keeps to be
strange to me. It's kind of unpythonic ... well. I don't know.

Vectors, where each component is a value for a certain dimension is
not a very good example for that discussion, I think. At least when
all dimensions are equal to each other like in an Euclid space. May be
the theory of relativity with its four component vectors is a
resonable example even for a vector being a tuple, not a list ...

Beside that, you're right. We should forget about type checking and
than it usually becomes unimportant.

> The real difference is between this
> and
> 
>   point(1, 2, 3)
> 
> Even the numarray arrays use the first form, as do, really, all
> sequence types, including tuples.

In my redesign I'm only left with a single vector class. Here I'm
using the list like version to create a constant and a plain number to
specify a variable vectors dimension. I'm not sure whether you'll like
this syntax in the end, but the user is left with just a scalar and a
vector. Period. That's nice, I think, but we can discuss those details
and the naming again once we see how it works out.

> I'm just saying that the "standard" constructor for sequence
> types admits a single iterable objects as its argument.

BTW: How invented this stange *single* iterable object. I would really
like to be allowed to use several of them. This limitation is annoying
and unnecessary to me. (I haven't thought very hard about that, but I
really don't see any reasoning why this limitation exist.)


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] Great!

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

Hi,

On 29.07.04, Magnus Lie Hetland wrote:
> > I've just checked in another version, which gets rid of "==" and
> > becomes even nicer. What we'll need additionally is a "whatever"
> > used in front of a vector (or point, if its not a variable).
> 
> That would be nice, yes. But, in MetaPost, IIRC, 'whatever' is
> actually a completely normal variable -- it's just a new variable each
> time it's used. Isn't it? In that case you could just use var() (or
> whatever the constructor is) instead of whatever...
> 
> But I guess it's highly probable that I've missed some snag here.

I think, you are right (for MetaPost), but not for solve.py. In
MetaPost whatever is just a "unnamed" scalar variable typically used
in the following way:

scalar() * point(0, 1)

Unfortunately, this fails with the current version of solve.py. (Even
scalar() * point(0) fails, because point is a vector, but scalar() is
a scalar.)

I have to come around that. And as more as I think about it, it become
clearer, that I need a second try for the term class (fixing this
issue as well as the limitation to linear terms). I've already started
something *really* cool yesterday evening, but didn't yet finished it.
Don't worry, I'm almost there, I think. So stay tuned ... ;-)

> > BTW, the name point (for a constant vector) vs. vector (for a
> > variable vector) might be worth a discussion.
> 
> Yeah, I thought about that when I read the code, but didn't comment on
> it. Doesn't sound completely obvious to me. (*Must* they be two
> separate classes?)

No, you're right! This was an important point to me. I'm working along
that line. So thanks, this discussion helps me a lot ...


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] Great!

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

Andre Wobst <wo...@us...>:
>
> Hi Magnus,
>=20
> On 29.07.04, Magnus Lie Hetland wrote:
> > Just looked at solve.py (which finally made it through CVS to my
> > machine) -- looks great! :)
>=20
> I should tell you, that I still can't resist on that topic.

Hah! Even better! Keep up that addiction ;)

> I've just checked in another version, which gets rid of "=3D=3D" and
> becomes even nicer. What we'll need additionally is a "whatever"
> used in front of a vector (or point, if its not a variable).

That would be nice, yes. But, in MetaPost, IIRC, 'whatever' is
actually a completely normal variable -- it's just a new variable each
time it's used. Isn't it? In that case you could just use var() (or
whatever the constructor is) instead of whatever...

But I guess it's highly probable that I've missed some snag here.

> BTW, the name point (for a constant vector) vs. vector (for a
> variable vector) might be worth a discussion.

Yeah, I thought about that when I read the code, but didn't comment on
it. Doesn't sound completely obvious to me. (*Must* they be two
separate classes?)

If you could emulate the numarray/Numeric behavior of the array class
you could name it array (this name is already used for differet kinds
of arrays, e.g. in the  built-in array module). Then the variable kind
could be vararray (just like numarray has, for example, chararray and
recarray).

Then you could even get around my quibble about the constructor...

def point(x, y, z=3DNone):
    if z is not None:
        return array([x, y, z])
    return array([x, y])

(Similar for varpoint, perhaps.)

Or maybe I'm just muddling things here.

But using varpoint (or something like that) instead of vector might
have a more obvious meaning.

> Next step is to properly handle (intermediate) non-linear terms. I
> already thought about it a little, and I think I know what to do (at
> least I have the current impression to know what to do).

Great. I think this sort of thing is another feature that will put PyX
way ahead of most similar packages. (The only serious contender is
MetaPost anyway, it would seem.)

> Too bad, that the anonymous CVS is behind all the time ...

Actually, I got it now. Hm.

> 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...>:
>
> Hi,
>=20
> On 29.07.04, Magnus Lie Hetland wrote:
> > > Sounds like something to be build finite size canvas aka canvas wit=
h a
> > > border aka boxes (in the future). I'll try to keep it in mind.
> >=20
> > Sounds good.
>=20
> Have you read this as: "Sounds like something to be build *on* *top*
> *of* finite size canvas aka canvas with a ...". That's what I wanted
> to say ...

OK. Didn't read it that thoroughly, really -- I just thought it looked
good that something was possible here.

[snip]
> Hmmm. I think I'm looking at it the other way around: We already have
> a memory representation of what we want to output. I certainly do not
> want to write a PostScript interpreter.

No, no -- this was slightly humorous, I guess... That if you didn't
want to use a back-end API I could still pretend the EPS output was
front-end-to-back-end communication and use a PS interpreter in my own
back-end code, to convert things to my own memory representation. :)

> (There is one, already.)

Of course.

[snip]
> > No, I see. Does this mean that adding stuff like PDF and SVG is going
> > to be Hard Work(tm)?
>=20
> Not at all. You may have noticed, that you can already say
> writePDFfile and it behaves quite well most of the times. You can
> write whole graphs including text into pdf already. But this *is*
> highly experimental. I've already started a pdfwriter, which is the
> second try, which points into the right direction for the future, I
> guess.

Excellent :)

[snip]
> Right. And I draw the line at the native PyX output formats. Sure you
> can use a PostScript interpreter afterwards. Indeed, that's always
> done. It might be a RIP in a PostScript printer, but still ...

Well... If you have pdfwriter objects and the line, couldn't I write
an (external) antigrainwriter (or something) for example?

Just thinking here... As long as you output (say) SVG, interpreting
this and using it for (say) display graphics should be easy anyway.

PS, PDF and SVG is a nice trio.

[snip]
> There is some kind of transparency in pdf as well.

Hm. Right.

> But I'm not well informed about it.

Me neither.

> Might come with time ...
>=20
> > Anyway, PyX r teh pwnz0r! ;)
>=20
> ??? (I'm sorry, I don't speak that language. Seriously.)

Heh. See explanation in my previous posting.

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

Joerg Lehmann <jo...@us...>:
>
> While I'm not necessarily against doing so, I still think that having
> native support for some of the more popular vector formats is really a
> good idea. Consider for instance the transparency support, which does
> not exist in PostScript. How would you like to do that with
> a converter.

Sure, sure! I'm definitely *not* arguing against native support. This
was more like a temporary (or additional) feature.

If PyX could do SVG, that would be *excellent*. Imagine real tex
layout, transparency and filters in one and the same figure... Wooo.
:)

[snip]
> I think that we should focus on vector graphic formats which are built
> according to the PostScript model, which has already been quite well
> abstracted in PyX.

Yep; sounds very reasonable (as I also said elsewhere).

> But lowest common denominator would exclude things like transpacerency.

You are right. (It would have to be a "sliding scale" sort of thing, I
guess -- but that would also have to be the case with PyX supporting
SVG alongside PS, for example.)

> [snip]
> > 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.) ;)
>=20
> Well said. The more I've learnt about PDF and SVG there more I've becom=
e
> a PostScript fan.

Yes. PostScript is one of my favourite languages -- and not just
graphics languages. It's a pretty little programming language too. The
other two just really suck in that department (and the aren't even
Turing complete... Bah! ;)

[snipped about extra SVG features]
> As I said above, this should be possible. Realistically, this will also
> mean that some features are not supported by a specific backend,
> although they are supported by the output format, just because nobody
> has written the code. ;-)

Of course. After all, SVG has *lots* of features :)

> > Anyway, PyX r teh pwnz0r! ;)
>=20
> I'll bite. What does it mean?

Heh. Just an attempt at l33t sp33k. "r teh" as in "are the" as in "is
the". "pwn" as in "own"; "pwnz0r" as in "ownzor" as in "owner" as in
"the coolest" (or something; as in "i pwn u" or "I own you" from
online gaming and the like).

IOW, PyX rulez -- it's kewl :)

Seriously, I think it's a serious contender as one of the de facto
standard graphics packages for Python. I've been using ReportLab a bit
(it is in some areas sort of similar to Piddle/Sping, and, I think,
inspired by them) but the support for typography (through TeX and the
like) is, of course, completely missing. And PyX is just so much
cooler in many other ways too, so... ;)

Oh, enough, already... I've got to get out into the sun while I still
have some holiday left.

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

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

Hi,

On 29.07.04, Magnus Lie Hetland wrote:
> > 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.

Have you read this as: "Sounds like something to be build *on* *top*
*of* finite size canvas aka canvas with a ...". That's what I wanted
to say ...

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

I think there currently is a difference between MetaPost and PyX. In
MetaPost there is a picture type. Its similar to a canvas in PyX. But
AFAIK MetaPost allows to access all items in this picture. You can
fiddle along that line in PyX as well, but my current intension is,
that this would be "behind the scenes".

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

Right. Its about that. And it already tells you, that we want to be
able to add support for whatever we'll need for a given output format,
although it can't be expressed in PostScript ...

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

Hmmm. I think I'm looking at it the other way around: We already have
a memory representation of what we want to output. I certainly do not
want to write a PostScript interpreter. (There is one, already.) And
why should I read some strange output and try to find out, which
gsave/grestore matchs each other. We already have a canvas with local
draw attributes (colors etc.) inside. No need to worry ...

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

Not at all. You may have noticed, that you can already say
writePDFfile and it behaves quite well most of the times. You can
write whole graphs including text into pdf already. But this *is*
highly experimental. I've already started a pdfwriter, which is the
second try, which points into the right direction for the future, I
guess.

> > 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?

Sure.

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

Right. And I draw the line at the native PyX output formats. Sure you
can use a PostScript interpreter afterwards. Indeed, that's always
done. It might be a RIP in a PostScript printer, but still ...

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

There is some kind of transparency in pdf as well. But I'm not well
informed about it. Might come with time ...

> Anyway, PyX r teh pwnz0r! ;)

??? (I'm sorry, I don't speak that language. Seriously.)


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

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

Andre Wobst <wo...@us...>:
>
[snip]
>=20
> I'm not totally convinced, but I might need to think a bit. But I
> can't resist to answer right now (also I may change my mind after some
> thoughts): A point having two variables is a 2d-object, a point with 3
> variables is a 3d-object. And each position as a special meaning (i.e.
> x, y, z). So here we have a tuple, not a list.

Same thing, IMO. I think tuples in Python are really worthless in most
cases. The only thing they'd buy us here would be immutability. (One
could argue that that would be a good thing here, in accordance with
the Value pattern.)

But that doesn't really matter, IMO. Whether you do

  point([1, 2, 3])

or

  point((1, 2, 3))

is completely irrelevant (as long as you stay away from the
naughtiness of type checking ;). The real difference is between this
and

  point(1, 2, 3)

Even the numarray arrays use the first form, as do, really, all
sequence types, including tuples.

> (There *are* cases, where we have tuples, not lists.)

As I said, there's really no practical difference, IMO.

> In that sense I think its different from the attribute discussion
> ...

Sure. I'm just saying that the "standard" constructor for sequence
types admits a single iterable objects as its argument.

And if one stays away from type checking, one could even use future
enhancements, such as the upcoming generator comprehensions, such as:

  b =3D point(x**2 for x in a)

:)

You *could*, of course, still do

  b =3D point(*[x**2 for x in a])

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]

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

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

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

While I'm not necessarily against doing so, I still think that having
native support for some of the more popular vector formats is really a
good idea. Consider for instance the transparency support, which does
not exist in PostScript. How would you like to do that with
a converter.

[snip]
> 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?

I think that we should focus on vector graphic formats which are built
according to the PostScript model, which has already been quite well
abstracted in PyX.

> > 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 ...
> 
> Sure. Lowest common denominator is fine. That's what Piddle does,
> anyway.

But lowest common denominator would exclude things like transpacerency.

[snip]
> 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.) ;)

Well said. The more I've learnt about PDF and SVG there more I've become
a PostScript fan.

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

Yes, indeed.

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

As I said above, this should be possible. Realistically, this will also
mean that some features are not supported by a specific backend,
although they are supported by the output format, just because nobody
has written the code. ;-)

> Anyway, PyX r teh pwnz0r! ;)

I'll bite. What does it mean?

        Jörg

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

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

Hi,

On 29.07.04, Magnus Lie Hetland wrote:
> 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.

I could already remove that, once I stopped misusing equality. (But I
think, the solution of these two topics were not really releated. The
solution was to introduce self.zero in variable and vector. But is
doesn't matter.)

> > > 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?
> 
> No, no -- the above is just the use of a keyword argument.

I'm so stupid. Right, now I understand. Still, I don't like it and it
doesn't seems necessary.

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

I'm not totally convinced, but I might need to think a bit. But I
can't resist to answer right now (also I may change my mind after some
thoughts): A point having two variables is a 2d-object, a point with 3
variables is a 3d-object. And each position as a special meaning (i.e.
x, y, z). So here we have a tuple, not a list. (There *are* cases,
where we have tuples, not lists.) In that sense I think its different
from the attribute discussion ...


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] Great!

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

Hi Magnus,

On 29.07.04, Magnus Lie Hetland wrote:
> Just looked at solve.py (which finally made it through CVS to my
> machine) -- looks great! :)

I should tell you, that I still can't resist on that topic. I've just
checked in another version, which gets rid of "==" and becomes even
nicer. What we'll need additionally is a "whatever" used in front of a
vector (or point, if its not a variable). BTW, the name point (for a
constant vector) vs. vector (for a variable vector) might be worth a
discussion. Next step is to properly handle (intermediate) non-linear
terms. I already thought about it a little, and I think I know what to
do (at least I have the current impression to know what to do).

Too bad, that the anonymous CVS is behind all the time ...


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] Great!

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

Just looked at solve.py (which finally made it through CVS to my
machine) -- looks great! :)

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