pyx-devel — PyX development

Re: [PyX-devel] Re: [PyX-user] bar chart x-axis custom labels

[pieter c. <pi...@cl...>]

Hi Andre,

> This is absolutely trivial to implement, but my concerns are, that you
> need to adjust the data to what's needed by the plotting system and
> not vice versa ...

I am not sure what you mean by this. My previous assumption was that the
issues related to parameters that typify a histogram (beyond a normal line
chart) are:
1. The borders of each step.
2. The width, position and height of each step.
3. The correct labeling of each step (which I assume will be sorted out
now that we can use a continues data axis)


> Nice idea to look into the wikipedia. It exactly shows the whole
> problem of a histogram: To fully describe a histogram, you need three
> informations per data point: a position, a width and a hight. The only
> problem is, that typically you do not have all the three informations
> kept in a data file. Thats why I don't know how to implement such a
> style. That's all. So we're back on my original question: What data
> should we start with?
>

Is this situation any clearer yet?

I did run your example code and attached is the result. Something looks
like it is not working. Any suggestions?

Regards,
Pieter

[PyX-devel] [ pyx-Bugs-1116257 ] color.palette.XXX fails with 1 item only.

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

Bugs item #1116257, was opened at 2005-02-04 16:41
Message generated for change (Settings changed) made by wobsta
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1116257&group_id=45430

Category: None
Group: None
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: color.palette.XXX fails with 1 item only.

Initial Comment:
Hi,

If I try to plot using change(stroked|filled) or
change(symbol) and provide only one item to plot,
things work out normally.

So I expected the same when using color.palette.XXX. 

The primary use of palette is for more than one dataset
but as people start plotting things automatically with
scripts (as I do), it may happen at times that the
script will have only one dataset to plot, so it would
be nice if it simpled worked with a single data set as
well. 

If crashing with 1 data set is the intended behaviour,
I think I would be beter to define a new exception type
to give the user a beter hint of what went wrong.

Francisco Borges 


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

Comment By: André Wobst (wobsta)
Date: 2005-02-07 07:28

Message:
Logged In: YES 
user_id=405853

Indeed, it is the intended behaviour. OTOH I've heared about others who 
complained about this as well. Might be its really better to allow for this 
(ab-) use case. I've checked in the enclosed patch.

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

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

[PyX-devel] [ pyx-Bugs-1116257 ] color.palette.XXX fails with 1 item only.

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

Bugs item #1116257, was opened at 2005-02-04 16:41
Message generated for change (Comment added) made by wobsta
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1116257&group_id=45430

Category: None
Group: None
Status: Open
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: color.palette.XXX fails with 1 item only.

Initial Comment:
Hi,

If I try to plot using change(stroked|filled) or
change(symbol) and provide only one item to plot,
things work out normally.

So I expected the same when using color.palette.XXX. 

The primary use of palette is for more than one dataset
but as people start plotting things automatically with
scripts (as I do), it may happen at times that the
script will have only one dataset to plot, so it would
be nice if it simpled worked with a single data set as
well. 

If crashing with 1 data set is the intended behaviour,
I think I would be beter to define a new exception type
to give the user a beter hint of what went wrong.

Francisco Borges 


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

>Comment By: André Wobst (wobsta)
Date: 2005-02-07 07:28

Message:
Logged In: YES 
user_id=405853

Indeed, it is the intended behaviour. OTOH I've heared about others who 
complained about this as well. Might be its really better to allow for this 
(ab-) use case. I've checked in the enclosed patch.

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

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

[PyX-devel] [ pyx-Bugs-1116257 ] color.palette.XXX fails with 1 item only.

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

Bugs item #1116257, was opened at 2005-02-04 07:41
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1116257&group_id=45430

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: color.palette.XXX fails with 1 item only.

Initial Comment:
Hi,

If I try to plot using change(stroked|filled) or
change(symbol) and provide only one item to plot,
things work out normally.

So I expected the same when using color.palette.XXX. 

The primary use of palette is for more than one dataset
but as people start plotting things automatically with
scripts (as I do), it may happen at times that the
script will have only one dataset to plot, so it would
be nice if it simpled worked with a single data set as
well. 

If crashing with 1 data set is the intended behaviour,
I think I would be beter to define a new exception type
to give the user a beter hint of what went wrong.

Francisco Borges 


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

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

Re: [PyX-devel] Re: [PyX-user] bar chart x-axis custom labels

[pieter c. <pi...@cl...>]

Andre,

>> 4. To cater for both continuous as well as discreet x-values (this again
>> is a little unclear but I can imagine that not all statistical sampling
>> would be agains continues values)
>
> Well, there are continous variables and those which aren't.
> Non-continuous variables are for example "Germany", "US", "Japan",
> "Russia" ... to be used on a bar graph. Continous variables are
> numbers. Sure you can use integer numbers as discrete variables, but
> that's almost always a misuse. Also times and dates are usually
> continuous variables, although, in some usecases days of months or
> such are used as discrete variables.
>
> A histogram should be build on continous variables. I don't think its
> worth a discussion ...
>

Point taken.


> Nice idea to look into the wikipedia. It exactly shows the whole
> problem of a histogram: To fully describe a histogram, you need three
> informations per data point: a position, a width and a hight. The only
> problem is, that typically you do not have all the three informations
> kept in a data file. Thats why I don't know how to implement such a
> style. That's all. So we're back on my original question: What data
> should we start with?

In general, the following data is available:
[[x1,y1],[x2,y2]......[xn,yn]]
Graph width/height

Would it be possible to express the step width as following:
step_width = axis_length / num_data_points

And do the x location of middle of each step:
g_x[n] = gmin_xaxis + (n * step_width)/2

The y value of each step:
g_y = gmin_yaxis + ((f(x) - fmin) / (fmax - fmin)) * gmax_yaxis

[my IQ might let me down here!]


What are your thoughts on this?

Pieter

Re: [PyX-devel] Re: [PyX-user] bar chart x-axis custom labels

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

Hi Pieter,

On 03.02.05, pieter claassen wrote:
> A few questions if I may (this might be answered earlier in the list, so
> tell me to stop if that is the case):

I think we've never distributed that kind of knowledge. Some things
are described (more or less) at various places, but let me just give
some answers to your questions right away ...

> 1. How does pyx make use of TeX? What is the integration and purpose of
> the integration?

PyX starts a (La)TeX instance as soon as it needs to typeset some
text. PyX can't typeset text without TeX, so the purpose of the TeX
integration is to be able to insert text into the output.

PyX typesets the requested text in a box, analyses the box extents and
writes the box content into TeX's dvifile on a separate page for each
box. Later on it can read the information from that page and insert
the appropriate PostScript code into the output.

> 2. What is the basic idea behind the library design? I can see from the
> documentation the basic workflow, but what about the underlying principles
> for the implementation?

Well, PyX is just a collection of usefull stuff:

  - a canvas to paint on
  - paths with various features (splitting, intersection, etc.)
  - decorators which assign stroke or fill operations (and other
    things) to paths
  - attributes for the stroke or fill operations (like colors etc.)
  - deformers to modify paths (like transformations)
  - graphs built on top of that features

Graphs themselfs are constructed out of various components:

  - graph.graph takes care about the geometric arragement
  - graph.data contains classes to define graph data (by reading from
    a file or calculating it from a function etc.)
  - graph.style contains graph styles (lines, symbols, etc.)
  - graph.key to create graph keys
  - axis for the conversion of data values to graph coordinates (graph
    coordinates are fixed to the interval 0..1)

The axis are build out of various components themself:

  - graph.axis.axis does the conversion and global bookkeeping
  - graph.axis.tick are ticks to be placed on axes
  - graph.axis.parter calculates ticks for a given axis range
  - graph.axis.texter creates the label text to be placed at the ticks
  - graph.axis.painter paints the whole axis

May I've missed the one or the other, but that's the basic technology.
The idea is to plug everything together to make it working ... ;-)

> As to labels and tics: This I think is a difficult subject because in many
> libraries it is not an easy subject and the implementor requires a
> significant amount of knowledge to do anything other than use defaults. To
> make it more user friendly, I have the following suggestions (and will
> help implement where I can)
> 1. To develop a number of use-cases and appropriate examples for manual
> overried that include:

We intent to use examples for that. Those are complete usecases and
they work as functional tests for us. That's why we try to keep
comprehensive examples out of the manual ...

> 1.1. Example of no labels on all types graphs

Several possibilities here: The most easiest variant would be to just
suppress the painting of the labels. Set the labelattrs of the painter
to None ... that's it. You could also create parters which place ticks
at the axis, but no labels.

> 1.2. Example of manual labels on all types of graphs

Set the parter to None and use manualticks.

> 1.3. ...

There will be answers to that too ... ;-)

> 2. Would it be possible to provide a manual override parameter to all axis
> that allows users to provide a list of values or [[value,label],..] that
> will then be converted to chart-coordinates and plotted at value location
> on the axis? This would provide ultimate flexibility.

manualticks does that. But you can also use the axispos methods to get
positions at the axis and do whatever you want:

    ...
    g.dolayout()
    x, y = g.axespos["x"].tickpos(100)
    g.text(x, y, "here we are")

Note that a specialized painter would be able to do such things as
well and by that you can plug-in your needs into the graph design.
I.e. the solution as shown above will almost always be total crap,
although it might look as the most easiest and simplest way to get
your needs done in the first. But its only the most simplest way if
you need it only a single time. As soon as you want to use this twice,
a painter will save you time ...

> I have been thinking about a first set of requirements for the histogram
> class and here is my stab at them.
> 
> REQUIRED
> 1. To plot steps like gnuplot.

This is absolutely trivial to implement, but my concerns are, that you
need to adjust the data to what's needed by the plotting system and
not vice versa ...

> 2. To plot multiple series on a graph.

Use several plot commands on a graph or use a list of data in a single
plot command.

> 3. To provide manual overrides on the x-axis.

manualticks will do ...

> 4. To cater for both continuous as well as discreet x-values (this again
> is a little unclear but I can imagine that not all statistical sampling
> would be agains continues values)

Well, there are continous variables and those which aren't.
Non-continuous variables are for example "Germany", "US", "Japan",
"Russia" ... to be used on a bar graph. Continous variables are
numbers. Sure you can use integer numbers as discrete variables, but
that's almost always a misuse. Also times and dates are usually
continuous variables, although, in some usecases days of months or
such are used as discrete variables.

A histogram should be build on continous variables. I don't think its
worth a discussion ...

BTW: you can use continous and bar-graph axes in the same graph. PyX
is able to handle an arbitrary number of axes for each graph
dimension.

> DESIRED
> 1. To provide the facility to swap axis (this I cannot justify, but can
> imagine that it would be valuable.

Definitely. A graph style should never take into account the axis
names and the ordering of the different axis dimensions. A graph style
does not know anything about the graph layout ... and then x and y
axes are exchangeable in the style without any additional efforts ...

> http://en.wikipedia.org/wiki/Histogram

Nice idea to look into the wikipedia. It exactly shows the whole
problem of a histogram: To fully describe a histogram, you need three
informations per data point: a position, a width and a hight. The only
problem is, that typically you do not have all the three informations
kept in a data file. Thats why I don't know how to implement such a
style. That's all. So we're back on my original question: What data
should we start with?


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-user] bar chart x-axis custom labels

[pieter c. <pi...@cl...>]

Andre,

I had a go at looking at your code, but without understanding the larger
implementation, I am lost. However, I am interested in this and will have
a go at it again later.

A few questions if I may (this might be answered earlier in the list, so
tell me to stop if that is the case):
1. How does pyx make use of TeX? What is the integration and purpose of
the integration?
2. What is the basic idea behind the library design? I can see from the
documentation the basic workflow, but what about the underlying principles
for the implementation?

As to labels and tics: This I think is a difficult subject because in many
libraries it is not an easy subject and the implementor requires a
significant amount of knowledge to do anything other than use defaults. To
make it more user friendly, I have the following suggestions (and will
help implement where I can)
1. To develop a number of use-cases and appropriate examples for manual
overried that include:
1.1. Example of no labels on all types graphs
1.2. Example of manual labels on all types of graphs
1.3. ...
2. Would it be possible to provide a manual override parameter to all axis
that allows users to provide a list of values or [[value,label],..] that
will then be converted to chart-coordinates and plotted at value location
on the axis? This would provide ultimate flexibility.

I have been thinking about a first set of requirements for the histogram
class and here is my stab at them.

REQUIRED
1. To plot steps like gnuplot.
2. To plot multiple series on a graph.
3. To provide manual overrides on the x-axis.
4. To cater for both continuous as well as discreet x-values (this again
is a little unclear but I can imagine that not all statistical sampling
would be agains continues values)

DESIRED
1. To provide the facility to swap axis (this I cannot justify, but can
imagine that it would be valuable.

http://en.wikipedia.org/wiki/Histogram

Pieter

> Hi Pieter,
>
> welcome on pyx-dev (which is kind of low traffic most of the time as
> pyx-user as well) ... ;-)
>
> On 02.02.05, pieter claassen wrote:
>> 1. Top plot this data so that it can be seen that there were 55 trips
>> that
>> took 95 minutes and 45 minutes that took 100 minutes.
>> 2. To show that the distribution of the results are mostly on the high
>> end.
>>
>> To recap the current problem:
>> When this large number of data points are plotted on a bar graph, the
>> x-axis labels overwrite each other.
>>
>> Current suggested solution:
>> ??
>
> Well, not really. As I said before, you should try to use a x-y-plot
> for that. A bar graph is just the wrong thing for that.
>
>> Any suggestions on how to proceed?
>
> You'll need a histogram style. There are basically two ways to get it.
> You could create a style from graph.style.linestyle, overwrite the
> drawpoint method and call the graph.style.linestyle's drawpoint
> several times for each point with appropriately modified
> sharedata.vposi data to get the step-like shape. The other possibility
> would be to write your own style from scratch. A simple, first working
> example could look like:
>
>     import random
>     from pyx import *
>
>     class histogram(graph.style._styleneedingpointpos):
>
>         needsdata = ["vpos", "vposmissing", "vposavailable"]
>
>         defaultlineattrs = []
>
>         def __init__(self, lineattrs=[]):
>             self.lineattrs = lineattrs
>
>         def selectstyle(self, privatedata, sharedata, graph, selectindex,
> selecttotal):
>             if self.lineattrs is not None:
>                 privatedata.lineattrs =
> attr.selectattrs(self.defaultlineattrs + self.lineattrs,
> selectindex, selecttotal)
>             else:
>                 privatedata.lineattrs = None
>
>         def initdrawpoints(self, privatedata, sharedata, graph):
>             privatedata.path = path.path()
>             privatedata.lastvpos = None
>
>         def drawpoint(self, privatedata, sharedata, graph):
>             if sharedata.vposavailable:
>                 if privatedata.lastvpos:
>                     midvxpos = 0.5 * (privatedata.lastvpos[0] +
> sharedata.vpos[0])
>                     privatedata.path.append(path.lineto_pt(*graph.vpos_pt(midvxpos,
> privatedata.lastvpos[1])))
>                     privatedata.path.append(path.lineto_pt(*graph.vpos_pt(midvxpos,
> 0)))
>                     privatedata.path.append(path.lineto_pt(*graph.vpos_pt(midvxpos,
> sharedata.vpos[1])))
>                     privatedata.path.append(path.lineto_pt(*graph.vpos_pt(*sharedata.vpos)))
>                 else:
>                     privatedata.path.append(path.moveto_pt(*graph.vpos_pt(*sharedata.vpos)))
>                 privatedata.lastvpos = sharedata.vpos[:]
>             else:
>                 privatedata.lastvpos = None
>
>         def donedrawpoints(self, privatedata, sharedata, graph):
>             if privatedata.lineattrs is not None and
> len(privatedata.path.path):
>                 graph.stroke(privatedata.path, privatedata.lineattrs)
>
>
>     g = graph.graphxy(width=8)
>     g.plot(graph.data.list([(5*i, random.random()) for i in range(1, 20)],
> x=1, y=2), [histogram()])
>     g.writeEPSfile("histogram")
>
>
> However, its just a starting point. We do not correctly adjust the
> vertical range. We do not know how to handle the edge points
> (currently particial boxes are plotted --- we could, of course, just
> plot steps (like gnuplot and others, but I'm not sure whether this is
> a good idea)). We do not cut the path at the graph border. We can't
> exchange x and y axis ... etc.
>
> Any comments how to proceed? What's needed out there? (I do not need
> histograms at all, otherwise I would have implemented such a style
> before already, but since we're now on the subject, we might get it
> done once and for all ...) Although its working well that way, its not
> that easy to make it a robust graph style. As usual with graph styles.
> Its easy to implement one, but to make it general perpose, some more
> work needs to be done ...
>
>
> André
>
> --
> by  _ _      _    Dr. André Wobst
>    / \ \    / )   wo...@us..., http://www.wobsta.de/
>   / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
>  (_/ \_)_/\_/           visit http://pyx.sourceforge.net/
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> PyX-devel mailing list
> PyX...@li...
> https://lists.sourceforge.net/lists/listinfo/pyx-devel
>

Re: [PyX-devel] Re: [PyX-user] bar chart x-axis custom labels

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

Hi again,

On 02.02.05, Andre Wobst wrote:
> Well, not really. As I said before, you should try to use a x-y-plot
> for that. A bar graph is just the wrong thing for that.

Just to avoid confusion: A bargraph is a x-y-plot as well, but is has
a special axis, which doesn't handle continuous variables. In that
sense its not a x-y-plot with continous variables at the axes ...


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-user] bar chart x-axis custom labels

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

Hi Pieter,

welcome on pyx-dev (which is kind of low traffic most of the time as
pyx-user as well) ... ;-)

On 02.02.05, pieter claassen wrote:
> 1. Top plot this data so that it can be seen that there were 55 trips that
> took 95 minutes and 45 minutes that took 100 minutes.
> 2. To show that the distribution of the results are mostly on the high end.
> 
> To recap the current problem:
> When this large number of data points are plotted on a bar graph, the
> x-axis labels overwrite each other.
> 
> Current suggested solution:
> ??

Well, not really. As I said before, you should try to use a x-y-plot
for that. A bar graph is just the wrong thing for that.

> Any suggestions on how to proceed?

You'll need a histogram style. There are basically two ways to get it.
You could create a style from graph.style.linestyle, overwrite the
drawpoint method and call the graph.style.linestyle's drawpoint
several times for each point with appropriately modified
sharedata.vposi data to get the step-like shape. The other possibility
would be to write your own style from scratch. A simple, first working
example could look like:

    import random
    from pyx import *

    class histogram(graph.style._styleneedingpointpos):

        needsdata = ["vpos", "vposmissing", "vposavailable"]

        defaultlineattrs = []

        def __init__(self, lineattrs=[]):
            self.lineattrs = lineattrs

        def selectstyle(self, privatedata, sharedata, graph, selectindex, selecttotal):
            if self.lineattrs is not None:
                privatedata.lineattrs = attr.selectattrs(self.defaultlineattrs + self.lineattrs, selectindex, selecttotal)
            else:
                privatedata.lineattrs = None

        def initdrawpoints(self, privatedata, sharedata, graph):
            privatedata.path = path.path()
            privatedata.lastvpos = None

        def drawpoint(self, privatedata, sharedata, graph):
            if sharedata.vposavailable:
                if privatedata.lastvpos:
                    midvxpos = 0.5 * (privatedata.lastvpos[0] + sharedata.vpos[0])
                    privatedata.path.append(path.lineto_pt(*graph.vpos_pt(midvxpos, privatedata.lastvpos[1])))
                    privatedata.path.append(path.lineto_pt(*graph.vpos_pt(midvxpos, 0)))
                    privatedata.path.append(path.lineto_pt(*graph.vpos_pt(midvxpos, sharedata.vpos[1])))
                    privatedata.path.append(path.lineto_pt(*graph.vpos_pt(*sharedata.vpos)))
                else:
                    privatedata.path.append(path.moveto_pt(*graph.vpos_pt(*sharedata.vpos)))
                privatedata.lastvpos = sharedata.vpos[:]
            else:
                privatedata.lastvpos = None

        def donedrawpoints(self, privatedata, sharedata, graph):
            if privatedata.lineattrs is not None and len(privatedata.path.path):
                graph.stroke(privatedata.path, privatedata.lineattrs)


    g = graph.graphxy(width=8)
    g.plot(graph.data.list([(5*i, random.random()) for i in range(1, 20)], x=1, y=2), [histogram()])
    g.writeEPSfile("histogram")


However, its just a starting point. We do not correctly adjust the
vertical range. We do not know how to handle the edge points
(currently particial boxes are plotted --- we could, of course, just
plot steps (like gnuplot and others, but I'm not sure whether this is
a good idea)). We do not cut the path at the graph border. We can't
exchange x and y axis ... etc.

Any comments how to proceed? What's needed out there? (I do not need
histograms at all, otherwise I would have implemented such a style
before already, but since we're now on the subject, we might get it
done once and for all ...) Although its working well that way, its not
that easy to make it a robust graph style. As usual with graph styles.
Its easy to implement one, but to make it general perpose, some more
work needs to be done ...


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] Re: [PyX-user] bar chart x-axis custom labels

[pieter c. <pi...@cl...>]

Andre, comments inline.

...
>
> So let us start with the data. What kind of data you have in the
> beginning? You kind of collected the histogram data before you start
> with PyX, don't you? We could start with that, but we don't need to.
> In principle it would be possible to calculate the histogram out of
> some scattered data points *within* the graph style. I'm just not
> sure whether this would be a good idea or not ...

my data is obtained by running a number of simultions (100 to 1000000) and
to record a time result of each simulation (0 to 200).
I then process the data by grouping values into descrete intervals
(between 5 and 10 seconds each). The result is thus a list of the
following format

[[interval[0],value[0]],[interval[1],value[1],.....[interval[n],value[n]]

e.g.
[[0,0],[5,0],[10,0].......[95,55],[100,45]]

here are some use cases
1. Top plot this data so that it can be seen that there were 55 trips that
took 95 minutes and 45 minutes that took 100 minutes.
2. To show that the distribution of the results are mostly on the high end.

To recap the current problem:
When this large number of data points are plotted on a bar graph, the
x-axis labels overwrite each other.

Current suggested solution:
??

Any suggestions on how to proceed?

Cheers,
Pieter

[PyX-devel] Re: [PyX-checkins] pyx/pyx path.py,1.187,1.188

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

On 31.01.05, André Wobst wrote:
> Update of /cvsroot/pyx/pyx/pyx
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv29972
> 
> Modified Files:
> 	path.py 
> Log Message:
> remove the XXX NOTE TODO and the (WRONG!) moveto from arct_pt

Das mit dem moveto kann sein, ist ja auch der XXX code...
Nur als Hinweis: test/functional/test_path.py läuft nicht mehr durch.
Bezüglich der bbox-Sachen solltest Du insbesondere test_bbox.eps
anschauen.

        Jörg

> Index: path.py
> ===================================================================
> RCS file: /cvsroot/pyx/pyx/pyx/path.py,v
> retrieving revision 1.187
> retrieving revision 1.188
> diff -C2 -d -r1.187 -r1.188
> *** path.py	31 Jan 2005 10:13:45 -0000	1.187
> --- path.py	31 Jan 2005 13:04:48 -0000	1.188
> ***************
> *** 678,687 ****
>           self.r_pt = r_pt
>   
> !     def _path(self, context):
> !         """returns the path consisting of arc and/or line which corresponds
> !         to arct
>   
> !         this is a helper routine for _bbox and _normalized, which both need
> !         this path. Note: we don't want to calculate the bbox from a bpath
>           """
>   
> --- 678,688 ----
>           self.r_pt = r_pt
>   
> !     def _pathitem(self, context):
> !         """return pathitem which corresponds to arct in the given context.
>   
> !         The return value is either a arc_pt, a arcn_pt or a line_pt instance.
> ! 
> !         This is a helper routine for _updatecontext, _bbox and _normalized,
> !         which will all deligate the work to the constructed pathitem.
>           """
>   
> ***************
> *** 708,712 ****
>               yt2_pt = self.y1_pt + dy2_pt*self.r_pt*cotalpha2/l2
>   
> !             # direction of center of arc 
>               rx_pt = self.x1_pt - 0.5*(xt1_pt+xt2_pt)
>               ry_pt = self.y1_pt - 0.5*(yt1_pt+yt2_pt)
> --- 709,713 ----
>               yt2_pt = self.y1_pt + dy2_pt*self.r_pt*cotalpha2/l2
>   
> !             # direction of center of arc
>               rx_pt = self.x1_pt - 0.5*(xt1_pt+xt2_pt)
>               ry_pt = self.y1_pt - 0.5*(yt1_pt+yt2_pt)
> ***************
> *** 717,724 ****
>                   phi = degrees(math.atan2(ry_pt, rx_pt))
>               else:
> !                 # XXX why is rx_pt/ry_pt and not ry_pt/rx_pt used??? 
>                   phi = degrees(math.atan(rx_pt/ry_pt))+180
>   
> !             # half angular width of arc 
>               deltaphi = 90*(1-alpha/pi)
>   
> --- 718,725 ----
>                   phi = degrees(math.atan2(ry_pt, rx_pt))
>               else:
> !                 # XXX why is rx_pt/ry_pt and not ry_pt/rx_pt used???
>                   phi = degrees(math.atan(rx_pt/ry_pt))+180
>   
> !             # half angular width of arc
>               deltaphi = 90*(1-alpha/pi)
>   
> ***************
> *** 727,753 ****
>               my_pt = self.y1_pt - ry_pt*self.r_pt/(lr*sin(alpha/2))
>   
> -             # now we are in the position to construct the path
> -             p = path(moveto_pt(context.x_pt, context.y_pt))
> - 
>               if phi<0:
> !                 p.append(arc_pt(mx_pt, my_pt, self.r_pt, phi-deltaphi, phi+deltaphi))
>               else:
> !                 p.append(arcn_pt(mx_pt, my_pt, self.r_pt, phi+deltaphi, phi-deltaphi))
> ! 
> !             return p
>   
>           else:
> !             # we need no arc, so just return a straight line from context to x1_pt, y1_pt
> !             return line_pt(context.x_pt, context.y_pt, self.x1_pt, self.y1_pt)
>   
>       def _updatecontext(self, context):
> !         self._path(context)[-1]._updatecontext(context)
>   
>       def _bbox(self, context):
> !         return self._path(context).bbox()
>   
>       def _normalized(self, context):
> !         # XXX TODO NOTE
> !         return self._path(context).normpath().normsubpaths[0].normsubpathitems
>   
>       def outputPS(self, file):
> --- 728,747 ----
>               my_pt = self.y1_pt - ry_pt*self.r_pt/(lr*sin(alpha/2))
>   
>               if phi<0:
> !                 return arc_pt(mx_pt, my_pt, self.r_pt, phi-deltaphi, phi+deltaphi)
>               else:
> !                 return arcn_pt(mx_pt, my_pt, self.r_pt, phi+deltaphi, phi-deltaphi)
>   
>           else:
> !             return lineto_pt(self.x1_pt, self.y1_pt)
>   
>       def _updatecontext(self, context):
> !         self._pathitem(context)._updatecontext(context)
>   
>       def _bbox(self, context):
> !         return self._pathitem(context).bbox()
>   
>       def _normalized(self, context):
> !         return self._pathitem(context)._normalized(context)
>   
>       def outputPS(self, file):
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> PyX-checkins mailing list
> PyX...@li...
> https://lists.sourceforge.net/lists/listinfo/pyx-checkins
> 

Re: [PyX-devel] Re: Bug in Windows installer

[Fernando P. <Fer...@co...>]

Joerg Lehmann wrote:

> Yes, that may be the reason. Still under Linux and other Unix-like
> systems, absolute paths are interpreted relative to the --root
> directory, and the same mechanism could actually be used under Windows,
> e.g., one could specify --root D:\ Anyway, choosing a default "root
> directory" is probably not possible, although C:\ would come very close.

Let me suggest that you guys have a look at IPython's installer 
(http://ipython.scipy.org).  I had to deal with many similar issues, and I 
also develop 'in the blind', since I did everything from a Linux box with only 
about one day of work on a borrowed windows laptop.  It's primitive under 
windows, but it works.  Feel free to grab any code from there you may want.

You will HAVE to read registry keys if you want to make something portable, 
since the various windows directories can be called different things under 
different windows versions.  I also used the win32 extensions from David 
Ascher so I could give windows users 'Start Menu' shortcuts for  ipython and 
the manuals, but if you give that up, you can run all the code with only the 
tools in the stdlib.

I hope this helps.

Cheers,

f

ps.  If at some point you have a chance, it might be nice to fix pyx's 
installer for unix, whose bdist_rpm target is broken.  It fails with:

running install_data
creating /usr/share/pyx
error: can't copy 'pyx/lfs/10pt.lfs': doesn't exist or not a regular file
error: Bad exit status from /var/tmp/rpm-tmp.27521 (%build)

These days I try to install all my python packages via yum so I can manage 
them more cleanly, and now the only two things left which fail are PyX and 
VTK.  It would be nice to bring that list down to just VTK (which is a 
monster, so I sort of gave up on it).  And thanks for such a great tool!

Re: [PyX-devel] Re: Bug in Windows installer

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

Hi,

On 05.01.05, Andre Wobst wrote:
> On 05.01.05, pieter claassen wrote:
> Sure, they should be in the same directory. And this sounds good. Why
> not install pyxrc in that directory as well ...

This was also my first thought.

[ snip ]

> PS: BTW, there is a reason why absolut paths doesn't make sense on
>     Windows. I just got an idea of it. There are different drive
>     letters ...

Yes, that may be the reason. Still under Linux and other Unix-like
systems, absolute paths are interpreted relative to the --root
directory, and the same mechanism could actually be used under Windows,
e.g., one could specify --root D:\ Anyway, choosing a default "root
directory" is probably not possible, although C:\ would come very close.

        Jörg

Re: [PyX-devel] Re: Bug in Windows installer

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

Hi Pieter,

On 05.01.05, pieter claassen wrote:
> I am not on the mailing list so you might have to forward this on.

It seems to got posted to the mailing list without further approval.
Might be due to the "in-reply-to" or something similar ...

> Both pyx.def and 10pt.lfs are located in c:\python24\share\pyx

Sure, they should be in the same directory. And this sounds good. Why
not install pyxrc in that directory as well ...

> I would keep things out of c:\windows because that is cruising for a
> bruising. Only Bill and friends are supposed to write there and anyhow,
> permissions might be a problem on some machines (local policy).

Well, it was more like a joke of mine ...

> There is a registery setting
> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir
> which specifies where program files are installed. That is probably a more
> reasonable place to installed stuff if not under the python24 dir.
> 
> Don't know the python installer well enough to know if it can check the
> install platform before doing its thing.

Oh, that's trivial. Its available via os.name. It should be "nt" for
all windows versions?! That's what the doc says.

> If there is a hook, then here is a link for registery query from within
> python.
> 
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/146305

Sure we could use the registry. But I would not like to do so. We
should try to keep the differences between the different plattforms
small. And the user should be able to just edit the systemwide pyxrc.
That's what it is for.

> I would suggest if some stuff is moved to c:\{program files}\python24 then
> everything must be moved there. That sounds like an installer change to
> me?

But that's somethink, the distutils should take care of itself.
Depending on where you install Python, PyX is installed relative to
that. And that's fine!

Enclosed you find a new version of setup.py. I'm not sure whether you
can patch files, so I send the full file. You may try whether it
properly installes the pyxrc into c:\python24\share\pyx on your box.
It should also set the correct full path in siteconfig.py. (I guess
what you did before basically disabled the systemwide pyxrc, since it
could not be found by PyX any longer.) Could you try that for me? I
would really appreciate your help!


André

PS: BTW, there is a reason why absolut paths doesn't make sense on
    Windows. I just got an idea of it. There are different drive
    letters ...

-- 
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: Bug in Windows installer

[pieter c. <pi...@pi...>]

Hello Andre,

I am not on the mailing list so you might have to forward this on.

Both pyx.def and 10pt.lfs are located in c:\python24\share\pyx

I would keep things out of c:\windows because that is cruising for a
bruising. Only Bill and friends are supposed to write there and anyhow,
permissions might be a problem on some machines (local policy).

There is a registery setting
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir
which specifies where program files are installed. That is probably a more
reasonable place to installed stuff if not under the python24 dir.

Don't know the python installer well enough to know if it can check the
install platform before doing its thing.

If there is a hook, then here is a link for registery query from within
python.

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/146305

I would suggest if some stuff is moved to c:\{program files}\python24 then
everything must be moved there. That sounds like an installer change to
me?

Cheers,
Pieter


> Hi,
>
> On 05.01.05, Joerg Lehmann wrote:
>> Probably, we have to check
>> for the platform in the setup.py file.
>
> It seems so. Yes.
>
>> But before, we have to find
>> a sensible place for the pyxrc file under Windows. Any ideas?
>
> c:\windows ... ;-)
>
> Well, I have no idea. I think the generic place would be somewhere in
> the registry. Not everything is a file, at least not under windows.
> ;-(
>
> To make a serious suggestion: We might place it under "share/pyx" as
> well. But I don't know, where those things get installed in the end.
> Pieter, can you locate "pyx.def" and things like "10pt.lfs" on your
> maschine. Just to get an understanding myself, what I'm suggesting ...
>
>
> 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: Bug in Windows installer

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

Hi,

On 05.01.05, Joerg Lehmann wrote:
> Probably, we have to check
> for the platform in the setup.py file.

It seems so. Yes.

> But before, we have to find
> a sensible place for the pyxrc file under Windows. Any ideas?

c:\windows ... ;-)

Well, I have no idea. I think the generic place would be somewhere in
the registry. Not everything is a file, at least not under windows.
;-(

To make a serious suggestion: We might place it under "share/pyx" as
well. But I don't know, where those things get installed in the end.
Pieter, can you locate "pyx.def" and things like "10pt.lfs" on your
maschine. Just to get an understanding myself, what I'm suggesting ...


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] Re: Bug in Windows installer

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

Hello Pieter,

On 29.12.04, pieter claassen wrote:
> I found a bug in the windows PYX installation this morning. If you prefer
> a post to the mailing list, then tell me.
> 
> setup.py line 56
> 
> "/etc" is supposed to be relative but seems to be absolute.
> 
> I changed it to "etc" and it solved the problem on a windows install, but
> not sure what th impact on Linux would be.

You're the second one to report this problem, so I'm CCing the pyx-devel
list.

Concerning the impact on Linux, the situation is as follows: The
directories in the data_files option are taken relative to the --root
directory which defaults to /usr under Linux. Hence, if we use etc
instead of /etc, the pyxrc file is installed under /usr/etc, which is
the incorrect place. Note that using an absolute path is even documented
in the Python distutils docs:

        http://www.python.org/doc/2.4/dist/node12.html

Thus, the windows error message is not really accurate ;-)

On the other hand, under Windows installing the pyxrc file under
whatever-directory\etc makes no sense at all, so we should look for a
better solution anyway. Unfortunately, the Python distutils package does
not really support the handling of configuration files very well, so we
have to invent something by ourselves. Probably, we have to check
for the platform in the setup.py file. But before, we have to find
a sensible place for the pyxrc file under Windows. Any ideas?

        Jörg

Re: [PyX-devel] Re: [PyX-checkins] pyx/faq Makefile,1.4,1.5

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

Hi,

On 17.12.04, Gert Ingold wrote:
> > I'm currious. I've never had any problems without this second run. Did
> > I constantly missed something?
> 
> well, if you look at the documentation, you will notice that on page 3
> there is a reference which needs a second pdflatex run. So, Michael is
> right in adding one more run. On the other hand: who really wants to
> read my documentation of the glifaq code?

I've just seen the checkin and somehow I thought it was all about
executing the glifaq.ins file, where I would wonder why it should be
run multiple times. Now I've got it that we're talking about the
creation of the style documentation here. Sure this style doc is very
valueable (I would even call the faq style the most beta-like part of
PyX ;-) -- lets see whether at some point this gets used in another
project ...) and sure it should be processed twice. Just my fault to
not carefully looking at it from the very beginning ...


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/faq Makefile,1.4,1.5

[Gert I. <Ger...@Ph...>]

Dear Andre,

> I'm currious. I've never had any problems without this second run. Did
> I constantly missed something?

well, if you look at the documentation, you will notice that on page 3
there is a reference which needs a second pdflatex run. So, Michael is
right in adding one more run. On the other hand: who really wants to
read my documentation of the glifaq code?

Best regards,
Gert

--=20
 Gert-Ludwig Ingold        email: Ger...@Ph...
 Institut f=FCr Physik       Phone: +49-821-598-3234
 Universit=E4t Augsburg      Fax  : +49-821-598-3222
 D-86135 Augsburg          WWW  : www.physik.uni-augsburg.de/theo1/ingold
 Germany                   PGP  : 86FF5A93, key available from homepage

Re: [PyX-devel] Re: [PyX-checkins] pyx/faq Makefile,1.4,1.5

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

On 17.12.04, Andre Wobst wrote:
> Hi Michael,
> 
> On 17.12.04, Michael Schindler wrote:
> > Update of /cvsroot/pyx/pyx/faq
> > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv26975
> > 
> > Modified Files:
> >     Makefile 
> > Log Message:
> > pdflatex glifaq twice
> > 
> > Index: Makefile
> > ===================================================================
> > RCS file: /cvsroot/pyx/pyx/faq/Makefile,v
> > retrieving revision 1.4
> > retrieving revision 1.5
> > diff -C2 -d -r1.4 -r1.5
> > *** Makefile        15 Dec 2004 06:53:56 -0000      1.4
> > --- Makefile        17 Dec 2004 15:13:20 -0000      1.5
> > ***************
> > *** 22,25 ****
> > --- 22,26 ----
> >   glifaq.pdf: glifaq.dtx
> >     pdflatex glifaq.dtx
> > +   pdflatex glifaq.dtx
> >   
> >   pyxversion.tex: ../pyx/version.py
> 
> I'm currious. I've never had any problems without this second run. Did
> I constantly missed something?
> 
actually, LaTeX said something about cross-references after the first
run. I always run LaTeX until it does not complain about this. -- But
I did not check if there are really differences in the output ;-)

Michael.

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

[PyX-devel] Re: [PyX-checkins] pyx/faq Makefile,1.4,1.5

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

Hi Michael,

On 17.12.04, Michael Schindler wrote:
> Update of /cvsroot/pyx/pyx/faq
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv26975
> 
> Modified Files:
> 	Makefile 
> Log Message:
> pdflatex glifaq twice
> 
> Index: Makefile
> ===================================================================
> RCS file: /cvsroot/pyx/pyx/faq/Makefile,v
> retrieving revision 1.4
> retrieving revision 1.5
> diff -C2 -d -r1.4 -r1.5
> *** Makefile	15 Dec 2004 06:53:56 -0000	1.4
> --- Makefile	17 Dec 2004 15:13:20 -0000	1.5
> ***************
> *** 22,25 ****
> --- 22,26 ----
>   glifaq.pdf: glifaq.dtx
>   	pdflatex glifaq.dtx
> + 	pdflatex glifaq.dtx
>   
>   pyxversion.tex: ../pyx/version.py

I'm currious. I've never had any problems without this second run. Did
I constantly missed something?


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] Announcement: PyX 0.7.1 released

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

Hi,

we are proud to announce the release of PyX 0.7.1. This release fixes
some bugs in the graph system, the canvas module and the kpsewhich
support. The tipa package is no longer required to build the FAQ. The
index files to sort the examples are now included in the distribution.
Two new examples complete this maintenance release. Find a detailed
list of changes below.

Enjoy!


André,
on behalf of all PyX developers

-----

0.7.1 (2004/12/15):
  - canvas module:
    - EPS header fixed (reported by Russell Lang, cf. bug #1065099)
  - Makefile fixes:
    - use CURDIR instead of PWD (reported by David M. Cooke, bug #1070285)
  - pykpathsea module:
    - support windows line endings (patch by Hans-Andreas Engel, cf. bug #1071160)
  - graph modules:
    - line attributes handling fixed (reported by Andrea Riciputi)
    - fix typos in predefined symbols (reported by Andrea Riciputi)
    - cut column name list at the max. number of columns (reported by Arnd Baecker)
  - examples:
    - add INDEX and README files to distribution
    - new errorbar and julia example
  - faq:
    - pdf snippets for tipa based phonetic transliterations

-- 
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] Arrows and symbol plot.

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

Hi,

On 14.12.04, Andrea Riciputi wrote:
> I've noticed that mixing symbol plots with arrowed lines results in not 
> a good looking output. Just try the little script that I include in 
> this email and you understand what I'm talking about. It could be worth 
> to improve the way in which arrows are placed at the end-point and how 
> the key symbol are plotted (omitting the arrow could be an option). Any 
> comment?

A quick (and dirty) solution could be a "shorten deformer" as
enclosed, which modifies the line path before decorating. However, in
case you want to always stroke two points connected by an arrow, it
really sounds like an appropriate task for a specialized graph style.


André

PS: To omit the stroking of some styles in the graph key, just create
    a new subclass and overwrite the key_pt method by an empty method.

-- 
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] Arrows and symbol plot.

[Andrea R. <ari...@pi...>]

Hi,
I've noticed that mixing symbol plots with arrowed lines results in not 
a good looking output. Just try the little script that I include in 
this email and you understand what I'm talking about. It could be worth 
to improve the way in which arrows are placed at the end-point and how 
the key symbol are plotted (omitting the arrow could be an option). Any 
comment?

Cheers,
   Andrea.

Re: [PyX-devel] PyX Fink package.

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

On 06.12.04, Andre Wobst wrote:

[ snip : André also wants to release PyX 0.7.1 ]

> Could we summarize a bit, what we should take care off before
> releasing? The tipa issue. Sure. 

If Gert wants to invest some time into this issue, fine. A positive
side-effect would be that I then could also build the FAQ on
standard Debian installations without having to worry about yet
another LaTeX package.

> Other things, which somebody has in
> the queue? (I do have some enhancements of the pdfwriter in a private
> development tree, which basically enhances the pdfwriter to what we
> had in our first experiments in pdf writing (creating text etc.). I
> could commit that, but it doesn't really matter. I didn't had time to
> continue the development lately. In order to keep the release close to
> what we had, I think its better to keep it off.)

This is definitely not something for this release. Nobody officially
knows about this functionality anyway, so why should we bother ;-)

        Jörg