Re: [PyX-user] PyX with scipy/numpy

[William Henney <w.henney@as...>]

Hi list,

On 8/6/07, Michael SCHINDLER <m-schindler@...> wrote:
> > Well, I do know that there are scipy users on that list. You're not
> > alone ... :-)

I rarely use scipy but I do use PyX a lot with numpy arrays, which
seems to be what is really being discussed, so maybe I am qualified to
comment.

>
> > > Rather than renaming the old 'list' class you could add the above cla=
ss
> > > as something like a 'vector' or 'array' class.
>
> > Hmmm. Ok, both could be done. Still, even after a few days, I still
> > very much like the idea of using lists and points as the new names.
> > It would be nice to get some feedback from others (users and
> > developers ... :-) ).
>
> +1 for renaming the data into "points": I always have to look up how
> the current "list" is to be created. In most cases, I use a "zip(a,
> b)" for that, meaning that the new "lists" will make it more easy for
> me.
>

I would also favour remaning the current "list" as "points".

For the new class, I would be happy with either "lists" or "vectors",
but not with any of the other suggestions.

> I suggest, however, to use "coordinates" or "values" instead of
> "lists", as all names such as "array", "vector", "list", "lists" do
> not specify what is stored and thus do not indicate the logics of its
> use.
>

No, I think this is wrong. To me "values" is too vague and
"coordinates" implies a list of (x, y) pairs - think about the meaning
of "co" in "coordinate". This is the opposite of what the new class
provides, which is a pair of lists, not a list of pairs. That is why I
favour "lists" or "vectors". The only problem with "vectors" is that
there is a potential ambiguity between "vector" in the numpy sense (a
1-dimensional array of values) and "vector" in the geometry sense,
which might be confusing for some users.

Cheers

Will


--

  Dr William Henney, Centro de Radioastronom=EDa y Astrof=EDsica,
  Universidad Nacional Aut=F3noma de M=E9xico, Campus Morelia

Re: [PyX-user] PyX with scipy/numpy

[Andre Wobst <wobsta@us...>]

Hi Michael,

thanks for contributing.

On 06.08.07, Michael SCHINDLER wrote:
> +1 for renaming the data into "points": I always have to look up how
> the current "list" is to be created. In most cases, I use a "zip(a,
> b)" for that, meaning that the new "lists" will make it more easy for
> me.

Fine! And the zip really is a waist of resouces, since the points are
"unziped" again internally. (BTW this was of course not the case
originally, but I've changed the internal data structures a few
releases ago (I think along or a little after the graph style rework)
... it was centered around the points originally, since that's how
data in files is organized, but it makes it very complicated to pass
data around for the axes adjustment etc. and I finally simplified a
lot of code internally by this internal change.)

> I suggest, however, to use "coordinates" or "values" instead of
> "lists", as all names such as "array", "vector", "list", "lists" do
> not specify what is stored and thus do not indicate the logics of its
> use.

Good point. Since coordinates as a name really is a bit too long, I
would then go for values.

Maybe there's another important distinction: In case of the points
class there is a first parameter containing the actuall data and the
other kwargs are integers (indexing the point tuples starting at the
index 1). For the values there are those kwargs only containing the
values (as lists) directly. (I'm ignoring some special features like
the data title here.) But in terms of finding a name this doesn't seem
to help much ...

Lets wait a little longer to see, whether other options turn up. But
from my side "points" and "values" are ok already (even taking into
account, that we rarely should do such name changes at all) ...


André

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

Re: [PyX-user] PyX with scipy/numpy

[Michael SCHINDLER <m-schindler@us...>]

On 06.08.07, Andre Wobst wrote:
> On 06.08.07, BK wrote:
> > It's indeed very simple and after seeing your solution and looking again
> > at the 'list' class I feel a little stupid for not figuring it out
> > myself. I don't know about other scipy users (if there are any others
> > using PyX, after all scipy comes with its own plotting module
> > 'matplotlib') but for me it's exactly what I needed.
> 
> Well, I do know that there are scipy users on that list. You're not
> alone ... :-)

> > Rather than renaming the old 'list' class you could add the above class
> > as something like a 'vector' or 'array' class.

> Hmmm. Ok, both could be done. Still, even after a few days, I still
> very much like the idea of using lists and points as the new names.
> It would be nice to get some feedback from others (users and
> developers ... :-) ).

+1 for renaming the data into "points": I always have to look up how
the current "list" is to be created. In most cases, I use a "zip(a,
b)" for that, meaning that the new "lists" will make it more easy for
me.

I suggest, however, to use "coordinates" or "values" instead of
"lists", as all names such as "array", "vector", "list", "lists" do
not specify what is stored and thus do not indicate the logics of its
use.

Michael.

-- 
Michael Schindler
  Laboratoire de Physico-Chimie Théorique.
  ESPCI. 10 rue Vauquelin, 75231 Paris cedex 05, France.
  Tel: +33 (0)1 40 79 45 97    Fax: +33 (0)1 40 79 47 31
  http:  http://www.pct.espci.fr/~michael

Re: [PyX-user] PyX with scipy/numpy

[Andre Wobst <wobsta@us...>]

Hi,

On 06.08.07, BK wrote:
> It's indeed very simple and after seeing your solution and looking again
> at the 'list' class I feel a little stupid for not figuring it out
> myself. I don't know about other scipy users (if there are any others
> using PyX, after all scipy comes with its own plotting module
> 'matplotlib') but for me it's exactly what I needed.

Well, I do know that there are scipy users on that list. You're not
alone ... :-)

> Rather than renaming the old 'list' class you could add the above class
> as something like a 'vector' or 'array' class.

Hmmm. Ok, both could be done. Still, even after a few days, I still
very much like the idea of using lists and points as the new names.
It would be nice to get some feedback from others (users and
developers ... :-) ).

André

> > While I kind of dislike the above notation (d[0] and d[1] are
> > completely independed) and thus I focused on "points" in
> > pyx.graph.data.list, why not just add the lists class to PyX as well?
> > Maybe the name is not perfect. Well, "list" was not a good idea at
> > all ... I could think of renaming the old "list" to "points" and
> > adding the "lists" class as shown above. I know that'll break quite
> > some code and we could add some deprecated "list = points" to
> > pyx.graph.data ...

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

Re: [PyX-user] Class text - how to individually specify label position (Andre Wobst)

[Andre Wobst <wobsta@us...>]

Hi Gabrielle,

you may use the svn browser by sourceforge to grab the current
style.py at:
http://pyx.svn.sourceforge.net/viewvc/pyx/trunk/pyx/pyx/graph/style.py

Just take the enhanced version of the text class from that file ... it
should add the dxtext/dytext features as requested.

Best,

André

On 06.08.07, Gabrielle David wrote:
> Hi,
> 
> Thanks for the reply. Sorry but I am not particularly computer savy, what is
> svn? And how exactly do I use it on top of Pyx 0.9?
> 
> Cheers,
> Gabrielle
> 
> 
> On 8/1/07 10:51 PM, "pyx-user-request@..."
> <pyx-user-request@...> wrote:
> 
> > Re: Class text - how to individually specify label position
> >       (Andre Wobst)
> 
> > Hi Gabrielle,
> 
> >Sorry for the confusion. The doc you're looking at seems to come from
> >the current development branch. The dxunit/dyunit feature was added
> >after the PyX 0.9 release. Still, you can take the text style from svn
> >and use it on top of PyX 0.9. Shouldn't make any problems.
> 
> >Best
> 
> >Andr?
> 
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> PyX-user mailing list
> PyX-user@...
> https://lists.sourceforge.net/lists/listinfo/pyx-user

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

Re: [PyX-user] PyX with scipy/numpy

[BK <lists@be...>]

Hi Andr=C3=A9,

Am Mittwoch, den 01.08.2007, 17:27 +0200 schrieb Andre Wobst:
> Hi all,
>=20
> On 25.07.07, BK wrote:
> > > is there any way to directly plot scipy/numpy-type arrays? I am readi=
ng
> > my data using the scipy.array_import.read_array() method and then doing
> > some data manipulations based on the scipy arrays.
> > Before plotting I currently write the data from the arrays into a list
> > which can be read by the pyx.graph.graphxy.plot() method. Would it be
> > possible to add scipy-type array data to the plot() method of a graph?
>=20
> Sure ... and its even trivial to implement new data providers for pyx.
> (Let me call instances of the classes defined in pyx.graph.data to be
> "data providers".) Well, there are some non-trivial features in the
> data providers. Think of functions, where the range the function is
> evaluated may depend on the range of the corresponding axes. But those
> things really are advanced features and simple data providers don't
> need to deal with such stuff at all.
>=20
> The point is that (1) I do not know what people want and need and (2)
> I'm not an scipy user at all. OTOH I do know that pyx.graph.data
> really is very limited in terms of manipulating data. And it's also
> slow. So we just need to find out what's needed for all of you, guys,
> and I'll try to add an appropriate data provider to PyX. I'm sure
> thats better than reimplementing features found in scipy. It's fine
> that PyX comes with some useful data providers, since PyX users really
> should not need to scipy in the first place. But those of you who are
> beeing happy scipy users should get the power out of scipy + PyX most
> easily. Ok, enough blah, blah ...
>=20
> There is the pyx.graph.data.list class, which takes a list of lists
> and an columns dictionary. For example:
>=20
> d =3D pyx.graph.data.list([[1, 2], [3, 4]], x=3D1, y=3D2)
>=20
> (and than proceed with g.plot(d) ...)
>=20
> This means that you have two points, the first one with x=3D1 and y=3D2
> and the second one with x=3D3 and y=3D4.
>=20
> I've just tried to use read_array and provide a useful "adapter" for
> PyX. This looks the following:
>=20
>     from scipy.io import read_array
>     from pyx import *
>=20
>     class lists(graph.data._data):
>=20
>         defaultstyles =3D [graph.style.symbol()]
>=20
>         def __init__(self, title=3D"user provided lists", **columns):
>             self.columns =3D columns
>             self.columnnames =3D columns.keys()
>             self.title =3D title
>=20
>     d =3D read_array("scipytest.dat")
>     g =3D graph.graphxy(width=3D10)
>     g.plot(lists(x=3Dd[0], y=3Dd[1]))
>     g.writeEPSfile("scipytest")
>=20
Your little adapter does the trick, thanks a lot!
It's indeed very simple and after seeing your solution and looking again
at the 'list' class I feel a little stupid for not figuring it out
myself. I don't know about other scipy users (if there are any others
using PyX, after all scipy comes with its own plotting module
'matplotlib') but for me it's exactly what I needed.

Rather than renaming the old 'list' class you could add the above class
as something like a 'vector' or 'array' class.

Thanks again!

Benedikt

> It's that simple. You really need to understand, that the PyX data
> instances are very thin wrappers and maybe we should even more focus
> on that. While I kind of dislike the above notation (d[0] and d[1] are
> completely independed) and thus I focused on "points" in
> pyx.graph.data.list, why not just add the lists class to PyX as well?
> Maybe the name is not perfect. Well, "list" was not a good idea at
> all ... I could think of renaming the old "list" to "points" and
> adding the "lists" class as shown above. I know that'll break quite
> some code and we could add some deprecated "list =3D points" to
> pyx.graph.data, but let's keep the focus: Does the signature of the
> lists class shown above match the scipy users needs? Or should it look
> differently?
>=20
>=20
> Andr=C3=A9
>=20

Re: [PyX-user] Class text - how to individually specify label position (Andre Wobst)

[Gabrielle David <gabrielle.david@gm...>]

Hi,

Thanks for the reply. Sorry but I am not particularly computer savy, what is
svn? And how exactly do I use it on top of Pyx 0.9?

Cheers,
Gabrielle


On 8/1/07 10:51 PM, "pyx-user-request@..."
<pyx-user-request@...> wrote:

> Re: Class text - how to individually specify label position
>       (Andre Wobst)

> Hi Gabrielle,

>Sorry for the confusion. The doc you're looking at seems to come from
>the current development branch. The dxunit/dyunit feature was added
>after the PyX 0.9 release. Still, you can take the text style from svn
>and use it on top of PyX 0.9. Shouldn't make any problems.

>Best

>Andr?

Re: [PyX-user] pyx, scores

[<rbastian@fr...>]

Hello,

I will try to write a little python with
the path.moveto ... (r)lineto etc.

-- 
René Bastian
http://www.musiques-rb.org
http://pythoneon.musiques-rb.org

Re: [PyX-user] pyx, scores

[Alan G Isaac <aisaac@am...>]

I have not paid attention do this thread,
so my comments may prove off topic.

What I just read seemed to involve creating
an entire score and then breaking it into
pages, which is quite a different approache
than I would take.

I think at a minimum you need these objects:
bar
page
score

Process your array into a list of bars.
Process your list of bars into a list of pages.

If you can use a fixed page layout,
this should not be too hard.
But creating a nicely laid out page will
take some time.

Again, apologies if this proves OT.

Cheers,
Alan Isaac

PS Is there any reason not to use Lilypond?
http://lilypond.org/web/

Re: [PyX-user] pyx, scores

[<rbastian@fr...>]

Le Mercredi  1 Août 2007 12:37, Andre Wobst a écrit :
> Hi,
>
> you may not want to deal with clipping etc. at all. Just place your
> large canvas at different positions on several pages. It should harm
> any PostScript device/RIP ... it'll throw away all things outside of
> the printable area. Example:
>
>     from pyx import *
>
>     c = canvas.canvas()
>     c.text(0, 10, "This is huge!", [trafo.scale(50)])
>
>     d = document.document()
>     for i in range(5):
>         c2 = canvas.canvas()
>         c2.insert(c, [trafo.translate(-20*i, 0)])
>         d.append(document.page(c2, centered=0,
>                                paperformat=document.paperformat.A4))
>     d.writePSfile("banner")
>
> Best,
>
> André

To make a score a have a great number (100, ...) of 1-D arrays.
The best way for me would be a call like

c.plot(x, y, the_array)

with axes on each page (graphxy plots axes for each array - it's not
what I need).

Regards,

-- 
René B.

Re: [PyX-user] Caching of pyx.document ?

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

Hi Alan,

On 02.08.07, Alan G Isaac wrote:
> Well of course there have been other views on this.
> Guido's own comment on the absence was:
> "there isn't a real good reason."

Interesting, this I didn't know.

> And my personal view is that these methods should be 
> available for tuples, thereby encouraging the the good 
> practice of using tuples when immutability is a relevant 
> property.
> 
> Anyway, this seems a bit OT for this list, so you can have 
> the last word.  (I.e., I'll shut up now.)

I take the last word and admit that there are different "schools"
concerning the whole tuple-vs-list issue. In principle, one could
argue that Python is missing an immutable list type ;-) But
you're right: this is really off-topic...

Cheers,

        Jörg

Re: [PyX-user] Caching of pyx.document ?

[Alan G Isaac <aisaac@am...>]

On Thu, 2 Aug 2007, Joerg Lehmann apparently wrote:
> I can only guess that you were speaking about the index 
> and count methods, which are the only list methods that do 
> not modify the list.

Right.

> I meant that although being compatible with the 
> immutability property they do not make much sense for 
> tuples. 

Well of course there have been other views on this.
Guido's own comment on the absence was:
"there isn't a real good reason."
And my personal view is that these methods should be 
available for tuples, thereby encouraging the the good 
practice of using tuples when immutability is a relevant 
property.

Anyway, this seems a bit OT for this list, so you can have 
the last word.  (I.e., I'll shut up now.)

Cheers,
Alan

Re: [PyX-user] Caching of pyx.document ?

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

Hi Alan,

On 01.08.07, Alan G Isaac wrote:
> >> Sadly tuples still lack some useful methods they should 
> >> have: are these needed?)
> 
> On Wed, 1 Aug 2007, Joerg Lehmann apparently wrote:
> > If you need such methods, you almost certainly don't want to 
> > use tuples but a list. 
> 
> I meant, does PyX ever use such methods when processing read 
> only attributes?  If not, then tuples could be used,
> thereby taking advantage of immutability.  (A natural
> match to "read only".)

This question is difficult to answer without knowing the methods you
refer to. I can only guess that you were speaking about the index and
count methods, which are the only list methods that do not modify the
list. I meant that although being compatible with the immutability
property they do not make much sense for tuples.

Cheers,

        Jörg

Re: [PyX-user] Caching of pyx.document ?

[Alan G Isaac <aisaac@am...>]

>> Sadly tuples still lack some useful methods they should 
>> have: are these needed?)

On Wed, 1 Aug 2007, Joerg Lehmann apparently wrote:
> If you need such methods, you almost certainly don't want to 
> use tuples but a list. 

I meant, does PyX ever use such methods when processing read 
only attributes?  If not, then tuples could be used,
thereby taking advantage of immutability.  (A natural
match to "read only".)

Cheers,
Alan Isaac

Re: [PyX-user] Caching of pyx.document ?

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

Hi Alan,

On 01.08.07, Andre Wobst wrote:
> On 01.08.07, Alan G Isaac wrote:
> > On Wed, 1 Aug 2007, Andre Wobst apparently wrote:
> > > For read-only attribute no copy is necessary and should 
> > > not be made. 
> > 
> > Perhaps use a tuple instead of a list for read only 
> > attributes?  (Sadly tuples still lack some useful methods 
> > they should have: are these needed?)

If you need such methods, you almost certainly don't want to
use tuples but a list.

> -1 to that. Tuples are tuples and not lists. As I'm writing rules of
> thumb today, let me add a whole list here.

I fully agree with all of the points and just want to add for
the more mathematically inclined that tuples are nothing more
than cartesian products.

        Jörg

Re: [PyX-user] Caching of pyx.document ?

[Andre Wobst <wobsta@us...>]

Hi Alan,

On 01.08.07, Alan G Isaac wrote:
> On Wed, 1 Aug 2007, Andre Wobst apparently wrote:
> > For read-only attribute no copy is necessary and should 
> > not be made. 
> 
> Perhaps use a tuple instead of a list for read only 
> attributes?  (Sadly tuples still lack some useful methods 
> they should have: are these needed?)

-1 to that. Tuples are tuples and not lists. As I'm writing rules of
thumb today, let me add a whole list here.

  - Tuples containing no elements should never occur.

  - Tuples containing only one element should never occur.

  - Tuples should usually contain different elements of different
    type, or at least different meaning. A point (x, y) is perfect.
    That's a tuple, not a list. X is one coordinate, y the other.
    Different meaning.

  - Tuples are basically a simple (and ugly, but speedy and
    memory-efficient) way of expressing:

        class point:

            def __init__(self, x, y):
                self.x = x
                self.y = y

    This means p = (x, y) should better be written as p = point(x, y)
    and p[0] and p[1] should become p.x and p.y. The bracket notation
    of tuples looks like tuples are similar to lists, but they aren't.
    To my mind they are just a quick and dirty way of expressing some
    code as shown in the point example above.

  - Tuples are useful as dictionary keys, and that's about it.

(I know not all off the points are valid in all cases, but they are
good coding rules to start with ... at least if you ask me. :-) )

Overall, don't use tuples. If you're a python beginner, never use
tuples at all ... :-)

Well, I'm a bit crude today, but ... this advice it not that bad.


André

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

Re: [PyX-user] PyX with scipy/numpy

[Andre Wobst <wobsta@us...>]

Hi all,

On 25.07.07, BK wrote:
> > is there any way to directly plot scipy/numpy-type arrays? I am reading
> my data using the scipy.array_import.read_array() method and then doing
> some data manipulations based on the scipy arrays.
> Before plotting I currently write the data from the arrays into a list
> which can be read by the pyx.graph.graphxy.plot() method. Would it be
> possible to add scipy-type array data to the plot() method of a graph?

Sure ... and its even trivial to implement new data providers for pyx.
(Let me call instances of the classes defined in pyx.graph.data to be
"data providers".) Well, there are some non-trivial features in the
data providers. Think of functions, where the range the function is
evaluated may depend on the range of the corresponding axes. But those
things really are advanced features and simple data providers don't
need to deal with such stuff at all.

The point is that (1) I do not know what people want and need and (2)
I'm not an scipy user at all. OTOH I do know that pyx.graph.data
really is very limited in terms of manipulating data. And it's also
slow. So we just need to find out what's needed for all of you, guys,
and I'll try to add an appropriate data provider to PyX. I'm sure
thats better than reimplementing features found in scipy. It's fine
that PyX comes with some useful data providers, since PyX users really
should not need to scipy in the first place. But those of you who are
beeing happy scipy users should get the power out of scipy + PyX most
easily. Ok, enough blah, blah ...

There is the pyx.graph.data.list class, which takes a list of lists
and an columns dictionary. For example:

d = pyx.graph.data.list([[1, 2], [3, 4]], x=1, y=2)

(and than proceed with g.plot(d) ...)

This means that you have two points, the first one with x=1 and y=2
and the second one with x=3 and y=4.

I've just tried to use read_array and provide a useful "adapter" for
PyX. This looks the following:

    from scipy.io import read_array
    from pyx import *

    class lists(graph.data._data):

        defaultstyles = [graph.style.symbol()]

        def __init__(self, title="user provided lists", **columns):
            self.columns = columns
            self.columnnames = columns.keys()
            self.title = title

    d = read_array("scipytest.dat")
    g = graph.graphxy(width=10)
    g.plot(lists(x=d[0], y=d[1]))
    g.writeEPSfile("scipytest")

It's that simple. You really need to understand, that the PyX data
instances are very thin wrappers and maybe we should even more focus
on that. While I kind of dislike the above notation (d[0] and d[1] are
completely independed) and thus I focused on "points" in
pyx.graph.data.list, why not just add the lists class to PyX as well?
Maybe the name is not perfect. Well, "list" was not a good idea at
all ... I could think of renaming the old "list" to "points" and
adding the "lists" class as shown above. I know that'll break quite
some code and we could add some deprecated "list = points" to
pyx.graph.data, but let's keep the focus: Does the signature of the
lists class shown above match the scipy users needs? Or should it look
differently?


André

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

Re: [PyX-user] Caching of pyx.document ?

[Alan G Isaac <aisaac@am...>]

On Wed, 1 Aug 2007, Andre Wobst apparently wrote:
> For read-only attribute no copy is necessary and should 
> not be made. 

Perhaps use a tuple instead of a list for read only 
attributes?  (Sadly tuples still lack some useful methods 
they should have: are these needed?)

Sorry if this is just noise,
Alan Isaac

Re: [PyX-user] Caching of pyx.document ?

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

On 01.08.07, Andre Wobst wrote:
> Michael,
> 
> On 01.08.07, Michael SCHINDLER wrote:
> > The first use of this as document.document() and then adding some
> > pages modifies the standard argument (which was [] initially). All
> > further instances are then initialized with this nonempty list.
> 
> Blame on us. Blame ... please ... :-)

Aii....

> > Which solution do you prefer:
> > 
> >   class document:
> >       def __init__(self, pages=[]):
> >           self.pages = pages[:]
> > 
> > 
> >   class document:
> >       def __init__(self, pages=None):
> >           if pages is None:
> >               self.pages = []
> >           else:
> >               self.pages = pages
> 
> I'm not sure. Personally I somehow favour the second option (which is
> quite Pythonic btw), but I remember a "bug" Jörg came up with some
> time ago. It was about an internal reordering of some attributes and
> it was done on the original list passed to the method. I understand
> that such a behaviour can be very troublesome and shouldn't be done
> for such an end-user library like PyX.
> 
> So let me formulate a rule of thumb: Go for option 1 for all
> attributes, which are not read-only. (For read-only attribute *no*
> copy is necessary and should not be made.) Jörg, do you agree?

Sounds very reasonable to me.

> > I will scan through the code to eliminate all other occurrences of
> > this problem.
> 
> Thanks a lot!

Thanks from me, as well. These kind of errors tend to be hard to spot.

        Jörg

Re: [PyX-user] Caching of pyx.document ?

[Michael SCHINDLER <m-schindler@us...>]

André,

On 01.08.07, Andre Wobst wrote:
> 
> So let me formulate a rule of thumb: Go for option 1 for all
> attributes, which are not read-only. (For read-only attribute *no*
> copy is necessary and should not be made.)

As it is easily possible in Python to overwrite data in instances
(also ones that are not "self"), it is sometimes hard to see what is
read-only. Especially in the graph module, complex use of foreign data
is made -- can I rely on the assumption that foreign data is used
read-only?

Michael.

-- 
Michael Schindler
  Laboratoire de Physico-Chimie Théorique.
  ESPCI. 10 rue Vauquelin, 75231 Paris cedex 05, France.
  Tel: +33 (0)1 40 79 45 97    Fax: +33 (0)1 40 79 47 31
  http:  http://www.pct.espci.fr/~michael

Re: [PyX-user] Caching of pyx.document ?

[Andre Wobst <wobsta@us...>]

Michael,

On 01.08.07, Michael SCHINDLER wrote:
> The first use of this as document.document() and then adding some
> pages modifies the standard argument (which was [] initially). All
> further instances are then initialized with this nonempty list.

Blame on us. Blame ... please ... :-)

> Which solution do you prefer:
> 
>   class document:
>       def __init__(self, pages=[]):
>           self.pages = pages[:]
> 
> 
>   class document:
>       def __init__(self, pages=None):
>           if pages is None:
>               self.pages = []
>           else:
>               self.pages = pages

I'm not sure. Personally I somehow favour the second option (which is
quite Pythonic btw), but I remember a "bug" Jörg came up with some
time ago. It was about an internal reordering of some attributes and
it was done on the original list passed to the method. I understand
that such a behaviour can be very troublesome and shouldn't be done
for such an end-user library like PyX.

So let me formulate a rule of thumb: Go for option 1 for all
attributes, which are not read-only. (For read-only attribute *no*
copy is necessary and should not be made.) Jörg, do you agree?

> I will scan through the code to eliminate all other occurrences of
> this problem.

Thanks a lot!


André

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

Re: [PyX-user] Caching of pyx.document ?

[Michael SCHINDLER <m-schindler@us...>]

Salut André,

On 01.08.07, Andre Wobst wrote:
> still, you have different instances in your example. The only problem
> in your example is, that the garbage collector throws away the
> document instance immediately again. Check this out:
> 
>     from pyx import *
> 
>     class slides:
>         def document(self):
>             d = document.document()
>             return d
> 
>     l = []
>     s = slides()
>     for i in range(4):
>         d = s.document()
>         print d
>         l.append(d)
> 
> ... and you'll get diffent instances. Still, you may have some kind of
> a problem ... and there might be bugs. But as far as your example is
> concerned, everything is fine.

You are right. That explains the equal memory addresses. I had,
however the problem that upon writing the second document, the content
of the first was still there. In the meanwhile, I found the reason for
that: the dangerous initialization of empty lists:

  class document:
      def __init__(self, pages=[]):
          self.pages = pages

The first use of this as document.document() and then adding some
pages modifies the standard argument (which was [] initially). All
further instances are then initialized with this nonempty list.

Which solution do you prefer:

  class document:
      def __init__(self, pages=[]):
          self.pages = pages[:]


  class document:
      def __init__(self, pages=None):
          if pages is None:
              self.pages = []
          else:
              self.pages = pages

I will scan through the code to eliminate all other occurrences of
this problem.

Michael.

-- 
Michael Schindler
  Laboratoire de Physico-Chimie Théorique.
  ESPCI. 10 rue Vauquelin, 75231 Paris cedex 05, France.
  Tel: +33 (0)1 40 79 45 97    Fax: +33 (0)1 40 79 47 31
  http:  http://www.pct.espci.fr/~michael

Re: [PyX-user] Class text - how to individually specify label position

[Andre Wobst <wobsta@us...>]

Hi Gabrielle,

Sorry for the confusion. The doc you're looking at seems to come from
the current development branch. The dxunit/dyunit feature was added
after the PyX 0.9 release. Still, you can take the text style from svn
and use it on top of PyX 0.9. Shouldn't make any problems.

Best

André

On 29.07.07, Gabrielle David wrote:
> Hi,
> 
> I have a graph where I want to label each symbol with its own text to
> identify it. I know I can do this using graph.style.text and specifying a
> text= column and a general dx= and dy= for placement. The problem with this
> is that since some of the symbols are close together the text labels then
> overlap.
> 
> So I would like to specify the positions of the symbol labels individually,
> to make the layout nicer. I was reading that you can do this by specifying a
> dxname= and a dyname= column containing values and then a dxunit= and a
> dyunit=. Well at this that is what I understand this to mean from the Pyx
> manual:
> "Alternatively you can specify a dxname and a dyname and provide appropriate
> data in those columns to be taken in units of dxunit and dyunit to specify
> the position of the text for each point separately."
> 
> I have tried this but it comes up with an error of " TypeError: __init__()
> got an unexpected keyword argument 'dxunit'"
> 
> I am not sure if this is the way I have my script set up or if I am
> misinterpreting what the dxname/dxunit functionality is for.
> 
> Could someone please tell me how to individually specify the position of the
> labels?
> 
> This is my script:
> 
> from pyx import*
> 
> text.set(mode="latex")
> 
> text.preamble("\usepackage{wasysym}")
> 
> text.preamble("\usepackage[version=3]{mhchem}")
> 
> c = canvas.canvas()
> 
> g1=graph.graphxy(width=8,x=graph.axis.linear(min=0,max=70,title="cumulative
> \%  
> yield"),y=graph.axis.linear(min=-20,max=20,title="$\delta$\ce{^{15}N}$_{AIR}
> $ \permil"))
> 
> g1.plot(graph.data.file("roomn.dat", x=2, y=3, text=1, dxname=4, dyname=5,
> title="precipitated at room
> temperature"),[graph.style.symbol(graph.style.symbol.square,
> size=0.15*unit.v_cm,
> symbolattrs=[deco.stroked([color.rgb.black]),deco.filled([color.rgb.white])]
> ), graph.style.text(dxunit=0.25*unit.v_cm, dyunit=0.25*unit.v_cm)])
> 
> c.insert(g1)
> 
> g2=graph.graphxy(width=8,x=graph.axis.linear(min=0,max=70,title="cumulative
> \%  
> yield"),y=graph.axis.linear(min=-30,max=30,title="$\delta$\ce{^{2}H}$_{SMOW}
> $ \permil"),ypos=g1.ypos+g1.height+2)
> 
> 
> g2.plot(graph.data.file("roomd.dat", x=2, y=3, text=1, dxname=4, dyname=5,
> title="precipitated at room
> temperature"),[graph.style.symbol(graph.style.symbol.square,
> size=0.15*unit.v_cm,
> symbolattrs=[deco.stroked([color.rgb.black]),deco.filled([color.rgb.black])]
> ), graph.style.text(dxunit=0.25*unit.v_cm, dyunit=0.25*unit.v_cm)])
> 
> c.insert(g2)
> 
> c.writePDFfile("room")
> 
> 
> 
> 
> 
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> PyX-user mailing list
> PyX-user@...
> https://lists.sourceforge.net/lists/listinfo/pyx-user

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

Re: [PyX-user] pyx, scores

[Andre Wobst <wobsta@us...>]

Hi,

you may not want to deal with clipping etc. at all. Just place your
large canvas at different positions on several pages. It should harm
any PostScript device/RIP ... it'll throw away all things outside of
the printable area. Example:

    from pyx import *

    c = canvas.canvas()
    c.text(0, 10, "This is huge!", [trafo.scale(50)])

    d = document.document()
    for i in range(5):
        c2 = canvas.canvas()
        c2.insert(c, [trafo.translate(-20*i, 0)])
        d.append(document.page(c2, centered=0,
                               paperformat=document.paperformat.A4))
    d.writePSfile("banner")

Best,

André


On 31.07.07, René Bastian wrote:
> Le Mardi 31 Juillet 2007 16:13, Michael SCHINDLER a écrit :
> > Salut René,
> >
> > On 31.07.07, René Bastian wrote:
> > > -- is it possible to extend a graph on several sheets ?
> > > (e.g. graphical scores)
> >
> > what do you mean with "sheets" and "graph"? In pyx, a "graph" is an
> > instance of the pyx.graph class, mainly used for plotting a function
> > or a data set.
> 
> OK, I meant "page" 
> 
> >
> > > -- how to manage it if a line goes beyond the limit of a sheet
> > > and has to be continued on the next sheet?
> >
> > If you mean "page" by "sheet", the answer is the following: You draw
> > your line on a "canvas" (that is an inifinitely extended canvas for
> > drawing) and write it into two different "pages" (which know about
> > paperformats etc). When writing, you can clip it to the paperformat
> > you want to have, or some smaller geometry.
> >
> > The point is that pyx does not do this automatically. You have to
> > shift the canvas appropriately before writing it a second time, taking
> > into account the clipping geometry. The amount of the shift you have
> > to calculate yourself.
> > Michael
> 
> Thanks for the tip
> 
> -- 
> René Bastian
> http://www.musiques-rb.org
> http://pythoneon.musiques-rb.org
> 
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> PyX-user mailing list
> PyX-user@...
> https://lists.sourceforge.net/lists/listinfo/pyx-user

André

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

Re: [PyX-user] Caching of pyx.document ?

[Andre Wobst <wobsta@us...>]

Hi Michael,

still, you have different instances in your example. The only problem
in your example is, that the garbage collector throws away the
document instance immediately again. Check this out:

    from pyx import *

    class slides:
        def document(self):
            d = document.document()
            return d

    l = []
    s = slides()
    for i in range(4):
        d = s.document()
        print d
        l.append(d)

... and you'll get diffent instances. Still, you may have some kind of
a problem ... and there might be bugs. But as far as your example is
concerned, everything is fine.

Best,

André


On 01.08.07, Michael SCHINDLER wrote:
> Salut,
> 
> I have a problem with creating different instances of the pyx.document
> class: I would like to have a "slides" class which writes out a number
> of slides in different ways (for beamer presentations, for handouts,
> with different sizes).
> 
> Unfortunately, when I create several pyx.document instances, they are
> all the same (having the same memory address)! See the enclosed
> minimal example. Is there an explanation for this behaviour?
> 
> # -------------------------
> from pyx import *
> 
> class slides:
>     def document(self):
>         d = document.document()
>         return d
> 
> s = slides()
> for i in range(4):
>     print s.document()
> # -------------------------
> 
> Michael.
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> PyX-user mailing list
> PyX-user@...
> https://lists.sourceforge.net/lists/listinfo/pyx-user

André

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