I have been doing some testing with pcolor() and pcolormesh() with regards
to rasterization. I can not see a displacement when choosing between
different file types or with setting rasterized to be True or False. What I
have noticed is a half grid-space displacement between pcolor() and
pcolormes
Markus,
Looking again at your image, I realized that you are probably using real
data, not simulated data, therefore you can't easily use a higher grid
resolution.
So, I created a test script to examine this. I have found that there is
definitely a difference between filetypes. In my test scrip
Hello,
Attached is a test script to produce low and high resolution (data-wise)
images in multiple formats. You can change the dpi in the script, however,
I have not noticed any significant difference. It also appears that the
data resolution doesn't impact the size of the artifact as much as I
behavior, though. Maybe there could be a keyword option in
.readshapefile() to have only the data for the stated domain loaded? That
might solve the issue.
Thanks,
Ben Root
On Fri, May 21, 2010 at 4:08 PM, Benjamin Root wrote:
> Hello,
>
> I have been tracking down an annoying (but easi
Markus,
That is good to know that it has been fixed. As for the difference in
pcolor and pcolormesh, I think it has to do with the fact that pcolormesh is
composed of many lines while pcolor is composed of many polygons. It is
probably more efficient to rasterize polygons than lines.
Ben Root
On Tue, Jun 1, 2010 at 9:39 AM, Ryan May wrote:
> On Mon, May 31, 2010 at 11:28 AM, Benjamin Root wrote:
> > Markus,
> >
> > That is good to know that it has been fixed. As for the difference in
> > pcolor and pcolormesh, I think it has to do with the fact that pcol
hem. And I'm not sure this is
> intended behavior or not and I hope other developers step in.
>
> In the meantime, use a member method explicitly.
>
> p2 = pcolormesh(arr)
> p2.set_rasterized(True)
>
> Regards,
>
> -JJ
>
>
> On Tue, Jun 1, 2010 at 12:05 PM
ehaviors users
would encounter. FWIW, I was using v0.99.2 from the Fedora repos.
Ben Root
On Fri, May 21, 2010 at 4:57 PM, Benjamin Root wrote:
> I did some more digging and I think I have a hypothesis for what is
> happening.
>
> There is only one main difference between a call to .dr
.
Ben Root
On Tue, Jun 1, 2010 at 11:05 AM, Benjamin Root wrote:
>
>
> On Tue, Jun 1, 2010 at 9:39 AM, Ryan May wrote:
>
>> On Mon, May 31, 2010 at 11:28 AM, Benjamin Root wrote:
>> > Markus,
>> >
>> > That is good to know that it has been fix
On a related note, I have noticed an incompatibility between AxesGrid and
Basemap. It appears that Basemap will explicitly set adjustable='box' when
it calls ax.set_aspect(), but AxesGrid will error out, saying that it has to
be 'datalim'. What are the implications of using 'box-forced' instead o
and adjustable="box" at the same
> time, you cannot use this with any axes that shares its axis with
> others (including the axes created by the AxesGrid).
>
> You need to somehow avoid the set_aspect call with adjustable"box"
> (you can set box-forced in stead).
&
I just took a look at bar() and errorbar(). bar() has linewidth and uses it
properly (I believe), except in the case where one specifies yerr/xerr (it
doesn't pass on kwargs nor does it apply the linewidth parameter).
Then looking at errorbar(), there is a kwarg called 'elinewidth' which
supercee
1, 2010 at 1:07 PM, Benjamin Root wrote:
> Correction -- the problem with pcolormesh and the faint white lines are
> occurring for pdf and svg files, *not* eps files as I originally stated. I
> am also checking a number of display backends and found that the problem
> occurs for GTK
I am curious as to why bar() should even be acting like errorbar(). As a
user, I would expect bar() to do bar graphs and errorbar() to do error bar
graphs. Is there some sort of use-case that I am missing where it makes
sense to generate errorbars from a bar() function?
Ben Root
On Wed, Jun 2,
ay to modify this a
posteriori ?
Cheers,
Denis
Le 02-06-2010, Benjamin Root a
écrit :
> Huh, how about that? I never noticed that before. I wonder if that
> is a bug or if it is intentional?
>
> Ben Root
>
> On Tue, Jun 1, 2010 at 5:28 PM, Denis Laxalde
> wrote:
>
>
On Wed, Jun 2, 2010 at 10:26 AM, John Hunter wrote:
> On Wed, Jun 2, 2010 at 9:48 AM, Benjamin Root wrote:
> > I am curious as to why bar() should even be acting like errorbar(). As a
> > user, I would expect bar() to do bar graphs and errorbar() to do error
> bar
> >
On Wed, Jun 2, 2010 at 11:41 AM, Eric Firing wrote:
> On 06/01/2010 05:21 PM, Benjamin Root wrote:
> > I have finally managed to test against TkAgg, and the faint white lines
> > do not appear to occur. So, as far as I can tell (no clue about Macs),
> > the GTKCairo, pdf
Hello,
I am getting this runtime error for some of my plotting scripts ever since I
did a clean build and install of matplotlib from the svn repo:
[snip]
File "/home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/text.py", line
524, in draw
bbox, info = self._get_layout(renderer)
File "/
Yes! Thank you!
As extra debugging info, the issue was happening regardless of me choosing
GTK, GTKAgg, and others for backends.
Ben Root
On Thu, Jun 3, 2010 at 2:45 PM, John Hunter wrote:
> On Thu, Jun 3, 2010 at 2:41 PM, Benjamin Root wrote:
> > Hello,
> >
> > I am
On Fri, Jun 4, 2010 at 4:53 PM, Jae-Joon Lee wrote:
> On Wed, Jun 2, 2010 at 10:09 PM, Benjamin Root wrote:
> > I have noticed that the svn repo still does not have rasterization
> > decorators for some of the collections (e.g., PolyCollection,
> > EllipseCollection,
Erik,
Thanks for addressing this. I actually ran into this problem once a while
back, but just figured that I was doing something wrong. I will check out
your patch to see how well it works.
Ben Root
On Tue, Jun 8, 2010 at 2:16 PM, Erik Tollerud wrote:
> I noticed some odd behavior in the leg
Has anybody given any further thought to the implication of having Basemap
set adjustable as "box-forced" instead of "box"? So far, it has been
working just fine for me, but I have no clue if there are any unintended
side-effects.
Ben Root
On Tue, Jun 1, 2010 at 6:00 PM,
I was trying the patch and I realized a possible use-case that might not
have been thought of before. Consider the situation where a user does a
scatter plot with markers of two different sizes. Then, it isn't that
far-fetched that the user might also want to control the markerscale for
each mark
On Thu, Jun 10, 2010 at 11:56 AM, Jeff Whitaker wrote:
> On 6/10/10 10:41 AM, Benjamin Root wrote:
>
>
>
> On Thu, Jun 10, 2010 at 11:05 AM, Jeff Whitaker wrote:
>
>> On 6/9/10 1:58 PM, Benjamin Root wrote:
>>
>> Has anybody given any further thought to the
Actually, I just noticed this problem myself after upgrading my system to
Fedora 13. Turns out I still had some *.so files in the lib directory that
were not getting updated by the Make (might be a dependency issue?), and
they weren't getting eliminated by a 'clean' command. Therefore, the old
.s
I agree, while most of the time I call set_xlim() after all plotting is
finished, there are some cases where I call it before subsequent plot calls,
and this is a little nutty. I wonder how this change in behavior would
impact basemap which always seemed to have to code around this issue?
Ben Ro
I just thought of a possible interaction issue that might have to be sorted
out. If we want a .set_xlim() to firmly establish the data limits, what
about a future (or previous) call to ax.set_aspect('equal', 'datalim')?
This causes the data limits to change within the figure box.
Ben Root
On Mon
Hello,
I am working with the Line3D objects in the mplot3d toolkit. I have noticed
that the .set_data() function is not overloaded from the Line class,
therefore, there is no direct way to set the line data. Should a
.set_data() function be created for Line3D or is there some inherent barrier
to
On Fri, Jul 2, 2010 at 2:28 PM, Benjamin Root wrote:
> Hello,
>
> I am working with the Line3D objects in the mplot3d toolkit. I have
> noticed that the .set_data() function is not overloaded from the Line class,
> therefore, there is no direct way to set the line data. Shoul
Hello all,
I have always been a bit troubled with how Axes3D object is a bit of a
2nd-class citizen in matplotlib. In particular, it is very common to create
a new axes using .add_subplot() or .gca(), but you can't do that with
Axes3D. You also can't create subplots of 3d figures, you have to cr
Do we want to add a note to the CHANGELOG for this?
Ben Root
On Wed, Jun 30, 2010 at 4:43 PM, Eric Firing wrote:
> On Wed, 2010-06-30 at 23:08 +0200, Peter Butterworth wrote:
> > On Wed, Jun 30, 2010 at 3:42 AM, Eric Firing wrote:
> > > On Tue, 2010-06-29 at 16:01 -0700, butterw wrote:
> > >>
Oops, sorry, that'll teach me to check more than just the last diff!
Ben
On Sat, Jul 3, 2010 at 2:11 PM, Eric Firing wrote:
> On Sat, 2010-07-03 at 09:13 -0500, Benjamin Root wrote:
> > Do we want to add a note to the CHANGELOG for this?
>
> I did.
>
> Eric
>
&g
Hello,
I came across a typo in mplconfig.py that results in an error when
processing the matplotlib configurations. Attached is a patch.
Ben Root
Index: matplotlib/lib/matplotlib/config/mplconfig.py
===
--- matplotlib/lib/matplotlib
While I don't think this has caused any problems yet, I have noticed a
discrepancy in how a button-click test was being done versus other checks in
the same file. It also makes more sense to check against a compiled list of
buttons instead of using a hard-coding value.
Attached is a patch
Ben Ro
On Sun, Jul 4, 2010 at 8:24 PM, John Hunter wrote:
> On Sun, Jul 4, 2010 at 4:46 PM, Benjamin Root wrote:
> > Hello,
> >
> > I came across a typo in mplconfig.py that results in an error when
> > processing the matplotlib configurations. Attached is a patch.
>
&g
On Sun, Jul 4, 2010 at 9:43 PM, Darren Dale wrote:
> On Sun, Jul 4, 2010 at 9:24 PM, John Hunter wrote:
> > On Sun, Jul 4, 2010 at 4:46 PM, Benjamin Root wrote:
> >> Hello,
> >>
> >> I came across a typo in mplconfig.py that results in an error
the class)
31-32 ('embed_chars' is in the default file, but the config class has
'embed_char_paths')
35-36 (many keys between the class and the file are similar, but not the
same)
The other paragraphs might be interesting, but I hardly know enough to make
such determination
On Mon, Jul 5, 2010 at 3:38 PM, Eric Firing wrote:
> On 07/05/2010 10:22 AM, Benjamin Root wrote:
> > After some more digging, I think I finally found the source of my
> > issues. I have noticed that there are inconsistencies between the keys
> > and sections
Just re-pinging to see if there is any interest in this patch.
Ben Root
On Sat, Jul 3, 2010 at 1:51 AM, Benjamin Root wrote:
> Hello all,
>
> I have always been a bit troubled with how Axes3D object is a bit of a
> 2nd-class citizen in matplotlib. In particular, it is very comm
6:18 PM, John Hunter wrote:
> On Sat, Jul 3, 2010 at 1:51 AM, Benjamin Root
> wrote:
> > Hello all,
> >
> > I have always been a bit troubled with how Axes3D object is a bit of a
> > 2nd-class citizen in matplotlib. In particular, it is very common to
> create
I am working on converting examples in the mplot3d directory when I
discovered that pathpatch3d_demo.py seems to fail while using LaTeX. I am
getting an error "LaTeX Error: File `type1cm.sty' not found." Is anyone
else having this issue or is there something that needs to be setup properly
first?
e.
Thanks,
Ben Root
On Wed, Jul 7, 2010 at 8:47 AM, Michael Droettboom wrote:
> Sounds like something missing from your LaTeX install. How did you
> install it?
>
> Mike
>
>
> On 07/06/2010 09:21 PM, Benjamin Root wrote:
>
> I am working on converting examples in the
On Sun, Jul 18, 2010 at 8:56 AM, João Luís Silva wrote:
> On 07/18/2010 04:58 AM, H Mike Duan wrote:
> > Hi,
> >
> > There seems to be a problem in how 3D surfaces and lines are rendered
> > in mplot3d. The following is a simple script that plots a yellow
> > sphere, a blue wireframe on the surfa
On Sun, Jul 18, 2010 at 12:05 PM, Benjamin Root wrote:
>
>
> On Sun, Jul 18, 2010 at 8:56 AM, João Luís Silva wrote:
>
>> On 07/18/2010 04:58 AM, H Mike Duan wrote:
>> > Hi,
>> >
>> > There seems to be a problem in how 3D surfaces and lines are
On Sun, Jul 18, 2010 at 1:40 PM, Benjamin Root wrote:
> On Sun, Jul 18, 2010 at 12:05 PM, Benjamin Root wrote:
>
>>
>>
>> On Sun, Jul 18, 2010 at 8:56 AM, João Luís Silva wrote:
>>
>>> On 07/18/2010 04:58 AM, H Mike Duan wrote:
>>> > Hi
On Sun, Jul 18, 2010 at 3:33 PM, H Mike Duan wrote:
> Ben,
>
> > Yes, there is a known issue with objects not properly rendering when
> viewed
> > at certain angles. How to go about solving this seems to be a difficult
> one
> > to figure out.
>
> I think the problem is that mplot3d can't reliab
On Sun, Jul 18, 2010 at 3:35 PM, Benjamin Root wrote:
> On Sun, Jul 18, 2010 at 1:40 PM, Benjamin Root wrote:
>
>> On Sun, Jul 18, 2010 at 12:05 PM, Benjamin Root wrote:
>>
>>>
>>>
>>> On Sun, Jul 18, 2010 at 8:56 AM, João Luís Silva wrote:
>&
Hello,
I was just peeking through the code for hsv_to_rgb() and rgb_to_hsv() and
found that they were lacking in comments. While I haven't quite figured out
hsv_to_rgb() and there are some missing documentation regarding how hsv is
represented, I figured that I should make available what I could
On Mon, Jul 19, 2010 at 10:13 AM, Ryan May wrote:
> On Sun, Jul 18, 2010 at 6:16 PM, Benjamin Root wrote:
> > A few corrections. First, I wrong, it is unusual. The second axes that
> I
> > noticed in a 2d case came from a colorbar being added. Second, in the 3d
&g
y set my limits
before the .show() call and save using .savefig()
Attached is a simple script.
Ben
On Thu, Jul 22, 2010 at 9:14 PM, Benjamin Root wrote:
> Attached is a screenshot of what I am seeing with the Tkinter backend (I
> haven't tested others). The lines aren't getting
On Thu, Jul 22, 2010 at 9:46 PM, Eric Firing wrote:
> On 07/22/2010 04:34 PM, Benjamin Root wrote:
> > Heh, looks more pervasive than just the Tkinter backend, and it isn't
> > just caused by zooming. Just moving the image off to the side is
> > enough, and saving t
On Sat, Jul 24, 2010 at 5:08 PM, Eric Firing wrote:
> While running backend_driver.py on the maintenance branch, I found that
> the mplot3d examples were not working. Here is an example:
>
> efir...@manini:~/programs/py/mpl/mpl_v1_0_maint/examples/mplot3d$ python
> wire3d_demo.py
> Traceback (mo
On Tue, Jul 20, 2010 at 9:21 AM, Jeff Klukas wrote:
> Hello,
>
> The documentation for hist seems to indicate that you should be able
> to send a list of values through the 'weights' parameter in axes.hist,
> and this worked in previous versions. In 1.0, however, this produces
> an error. I've
On Mon, Jul 26, 2010 at 7:55 PM, Erik Tollerud wrote:
> Just a quick ping about this - did it get applied, or was there
> something wrong with it? (Or am I just too impatient?)
>
> On Mon, Jul 19, 2010 at 4:26 AM, Erik Tollerud
> wrote:
> > I noticed some odd behavior when trying to set ticks on
On Tue, Jul 27, 2010 at 12:11 AM, David Trem wrote:
> Just for the records, the fix now applied to the svn and
> discuss on this list under """Plot moves while using the "Zoom to
> rectangle" button""" thread also fixes the problem I reported
> earlier this year (see email below).
>
> Best Regard
I am trying to track down a problem in the 3D code, and I have noticed an
issue with Axes3D.add_collection3d(). It checks to see which collection
type you are passing in and will convert them to their 3D equivalent if
possible, and then calls .set_sort_zpos() afterwards. However,
.set_sort_zpos()
On Sun, Jul 25, 2010 at 3:51 PM, Benjamin Root wrote:
> On Tue, Jul 20, 2010 at 9:21 AM, Jeff Klukas wrote:
>
>> Hello,
>>
>> The documentation for hist seems to indicate that you should be able
>> to send a list of values through the 'weights' param
On Thu, Jul 29, 2010 at 3:39 PM, Eric Firing wrote:
> On 07/29/2010 09:31 AM, Benjamin Root wrote:
> [...]
> >
> > Good catch, Jeff. Looking over the code, looks like both the input
> > data, x, and the weights get similar pre-processing done to ready it
>
On Fri, Jul 30, 2010 at 9:54 AM, Damon McDougall
wrote:
> Hi,
>
> I'm interested in fiddling around with the matplotlib source. Let's say we
> set up various things:
>
> from matplotlib.figure import Figure()
> from matplotlib.backends.backend_pdf import FigureCanvasPdf as FigureCanvas
>
> fig = F
On Fri, Aug 6, 2010 at 3:33 PM, Damon McDougall
wrote:
> Hi all,
>
> Don't know if anybody else has found a colormap that is aesthetically
> pleasing and prints well in black and white. I found one after a lot of
> Googling. Perhaps useful for plotting figures in journals that charge a lot
> for c
Same here with r8611
Ben Root
On Fri, Aug 6, 2010 at 2:36 PM, Gökhan Sever wrote:
> Hello,
>
> Just reporting if all is good with the mpl test suite.
>
> >>> import matplotlib
> >>> matplotlib.test()
> /home/gsever/Desktop/python-repo/matplotlib/lib/matplotlib/axes.py:2377:
> UserWarning: Attem
On Mon, Aug 9, 2010 at 3:28 AM, Ben North wrote:
> Hi,
>
> I tried to use "edgecolor = 'none'" in a call to bar(), hoping to get no
> border to the bars, but instead got no bars at all. The patch below
> (against 1.0.0) seems to fix this; it adds a check for 'none' to the
> existing check for No
On Mon, Aug 9, 2010 at 3:40 PM, Friedrich Romstedt <
friedrichromst...@gmail.com> wrote:
> 2010/8/6 Benjamin Root :
> > Actually, I have been looking at a somewhat related problem. It might be
> a
> > useful feature in matplotlib.color to provide a function that can
On Tue, Aug 10, 2010 at 4:21 PM, Eric Firing wrote:
> On 08/10/2010 10:27 AM, Friedrich Romstedt wrote:
> > Ah, the list config got me ... (resending to list)
> >
> > 2010/8/10 Benjamin Root:
> >> I am working on a function that can take a Colormap object and retu
On Tue, Aug 10, 2010 at 7:20 PM, Eric Firing wrote:
> On 08/10/2010 11:58 AM, Friedrich Romstedt wrote:
> > 2010/8/10 Eric Firing:
> >> On 08/10/2010 10:27 AM, Friedrich Romstedt wrote:
> >>> So I think it is probably best to code it into the Colormap object
> >>> itself, so that each and ever de
On Tue, Aug 10, 2010 at 7:39 PM, Benjamin Root wrote:
> On Tue, Aug 10, 2010 at 7:20 PM, Eric Firing wrote:
>
>> On 08/10/2010 11:58 AM, Friedrich Romstedt wrote:
>> > 2010/8/10 Eric Firing:
>> >> On 08/10/2010 10:27 AM, Friedrich Romstedt wrote:
>> >&g
On Wed, Aug 11, 2010 at 11:47 AM, Friedrich Romstedt <
friedrichromst...@gmail.com> wrote:
> 2010/8/11 Eric Firing :
> > Why make a whole new class instead of switching a behavior in an existing
> > class?
>
> To my understanding, making object having "behaviours" is usually not
> a good idea - I
On Wed, Aug 11, 2010 at 1:27 PM, John Hunter wrote:
> On Wed, Aug 11, 2010 at 12:35 PM, Eric Firing wrote:
> > John et al.,
> >
> > Is this a reasonable time to put out 1.0.1? There have been quite a few
> > bugfixes and other cleanups since 1.0. Most likely the biggest problem
> with
> > 1.0
I am tracing down a bug in hist() and I am trying to figure out what is it
about the 'stepfilled' mode that is different from the regular 'bar' mode.
Currently, the hist() code has a separate if branch for dealing with 'step'
and 'stepfilled', and that branch has a bunch of bugs. The best that I c
On Wed, Aug 11, 2010 at 3:11 PM, Benjamin Root wrote:
> I am tracing down a bug in hist() and I am trying to figure out what is it
> about the 'stepfilled' mode that is different from the regular 'bar' mode.
> Currently, the hist() code has a separate if branch
On Mon, Aug 9, 2010 at 10:02 AM, Ben North wrote:
> >> I tried to use "edgecolor = 'none'" in a call to bar(), hoping to get no
> >> border to the bars, but instead got no bars at all.
> >
> > Just to note, the documentation does specify a difference between None
> and
> > 'none'. None means to
On Thu, Aug 12, 2010 at 10:13 AM, Ben North wrote:
> Ben Root:
> >Ben North:
> >> Same kind of thing with
> >> the kwarg 'color' instead of 'edgecolor', which is also fixed in my
> >> second recent email.
> >
> > Looking through the code for bar(), I see the same thing occurs for the
> > 'color'
I am currently working to patch something in colors.py and I am coming
across a lot of older style code and code that duplicates functionality that
can be found in cbook.py (particularly the type-checking functions). Is
there a standing rule that code that we come across should get updated or
adap
On Thu, Aug 12, 2010 at 2:39 PM, John Hunter wrote:
> On Thu, Aug 12, 2010 at 2:34 PM, Benjamin Root wrote:
> > I am currently working to patch something in colors.py and I am coming
> > across a lot of older style code and code that duplicates functionality
> that
> >
On Thu, Aug 12, 2010 at 12:37 PM, Eric Firing wrote:
> On 08/12/2010 06:09 AM, Benjamin Root wrote:
> > On Thu, Aug 12, 2010 at 10:13 AM, Ben North > <mailto:b...@redfrontdoor.org>> wrote:
> >
> > Ben Root:
> > >Ben North:
> >
On Thu, Aug 12, 2010 at 3:58 PM, Eric Firing wrote:
> On 08/12/2010 09:56 AM, Benjamin Root wrote:
>
> > Btw, the current set of tests has a failure for testing pcolormesh.
> > Wasn't there a change fairly recently to fix a problem with pcolormesh,
> > so that
On Fri, Aug 13, 2010 at 12:11 PM, Eric Firing wrote:
> On 08/13/2010 06:20 AM, Benjamin Root wrote:
> >
> >
> > On Thu, Aug 12, 2010 at 3:58 PM, Eric Firing > <mailto:efir...@hawaii.edu>> wrote:
> >
> > On 08/12/2010 09:56 AM, Benjamin Root
On Fri, Aug 13, 2010 at 12:31 PM, Eric Firing wrote:
> On 08/13/2010 07:20 AM, Benjamin Root wrote:
> > On Fri, Aug 13, 2010 at 12:11 PM, Eric Firing > <mailto:efir...@hawaii.edu>> wrote:
> >
> > On 08/13/2010 06:20 AM, Benjamin Root wrote:
> >
On Fri, Aug 13, 2010 at 1:18 PM, John Hunter wrote:
> On Fri, Aug 13, 2010 at 12:53 PM, Benjamin Root wrote:
>
> > Where are the difference images saved to? Or do I have to pass an option
> to
> > matplotlib.test() to generate those? I only have a directory
>
&
On Fri, Aug 13, 2010 at 1:34 PM, John Hunter wrote:
> On Fri, Aug 13, 2010 at 1:26 PM, Benjamin Root wrote:
> > Found it. It is solid black.
>
> Not quite:
> In [95]: im =
> imread('/home/titan/johnh/Downloads/failed-diff-pcolormesh.png').ravel()
>
> In
On Thu, Aug 12, 2010 at 4:46 PM, Eric Firing wrote:
> On 08/12/2010 10:40 AM, Benjamin Root wrote:
> [...]
> > >
> > > >>> mcolor.colorConvertor.to_rgba_array('none')
> > > array([], shape=(0, 4), dtype=float64)
> > &
On Fri, Aug 13, 2010 at 4:43 PM, Eric Firing wrote:
> On 08/13/2010 10:35 AM, Benjamin Root wrote:
> > On Thu, Aug 12, 2010 at 4:46 PM, Eric Firing > <mailto:efir...@hawaii.edu>> wrote:
> >
> > On 08/12/2
On Mon, Aug 16, 2010 at 4:48 PM, Friedrich Romstedt <
friedrichromst...@gmail.com> wrote:
> Ben, I fully agree with you that figures should be able to be saved
> both coloured and grayscale. It was a misunderstanding. What I meant
> was, that it will not be necessary to display one part of the f
On Tue, Aug 17, 2010 at 4:19 PM, Friedrich Romstedt <
friedrichromst...@gmail.com> wrote:
> 2010/8/17 Benjamin Root :
> > "...it will not be necessary..."
> >
> > I think we are still getting confused here. I was listing off several
> > different kinds
On Wed, Aug 18, 2010 at 2:08 PM, Friedrich Romstedt <
friedrichromst...@gmail.com> wrote:
> 2010/8/18 Benjamin Root :
> > I had a thought... and it is based on my admittedly incomplete
> understanding
> > of matplotlib. Everything that gets drawn is derived from the a
On Tue, Aug 24, 2010 at 1:48 PM, Erik Tollerud wrote:
> Sorry for the re-ping if it was taken care of in some way I didn't
> undertand, but this doesn't seem to have been changed on the trunk
> svn... should it have been, or is there some other branch that this
> stuff is being worked on?
>
> On T
On Tue, Aug 24, 2010 at 6:16 PM, Erik Tollerud wrote:
> Whoops, yes, that should be True... Also realized a slight error in
> the description of how the mimum is set - both of those are fixed in
> the attached diff.
>
> On Tue, Aug 24, 2010 at 1:53 PM, Eric Firing wrote:
> > On 08/24/2010 08:39 A
On Tue, Aug 24, 2010 at 9:01 PM, Anne Archibald
wrote:
> On 24 August 2010 19:16, Erik Tollerud wrote:
> > Whoops, yes, that should be True... Also realized a slight error in
> > the description of how the mimum is set - both of those are fixed in
> > the attached diff.
>
> Um, this is a kind of
On Wed, Aug 25, 2010 at 12:00 AM, Anne Archibald wrote:
> On 24 August 2010 22:22, Benjamin Root wrote:
> > On Tue, Aug 24, 2010 at 9:01 PM, Anne Archibald <
> aarch...@physics.mcgill.ca>
> > wrote:
> >>
> >> On 24 August 2010 19:16, Erik Tollerud wrot
On Fri, Aug 27, 2010 at 7:21 AM, Stan Schymanski wrote:
> Dear all,
>
> I don't know which update it was that broke it, but this used to work:
>
> import numpy
> import pylab
> pylab.clf()
> fig = pylab.figure(1,figsize=(8,5))
> ax = fig.add_subplot(111, autoscale_on=False, xlim=(-1,5),
> ylim=(-4
On Mon, Aug 30, 2010 at 2:21 AM, Fernando Perez wrote:
> Hi Eric,
>
> On Sat, Aug 28, 2010 at 4:27 PM, Eric Firing wrote:
> >
> > Impressive--but I don't think I understand why one would want plots
> rendered
> > inline rather than in separate windows.
>
> It's not 'rather than', it's 'in additio
On Tue, Aug 31, 2010 at 2:38 AM, imsc wrote:
>
> Is there any development in this project. I was searching for the ways to
> change the subplot sizes, but could not find any easy or nicer way.
>
>
> --
> View this message in context:
> http://old.nabble.com/Custom-sized-and-spanning-subplots-tp20
Hello,
I have been working on a couple of interesting concoctions for matplotlib.
The first is a wrapper class called "ThinWrap" that, essentially, provides a
way to create objects that are linked to a given object. These objects can
then be subclassed for some very interesting behaviors. Which
On Mon, Aug 30, 2010 at 10:48 AM, Stan West wrote:
> Greetings. The attached script saves three EPS files (also attached) of a
> figure containing a text object using the Liberation Sans font. In the three
> EPS files, the text object contains no spaces, a normal space, and a
> non-breaking spac
On Wed, Sep 1, 2010 at 11:29 AM, Stan West wrote:
> *From:* ben.v.r...@gmail.com [mailto:ben.v.r...@gmail.com] *On Behalf Of
> *Benjamin Root
> *Sent:* Tuesday, August 31, 2010 23:20
>
> I can confirm that evince also has a problem with the second image, but not
> the first o
There was a bug report recently (not to the mailing list) where the reporter
noted that if an Axes3D was created using the fig.add_subplot(111,
projection='3d') or fig.gca(projection='3d'), then you can not clear the
figure using fig.clf(). Doing so causes an exception to be thrown.
Tracing down
On Thu, Sep 2, 2010 at 3:51 PM, Ryan May wrote:
> On Sep 2, 2010, at 14:14, Benjamin Root wrote:
>
> > There was a bug report recently (not to the mailing list) where the
> reporter noted that if an Axes3D was created using the fig.add_subplot(111,
> projection='3d'
On Thu, Sep 2, 2010 at 7:57 PM, Eric Firing wrote:
> On 09/02/2010 01:21 PM, Benjamin Root wrote:
> > On Thu, Sep 2, 2010 at 3:51 PM, Ryan May > <mailto:rma...@gmail.com>> wrote:
> >
> > On Sep 2, 2010, at 14:14, Benjamin Root > <mailto:ben.r...@o
On Sat, Sep 4, 2010 at 3:20 AM, Jae-Joon Lee wrote:
> On Fri, Sep 3, 2010 at 4:14 AM, Benjamin Root wrote:
> > I think there are multiple issues here. Primarially, there is the issue
> > that Axes3D is attaching itself to a figure. However, in the interest of
> > backwa
On Sun, Sep 5, 2010 at 2:53 PM, Eric Firing wrote:
> On 09/04/2010 05:50 PM, Benjamin Root wrote:
> > On Sat, Sep 4, 2010 at 3:20 AM, Jae-Joon Lee > <mailto:lee.j.j...@gmail.com>> wrote:
> >
> > On Fri, Sep 3, 2010 at 4:14 AM, Benjamin Root >
1 - 100 of 664 matches
Mail list logo
