On Wed, Aug 18, 2010 at 10:03 PM, Nils Wagner
wrote:
> I would like to plot an annulus.
>
With mpl_toolkits.axisartist, it is possible to make an axes of annulus.
But, the resulting axes is not fully compatible with the original
matplotlib axes. Most of the tick-related commands won't work and yo
Let me know if it does not work or you have any other problem.
Regards,
-JJ
On Tue, Aug 17, 2010 at 3:17 AM, Jeremy Conlin wrote:
> On Sun, Aug 15, 2010 at 10:49 PM, Jae-Joon Lee wrote:
>> On Fri, Aug 13, 2010 at 3:34 AM, Jeremy Conlin wrote:
>>> I have a problem with the sc
Those artist in offsetbox module (e.g., TextArea, VPacker,
AnchoredOffsetbox) are mostly a container object, i.e., actual drawing
is done by other artists. And changing the artist attributes of the
container object often does not work.
In your case (I guess you want to make the frame translucent?),
On Thu, Aug 12, 2010 at 2:08 PM, Russell E. Owen wrote:
> So...can I convince the automatic sizer to always show the full X (time)
> axis annotations and put all the variable sizing into the data area? Or
> do I have to manually set them somehow?
>
Another option you may try is to use axes_grid1
On Fri, Aug 13, 2010 at 3:34 AM, Jeremy Conlin wrote:
> I have a problem with the scaling of the numbers on a colorbar. The
> problem occurs when the numbers used as colorbar labels need to be
> scaled (i.e. by 1E3). The colorbar correctly puts the scaling value
> on the top of the colorbar, but
On Sun, Aug 8, 2010 at 10:38 PM, Simon Friedberger
wrote:
> a) I tried using the twinx() command like in that example but the axes
> seem to be scaled differently i.e. the ticks on the right don't have the
> same spacing as on the left.
>
twinx() creates an axes whose y-axis is independent from t
On Thu, Aug 5, 2010 at 4:48 PM, Jorge Scandaliaris
wrote:
> BTW, I think I've found another thing
> related to legend() and scatter plots: the 'numpoints' keyword argument to
> legend is not respected, as showed in the example pasted below,
>
> Jorge
In recent versions, there is a separate parame
On Wed, Aug 4, 2010 at 12:11 AM, Benjamin Root wrote:
> I have done some further research on this, and it appears to be a bug of
> some sort. Possibly the Locators are already made by the time the
> ax.set_xticks([]) is called and that function falls on deaf ears because the
> real xaxis is actua
On Wed, Aug 4, 2010 at 2:21 AM, R. Padraic Springuel
wrote:
> Things I've tried:
> Adding a size keyword argument to the set_xlabel and set_ylabel commands
> (both numerical and keywords). No errors are raised, but nothing is
> changed on the plot.
>
> Adding host.axis["left"].set_size(24) and
>
On Thu, Jul 29, 2010 at 1:17 AM, Jenna L. wrote:
> That looks fine to me too, but if you plot that as one subplot in a 5x5 array
> of subplots or more, then you can see the shift I am talking about in the
> eps file. Example:
I still don't see it (a capture of my eps output is attached).
Can you
Thanks for reporting.
This is now fixed in r8581(maint branch) and r8582(trunk).
Meanwhile, you may define your own subplot2grid function and use it instead.
from matplotlib.gridspec import GridSpec
from matplotlib.pyplot import gcf, draw_if_interactive, delaxes
def mysubplot2grid(shape, loc, row
On Sun, Jul 25, 2010 at 3:55 PM, Satish Raghunath wrote:
> " AttributeError: 'module' object has no attribute 'use' "
It means that the "module" object (matplotlib) has no attribute named "use".
This kind of error is often encountered when wrong module is imported
as matplotlib.
Try
import ma
I tried a simple array (see the code below) but cannot reproduce the
problem you reported.
import matplotlib.pyplot as plt
import numpy as np
arr = np.zeros((11, 11), dtype="d")
arr[3,3]=1
im = plt.imshow(arr, interpolation="nearest", origin="lower")
cont = plt.contour(arr, levels=[0.5])
plt.save
http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/branches/v1_0_maint/lib/matplotlib/text.py?r1=8512&r2=8541&pathrev=8541
Regards,
-JJ
On Wed, Jul 14, 2010 at 1:22 AM, shuwj wrote:
> Hi JJ,
> Thanks for your reply. I can't access the svn for some network
> reason. Will you please sen
I presume that you're using matploltib v1.0?
It seems that the bug was recently introduced as the baseline of the
multiline text has been recently changed.
This should be fixed this in r8564, and r8565.
Unfortunately, I don't see any easy workaround other than changing the
vertical alignment of mu
It seems that there are at least two issues related with the text clipping.
The first issue is that the Text.draw method does not properly set
clip path. I think I fixed this in r8541 and r8542.
The second issue is that the agg backend does not seem to support a
clip path yet for the text.
Also,
The axes_grid toolkit in the matplotlib 1.0 have some major changes.
1. Refactoring
2. introduced a concept of "axis_direction"
3. FloatingAxes
1. Refactoring
---
The axes_grid toolkit is now separated into two different modules,
*axes_grid1* and *axisartist*. The original ax
On Wed, Jun 30, 2010 at 10:39 AM, Jeremy Conlin wrote:
> Essentially my question is: how can I get a nice color distribution
> while at the same time avoid the extreme scaling issues associated
> with some data being zero (while all the other data is ~16)?
It seems that plot_surface method does h
contour creates list of LineCollection objects (per each level I
suppose) which is stored in "collections" attribute. For example,
cntr = contour(A, levels)
then
cntr.collections[i] is a LineCollection objects that is associated
with levels[i].
And you can change colors of each line in the Line
>
> The following gets it done, however:
>
> cb.ax.artists.remove(cb.outline)
>
or
cb.outline.remove()
-JJ
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to
quot;)
Regards,
-JJ
On Wed, Jun 16, 2010 at 1:40 PM, Jim Vickroy wrote:
> Jae-Joon Lee wrote:
>>
>> As you can see from the error, the dimension of your input is wrong
>> (it needs to be transposed).
>> Furthermore, matplotlib expects the rgb va
As you can see from the error, the dimension of your input is wrong
(it needs to be transposed).
Furthermore, matplotlib expects the rgb values in 0-1.
replace
colormap = matplotlib.colors.ListedColormap(palette,'custom-orange')
with
colormap = matplotlib.colors.ListedColormap(palette.T/255.,
On Thu, Jun 10, 2010 at 1:55 PM, mdekauwe wrote:
> fig = plt.figure(figsize=(8, 6))
This.
Also play with subplots_adjust.
-JJ
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE
On Thu, Jun 10, 2010 at 12:47 PM, Benjamin Root wrote:
> P.S. - I have found a 'bug' of sorts with using 'box-forced' for Basemap and
> AxesGrid. For the displayed plot, if one were to zoom in on one of the
> plots, the other plots will zoom in as well (which I think is neat), but
> they won't up
On Thu, Jun 10, 2010 at 9:28 AM, mdekauwe wrote:
> so by the sounds of it an outdated version? But your example will work on a
> newer version?
I think bbox_inches option is not supported with your version of matplotlib.
You may upgrade to newer version, or you have to manually adjust the
figure
Can you describe why using the "extent" keyword does not serve your purpose?
The svn version of matplotlib support BboxImage which might be better
(depending on your use case).
-JJ
On Thu, Jun 10, 2010 at 1:21 AM, Eamon Caddigan
wrote:
> Hi everybody,
>
> I'd like to draw thumbnails of images
What version of matplotlib are you using?
With 0.99.1.1 (and likely later) and also with the svn version, using
the bbox_inches="tight" actually produces an output with too small
margin.
With the svn version, following code should generate an output with an
adequate margin.
Otherwise, you cannot r
I think this is a known bug (unfortunately, the bug fix does not seem
to be reflected in the maintenance version), but without a full
traceback, I'm not 100% sure.
You may use the svn version which have fixed this bug, or you may try
the workaround described in the link below (check the
clabel_mon
On Sat, Jun 5, 2010 at 1:41 PM, Benjamin Root wrote:
> To encourage the use of axes_grid1, shouldn't the examples on the website
> get updated to reflect this? Would the examples still work with a simple
> search-and-replace?
>
>
The examples in the svn are already updated and they are reflected
17 PM, Benjamin Root wrote:
>
>
> On Thu, Jun 3, 2010 at 12:22 PM, Jae-Joon Lee wrote:
>>
>> On Thu, Jun 3, 2010 at 12:52 PM, Benjamin Root wrote:
>> > Well, the link is still not back, so I will probe you a bit further.
>> > You
>> > say that axes_g
By default, when the xy coordinate of the annotate is given in the
data coordinate, it draws the arrow only if the xy point is inside the
axes bbox. And, when the xy point is at the boundary of the axes bbox,
the inside-test results seems to depend on the backend. So, some
backends draws the arrow
On Thu, Jun 3, 2010 at 4:00 PM, Jim Vickroy wrote:
> How do I do this? Attempts to specify vimin and vmax appear to be ignored.
>
Hmm,
vmin and vmax should work.
cax= ax.imshow(data, interpolation='bilinear', vmin=-1, vmax=1)
If these are still ignored, what the following line prints?
pri
On Thu, Jun 3, 2010 at 12:52 PM, Benjamin Root wrote:
> Well, the link is still not back, so I will probe you a bit further. You
> say that axes_grid is provided for backward compatibility, does that mean
> that I should be using axes_grid1 for new code? I have noticed differences
> in behavior
On Wed, Jun 2, 2010 at 2:46 PM, Denis Laxalde wrote:
> That would indeed be a better approach. Can somebody points me to the
> particular methods/attributes to look at ?
>
As far as I can see, there is no public methods/attributes.
Can you file a bug so that Reinier (or others) can pick this up l
The currently implemented bounding box algorithm is very simple and it
basically only accounts the title, axis label and ticklabels etc. I
thought about implementing a general algorithm that accounts all the
visible artist, but I found it very difficult (at least for me) given
the support of the sp
On Wed, Jun 2, 2010 at 10:42 AM, Denis Laxalde wrote:
> This is set in axis3d module (class Axis), by _AXINFO.
> So far, I haven't found a way to modify colors/transparency but to edit
> the latter file. Is this hard-coded or is there a way to modify this a
> posteriori ?
>
> Cheers,
>
> Denis
On Tue, Jun 1, 2010 at 2:22 PM, rugspin wrote:
> That's doing it, thought there might be an internal way within matplotlib,
> but I could figure one.
If you need more hard-core way of doing this,
a = np.arange(16384).reshape(128, 128)
from matplotlib.colors import Normalize
import matplotlib.cm
this is supposed to be explained in
http://matplotlib.sourceforge.net/trunk-docs/users/gridspec.html
But the trunk documentation is failed to build at this moment.
In short, in the svn version of matplotlib, axes_grid is divided into
two separate modules, axes_grid1 and axisartist (axes_grid is
t;box", or "datalim" at
>> set_adjustable...
>> I'm using Matplotlib version 0.98.5.3, do I need to update?
>>
>> On Thu, May 27, 2010 at 2:59 PM, Jae-Joon Lee
>> wrote:
>>>
>>> ax1 = subplot(121)
>>> ax2 = subplot(122, share
You may use StringIO.
from scipy import *
from pylab import *
from PIL import Image
import cStringIO
a = arange(16384).reshape(128,128)
f = cStringIO.StringIO()
imsave(f, a, cmap=cm.summer,vmin=0,vmax=16383, format="png") # you'd
better set the format explicitly.
f.reset()
b = Image.open(f)
f.
On Tue, Jun 1, 2010 at 3:58 AM, L1011 wrote:
>
> Hello everyone!
>
> Here's my first (bout not last) post:
>
> I'm trying to customize one of my plot and I wondered if there was easy way
> to:
> -set the font size of the legend
> -set the number of markers displayed in the legend. Indeed, I got by
ax1 = subplot(121)
ax2 = subplot(122, sharex=ax1, sharey=ax1)
ax1.set_adjustable("box-forced")
ax2.set_adjustable("box-forced")
arr1 = np.arange(100).reshape((10, 10))
ax1.imshow(arr1)
arr2 = np.arange(100, 0, -1).reshape((10, 10))
ax2.imshow(arr2)
Note the use of set_adjustable("box-forced").
The bbox needs to be in a proper coordinate.
from matplotlib.transforms import TransformedBbox
bb = TransformedBbox(rect[0].get_bbox(), ax.transData)
Also, do not use clip_on when clip_box is used. clip_on override
clip_box with ax.bbox.
text0 = ax.text(0,11,'JobName', clip_box=bb)
A complete c
On Mon, May 24, 2010 at 10:04 AM, Fredrik Pihl wrote:
> some googling gives this thread:
> http://www.mail-archive.com/matplotlib-users@lists.sourceforge.net/msg16191.html
>
> but that doesn't solve the problem, just makes it different...
Different, but much easier to solve.
Unfortunately, Matplo
There is no clear api to manage this.
Try something like
ax = gca()
for t in ax.xaxis.get_major_ticks():
t.tick1On = False
t.tick2On = False
-JJ
On Wed, May 26, 2010 at 6:30 AM, John Reid wrote:
> Hi,
>
> This is probably easy to do but I didn't work it out from the
> documentation so
You need to define your own transform. And the best way is to read
through the transforms.py. Here is a modified version of your example
that uses a custom transform.
However, often you may need to use a custom locator also for this kind
of transform.
HTH,
-JJ
from matplotlib.transforms import
set_array method only update the underlying array, and no more.
The problem is that, the first imshow results in clim=(0,0) and
set_array does not change this.
You may manually update the clim of the image, or you may explicitly
call autoscale() after set_array.
Regards,
-JJ
On Fri, May 21, 2
On Wed, May 19, 2010 at 5:47 PM, Solomon M Negusse
wrote:
> Hello,
> I came across problem of label rotation with autofmt_xdate() in subplothost
> too. Is there a new version with the bug fixed or a workaround to doing the
> label rotation in subplothost?
>
While this is fixed in the svn, there
On Mon, May 10, 2010 at 12:19 PM, Nico Schlömer
wrote:
> When tick labels are explicitly supplied, that may not actually
> reflect in the return result of get_ticks. Specifically, I set the
> tick labels in a color bar, but get_ticklabels() returns a list of
> empty text objects Text(0,0,'').
> Fo
On Thu, May 20, 2010 at 3:17 PM, Jae-Joon Lee wrote:
> Again, note that not all ticks that are returned by get_xticks()
> methods may be actually drawn.
>
I mean, even if their tick1On (and others) is T
Like the gridlines, these are determined during the drawing time.
Each tick instances have
tick1On
tick2On
label1On
label2On
attributes that controls whether to draw tick (or ticklabel) or not.
Again, note that not all ticks that are returned by get_xticks()
methods may be actually drawn.
-JJ
On Thu, May 13, 2010 at 11:25 PM, Uri Laserson wrote:
> I noticed that the example for the radar chart has only a single scale. Is
> there a way to generate a radar plot where each axis has its own scale?
Can you show us some example plots? I'm not clear what you want.
Regards,
-JJ
--
It turns out that when axes_grid toolkit is used and there are some
ticks does not have associated ticklabels (i.e., minor ticks), it
tries to call the "get_texts_widths_heights_descents" method with
empty string.
The following patch prevent this.
--- a/lib/mpl_toolkits/axisartist/axis_artist.py
+
http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.plot
use *markevery* keyword.
http://matplotlib.sourceforge.net/api/artist_api.html#matplotlib.lines.Line2D.set_markevery
If you want more control, you can always draws the lines (without
markers) first and overplot markers
I cannot reproduce this error.
I'm using r8330 on Linux.
I guess the error does not occur when you use a normal subplot?
Just in case, replace axes_grid with axes_grid1 and see if it makes
any difference, i.e.,
from mpl_toolkits.axes_grid1.parasite_axes import SubplotHost
Regards,
-JJ
On Thu
The functionality of the gridspec is now merged into the matplotlib.
The updated documentation can be found in
http://matplotlib.sourceforge.net/trunk-docs/users/gridspec.html
Regards,
-JJ
On Tue, May 11, 2010 at 11:57 AM, Jae-Joon Lee wrote:
> Hi,
>
> gridspec is a module that i
On Sun, May 16, 2010 at 3:19 PM, Philipp K. Janert
wrote:
> Is this the best way to do this, or is there another way
> (or one that does not require an explicit draw()?). Also,
Any change in your figure is realized when you "draw()" the figure. So
there is no way that does not require an explicit
This can be done relatively easily with the current svn version of
matplotlib (r8319).
Below is the modified version of your code.
See
http://matplotlib.sourceforge.net/trunk-docs/users/annotations_guide.html#using-complex-coordinate-with-annotation
for how the annotation works.
While this is c
On Wed, May 12, 2010 at 5:58 AM, Yannick Copin
wrote:
> gs = gridspec.GridSpec(3, 3)
> ax1 = gs[0, :]
>
I'm inclined to leave the GridSpec as it is and I prefer to have a
separate class for this (if we go for it). My inclination is to modify
subplot2grid to return such an instance. e.g.,
grid =
On Tue, May 11, 2010 at 1:38 PM, John Hunter wrote:
> This looks sufficiently general and useful that we may simply want it
> to live in the main tree (not as a toolkit) and have subplot2grd
> helper functionality available directly from pyplot.
>
Okay.
I'll merge this into the main tree and comm
On Tue, May 11, 2010 at 12:10 PM, Ryan May wrote:
> 1) How does this relate to the functionality present in your axes_grid
> toolkit?
axes_grid toolkit is more flexible and is mainly meant to work with
axes with images. gridspec is more for normal axes.
As a matter of fact, the multiple axes cr
Hi,
gridspec is a module that implements matplotlib’s Subplot slightly
differently. Current matplotlib’s Subplot only allows a Subplot to
occupy a single cell of the n x m grid. gridspec enables a Subplot to
occupy multiple cells.
http://leejjoon.github.com/mpl_toolkits-gridspec/
The code is
On Thu, May 6, 2010 at 10:18 AM, Antony Lee wrote:
> asarray (and there's no copy) works too, so my question now is rather, why
> does imshow cast (I suppose that's what it does) 32bit arrays but not 16bit
> ones?
> Thanks for your help.
> Antony
It turns out that this is not a 16bit-32bit issue.
On Tue, May 4, 2010 at 6:27 PM, Nico Schlömer wrote:
> That's really independent of whether the grid is on or off.
>
> Is there any explanation for it that does not have to do with Harry
> Potter or the Jedi? ;)
>
positions of gridlines (and ticks, ticklabels, etc) are updated during
the drawing
Fixed in r8295.
Axes.annotate was not setting the _remove_method attribute.
Regards,
-JJ
On Tue, May 4, 2010 at 3:15 PM, Ryan May wrote:
> On Tue, May 4, 2010 at 2:09 PM, KrishnaPribadi
> wrote:
>> I'm trying to remove or delete an annotate arrow but I'm unsuccessful. Can
>> some please help?
On Wed, Apr 28, 2010 at 3:48 AM, David Epstein wrote:
> Here is the problem: each row is read once and those that matche
> the "if" statement are plotted once--but somehow generate TWO LABELS in
> the legend. How is that possible?! I've attached a code snippet below. I
> apologize for any sloppy c
On Thu, Apr 29, 2010 at 12:40 PM, acoffeemug
wrote:
> Does anyone know a good fix for this? Preferably one which doesn't involve
> manual resizing?
http://matplotlib.sourceforge.net/faq/howto_faq.html#automatically-make-room-for-tick-labels
While example in the link try to make a room for tickla
You may do this without creating an extra axes (ax0).
Try something like
ax4.plot([0.5, 0.5], [0, 1], color='lightgreen', lw=5,
transform=gcf().transFigure, clip_on=False)
Regards,
-JJ
On Fri, Apr 30, 2010 at 3:56 AM, Matthias Michler
wrote:
> On Wednesday 28 April 2010 15:07:21 Maxi
>
> I did not try vmin and vmax, because
> On 04/26/2010 02:31 PM, Jae-Joon Lee wrote:
>> Did you try to change vmin, vmax?
>>
>> http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.imshow
>>
>> If this is not what you want, please describe
Looking at the code, the "transparent" option set alphas of paches to
0, which I think is simply ignored in ps backend (which does not
support alpha). I think it is better if the visibility of patches is
set to False when the "transparent" option is set.
Setting patch's (face) color to "none" work
Did you try to change vmin, vmax?
http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.imshow
If this is not what you want, please describe more explicitly why the
colorbar is wrong.
Regards,
-JJ
On Mon, Apr 26, 2010 at 11:37 AM, Nikolaus Rath wrote:
> The problem with ims
On Fri, Apr 23, 2010 at 11:07 AM, Thomas Robitaille
wrote:
> Hi,
>
> I'm having issues with translucent patches. The following code
>
> import matplotlib
> matplotlib.use('Agg')
> import matplotlib.pyplot as mpl
> from matplotlib.patches import Circle
>
> fig = mpl.figure()
> ax = fig.add_subplot(
There seems no obvious way to change the padding.
You may use *set_rgrids* method which takes rpad parameter but you
need to specify the tick locations also.
Here is a simple function taken from set_rgrids method, that only
change the padding.
def update_rpads(ax, rpad):
angle = ax._r_label1_
I'm not sure if the default formatter needs to be changed.
However, you may try
import matplotlib.ticker as ticker
formatter=ticker.LogFormatterMathtext()
colorbar(format=formatter)
which will render colorbar ticklabels with mathtext mode.
Regards,
-JJ
On Fri, Apr 16, 2010 at 3:56 AM, Yves Re
On Sun, Apr 11, 2010 at 12:40 PM, Peter Butterworth wrote:
> sorry if this has been covered before, but I must say I've found the
> following quite confusing :
> color="cyan" is not in fact equivalent to color='c'
>
>
> in colors.py :
>
> Commands which take color arguments can use several format
On Sat, Apr 10, 2010 at 10:36 AM, arsbbr wrote:
> but it doesn't
> work.
>
Can you provide more details of what you tried and "how" it does not
work. For example, an exception is raised? or code runs without any
error but the result is not correct?
With my simple test, all things seem fine. I di
>
> Is it fairly easy to put something like this together using all the
> offsetbox tools and fancy arrows?
I tried to cook up something similar to what you described. See the
attached file.
Well, I would not say it is fairly easy, but not that difficult either I hope.
The demo requires svn r8227
See these examples. bbox works in a same way for the text and the annotation.
http://matplotlib.sourceforge.net/examples/pylab_examples/fancytextbox_demo.html
http://matplotlib.sourceforge.net/examples/pylab_examples/annotation_demo2.html
And, the annotation guide my help.
http://matplotlib.sou
I tried to take a look but, pstopdf in my linux box works okay (it
converted test_tex_r8216.eps fine also) and I'm afraid that I may not
be able to track this down.
Just in case, can you check if using a different distiller makes any
difference? I believe you're using a ghostscript (or none where
This is something that needs to be fixed in the next release.
Meanwhile, try something like,
cax = grid.cbar_axes[0]
cax.axis["right"].toggle(ticks=True, ticklabels=True, label=True)
cax.set_ylabel("Test")
Regards,
-JJ
On Tue, Apr 6, 2010 at 3:26 PM, Angus McMorland wrote:
> Hi all,
> I'm try
On Sun, Apr 4, 2010 at 2:56 AM, Levi Kilcher wrote:
> And what the heck are the line objects in the legend? Are there
> separate marker objects that I am missing?
>
Yes.
l = legend()
l.get_lines()[0]._legmarker.set_ms(5)
The line objects in the legend handles have a _legmarker attribute
which
On Fri, Apr 2, 2010 at 11:20 AM, Michael Droettboom wrote:
> It seems the relevant change is in r8102: "fix some issues in the bbox
> after the postscript distiller is run". This change removed a commented
> out call to ps2eps. I'm a bit out of my depth here as to why that
> change was made, and
On Mon, Apr 5, 2010 at 10:05 AM, Michael Droettboom wrote:
>> matplotlib.use('Agg')
>> import matplotlib.pyplot as mpl
>> from matplotlib.transforms import Affine2D
>> import numpy as np
>>
>> image = np.random.random((100,100))
>>
>> fig = mpl.figure()
>> ax = fig.add_subplot(1,1,1)
>> ax.pcolor(
On Sun, Apr 4, 2010 at 11:55 AM, Thomas Robitaille
wrote:
> It looks as though the set_linewidth and set_linestyle commands are silently
> ignored. Is this normal? I have submitted a bug report here:
linewidth and linestyle are (or looks) ignored because ticklines are
actually "markers".
To chan
I just had a quick look, but while extra "restore" could be a problem,
the erroneous one may not be the one at line 1073, but the one at line
1066.
I believe that the "restore" at 1073 is written by "pstoeps" function
in backend_ps.py, and this function did write a matching "save" at
line 11.
Reg
If you're not afraid of contaminating your code with axes_grid toolkit,
instead
cax = fig.add_axes([0.9, 0.1, 0.1, 0.8]) # setup colorbar axes.
try
from mpl_toolkits.axes_grid import make_axes_locatable
import matplotlib.axes as maxes
divider = make_axes_locatable(ax)
cax = divider.new_horizo
On Tue, Mar 30, 2010 at 11:12 AM, Julien wrote:
> This script should give you a srange historamme, with bins that are half
> the size they shoud be.
>
I'm sorry but it is not clear what is wrong. The histogram looks just fine
to me. Maybe you wanted to do
plt.hist(sorted(liste_histo),bins=rang
On Tue, Mar 30, 2010 at 2:56 PM, Eric Firing wrote:
> Is even that worth the potential extra complexity, both in the code and in
> the documentation? What is the real benefit?
>
I think there are some benefit of moving artists to another axes. Also
this will help enabling moving an axes to anoth
ance, would it not be possible to have a
> method that allows one to retrieve an Axes-independent LineCollection from an
> Axes instance? (for example a get_collection method) This would then allow
> one to 'recycle' existing collections.
>
> Cheers,
>
> Thomas
>
As far as I can say, moving around artists from one axes to the other
is NOT recommended. And I encourage you to create separate artists for
each axes rather than try to reuse the existing ones.
For your particular example,
fig = mpl.figure()
ax2 = fig.add_subplot(1,1,1)
for c in ax1.collections:
27;s a version that goes to the list too :-)
>
> On Fri, Mar 26, 2010 at 9:10 AM, Jae-Joon Lee wrote:
>> With the current svn, I cannot reproduce the problem, i.e., bars with
>> 0 height are correctly displayed. The x-range is incorrectly set, but
>> it is not clear if this
With the current svn, I cannot reproduce the problem, i.e., bars with
0 height are correctly displayed. The x-range is incorrectly set, but
it is not clear if this is what you meant.
Can you post a screenshot of your figure? Also, version of your
matplotlib will be helpful.
Regards,
-JJ
On We
Try something like
minorticks_on()
grid(True, color="k", ls="solid")
grid(True, which="minor", color="r")
-JJ
On Wed, Mar 24, 2010 at 7:33 AM, yogesh karpate wrote:
> Kindly find the image attached with this mail. I want to make the graph
> with grid lines(shown in background) as plotted in a
print >>sys.stderr, "Overlapping, offsetting a little
> bit"
> y1 = y1 + 0.1
> foo = theta
>
> annotate(l1,
> (xc, yc), xycoords="data",
> xytext=(x1, y1), textcoords="d
This should be doable using the annotation. Here is a simple cook-up I
just did. it uses a naive algorithm to place the labels, but I guess
it gives you an idea how things work.
a screenshot is attached.
Regards,
-JJ
from pylab import *
# make a square figure and axes
figure(1, figsize=(6,6))
The example assumes that the file is a dump of uin16 512x512 array.
So, no doubt that it won't work with a png file.
See
http://matplotlib.sourceforge.net/users/image_tutorial.html
-JJ
On Tue, Mar 23, 2010 at 9:41 AM, yogesh karpate wrote:
> The 1st code snippet of image_demo2.py is as follow
You need to define your own path (or you may combine a wedge and rectangles).
This may be helpful.
http://matplotlib.sourceforge.net/users/path_tutorial.html
Regards,
-JJ
On Sat, Mar 20, 2010 at 2:33 PM, Gary Jaffe wrote:
> Hi all --
>
> I'm new to Matplotlib, and it looks like a great proje
In the current implementation, sharing the axis does not mean sharing its scale.
This is not a subplots-specific issue, but applies to all kind of axes sharing.
So you need to change the scale of all the axes even though they have
shared axis.
What seems to be a better approach to me is to initial
On Tue, Mar 16, 2010 at 12:10 PM, PaterMaximus
wrote:
> Another way would be to use a font with a dark edge and light interior (or
> vice
> versa) but I know of know such font for matplotlib.
>
FYI, the svn version of matplotlib supports this.
http://matplotlib.sourceforge.net/trunk-docs/exampl
On Tue, Mar 16, 2010 at 3:30 AM, David wrote:
> This did not yield any results. With the above code, xlab.set_position((0.2,
> 0.1)), I change the position of the xlabel.
> But the problem is that my graph is cut before the xlabel has a chance to
> appear (see dea.png). Basically the graph ends ri
201 - 300 of 847 matches
Mail list logo
