OK, I reverted back to the tried and true MPL way... It hasn't been
completely unproductive, however: I added tests for infinity (either
sign) and finite-ness to MPL_isnan.h. (On top of which I now understand
the IEEE 754 representations far better than I care to.)
Now, this should work just li
It looks like Edin made setuptools required in svn, which I just
reverted. Edin -- why? I'm a fan of setuptools, but I don't think we
should require a prerequisite that isn't necessary. Of course, if the
developers decide we want to require setuptools, I'm happy to support
the change, but it should
Hi,
I don't have time to root around for the cause right now, but the PDF
backend isn't working. See the attachment for tracebacks generated with
"python backend_driver.py pdf" This is with recent svn (3565).
-Andrew
$ python backend_driver.py pdf
testing pdf
driving alignment_test.p
Darren Dale wrote:
> Hi Andrew,
>
> On Wednesday 18 July 2007 4:00:05 pm Andrew Straw wrote:
>> I don't have time to root around for the cause right now, but the PDF
>> backend isn't working. See the attachment for tracebacks generated with
>> "python
John Hunter wrote:
>>> Do we want to use 3x3 or 4x4 to leave the door open for 3D developers?
>> 4X4 -- is there much cost?
>
> The potential cost is not in the 3x3 vs 4x4, but in the extra row of
> junk data you would store in the data matrix, which is N extra values
> for plotting N points . T
Gael Varoquaux wrote:
> On Thu, Sep 06, 2007 at 08:46:24AM -0400, Paul Kienzle wrote:
>> We could store a copy of the png output somewhere in the svn tree.
>> Then,
>> whenever we change something we can do a binary comparison on all the
>> plots. It would avoid issues such as breakage of polar pl
Eric Firing wrote:
> Darren Dale wrote:
>
>
>> 3) We can not include traits-3 without either adding setuptools as an
>> external
>> dependency (which is already true for python-2.3 users) or monkey-patching
>> distutils. traits-3 includes some pyrex code, which standard distutils does
>> not
In any case, I think it's dangerous to set numpy's global error handling
mode permanently. Is it feasible to do this on a need-to-protect basis
by wrapping just the cases where this is needed with:
npy_orig_err = npy.seterr(invalid='ignore')
try:
do_potentially_risky_stuff()
finally:
n
John Hunter wrote:
> ( I configured my emacs to detect
> whitespace) and suspect I may have been a trailing whitespace
> contributer,
Can you give me a pointer about what exactly you did? Just now, I just
discovered a whitespace-cleanup and a whitespace-visual-mode. It'd be
nice if there was somet
Thanks, that works, but unforunately only on emacs21 but not xemacs 21.
Looks like I'll now have to find a way to do the one thing in emacs that
keeps me using xemacs: goto-line bound to M-g. (Any quick tips appreciated.)
-Andrew
John Hunter wrote:
> On Nov 21, 2007 1:37 PM, Andrew Straw
Eric Firing wrote:
> Yes, I understand, and I am sorry--but I hope it is one-time pain to
> avoid continuing pin-pricks. If svn ignored trailing whitespace, then
> there would be no problem; I could continue to use an editor that
> removes it, and you could continue to use editors that gratuito
Hi Michael, This looks very impressive.
Not understanding what kind of magic is happening underneath, I wonder
how this can work to keep the data areas aligned in cases where the user
initially sets the axes locations arbitrarily but then later sets them
to the final desired values after drawi
Michael Droettboom wrote:
> ...probably because I forgot to attach it. (When will my e-mail
> client read my mind?) I've also attached a version with a new version
> of the layout algorithm -- in addition to making all axes that were
> initially aligned remain aligned, it sets an axes that ori
Michael Droettboom wrote:
> Andrew,
>
> I'm embarrassed to admit I wasn't familiar with mplsizer before I
> looked into this. The user "API" of mplsizer actually looks like it
> would be much easier to support the text-overlapping problem, since
> the placement of the axes in a grid is more exp
If we're going to use setuptools (actually already required for Python
2.3), I think we need to do it completely and not optionally --
otherwise users will start to depend on its features, which simply won't
be there in some cases. In particular, I suspect they will make use of
the dependency r
Hi,
mlab.defaultformatd sets the default float formatter for rec2csv() to be
something that doesn't keep the full representation of a floating point
number. Obviously, I can pass in my own formatd argument to rec2csv(),
but I wonder if there's any reason why defaultformatd shouldn't use
repr()
file not loose precision,
Andrew
John Hunter wrote:
> On Dec 15, 2007 3:13 PM, Andrew Straw <[EMAIL PROTECTED]> wrote:
>
>> mlab.defaultformatd sets the default float formatter for rec2csv() to be
>> something that doesn't keep the full representation of a floating
OK, I created a test for numpy to isolate an issue:
http://scipy.org/scipy/numpy/ticket/629
I think setting MPL's behavior to repr() is good, though. John, I see
you did that r4745 -- thanks.
-Andrew
Fernando Perez wrote:
> On Dec 15, 2007 2:52 PM, Andrew Straw <[EMAIL PROTEC
ld close a file handle
passed to it. This prevents use with StringIO, for example. So, I added
a test for that, too. John, if it's not going to break anything for you,
I'll go ahead and fix that.
John Hunter wrote:
> On Dec 15, 2007 3:13 PM, Andrew Straw <[EMAIL PROTECTED]> wrote
Done in r4748. I added the kwarg "return_opened" to cbook.to_filehandle().
John Hunter wrote:
> On Dec 16, 2007 1:33 PM, Andrew Straw <[EMAIL PROTECTED]> wrote:
>> OK, I added unit/mlab_unit.py to svn. This checks that double precision
>> floats can round-trip throu
As a followup to the work on floats, I fixed rec2csv to deal with funky
strings (strings with commas and quotes). I've checked this is as r4749,
but I thought I'd announce here in case someone (John, in particular)
was depending on some peculiar aspect of the old implementation. If
there is som
(And if
they're thinking about it, maybe the slowness with dissuade them, or at
least cause them to read the docstrings! :)
John Hunter wrote:
> On Dec 16, 2007 5:26 PM, Andrew Straw <[EMAIL PROTECTED]> wrote:
>
>
>> As a followup to the work on floats, I fixed rec2csv
Fernando Perez wrote:
> It's probably worth mentioning that one of the reasons John chose Agg
> is because of image *quality* concerns. If I'm not mistaken (John and
> A. Straw will correct me as needed), the OpenGL anti-aliasing quality
> is positively horrible when you compare it to the quality
Something I haven't seen addressed on the numpy list (or here) is using
hg or bzr to mirror an svn repository. What would be the added advantage
to the project of using a DVCS if all the DVCS-ophiles would simply sync
the svn tree?
Eric Firing wrote:
> John Hunter wrote:
>> On Jan 7, 2008 2:37
As the author of the only other known MPL toolkit (at least in the MPL
tree), I'm happy with the idea of using a namespace package for
mpl_toolkits. I understand your proposal to mean that each toolkit would
have a directory structure:
setup.py
lib/
mpl_toolkits/
__i
Jeff Whitaker wrote:
> Darren Dale wrote:
>> On Wednesday 09 January 2008 7:01:14 pm Jeff Whitaker wrote:
>>
>>> Andrew Straw wrote:
>>>
>>>> As the author of the only other known MPL toolkit (at least in the MPL
>>>> tree),
Great -- hopefully that saved you some API re-arrangement pain. No
problem on shuffling mpl_sizer around -- please go ahead do it if you
have time.
-Andrew
Jeff Whitaker wrote:
> Andrew: Thanks, you've convinced me. Is it OK with you if I go ahead
> and make those changes to mplsizer at the
I just ran into a bug with picking of lines. I changed the line style in
figure 1, subplot 1 to 'o-' (from 'o') and ripped out most of everything
else in examples/pick_event_demo.py to create pick_event_demo3.py
(attached). When I run this and I attempt to click on points, I get
Traceback (most re
For those of you wondering "what is sphinx?" this will save you a few
seconds of searching: http://sphinx.pocoo.org/
The output looks really nice.
Darren Dale wrote:
> There was some discussion a while back concerning upcoming changes to the mpl
> documentation: moving the docs into the trunk an
Hi all,
I just discovered that attempting to plot a complex array using imshow()
results in a not-very-helpful traceback (attached). Would it be worth
catching this on the actual call to imshow() and raising a more
transparent error? (The test script, slightly modified from Gaël
Varoquaux's pyrepo
Hi Eric,
show() isn't bringing up my plots with r5430 in normal scripts (i.e. not
using IPython).
-Andrew
Eric Firing wrote:
> While investigating a bug pointed out by Andrew (and one that I had
> introduced some time ago) I found to my horror that I had also caused
> another bug: interactive
Hi,
When I attempt to plot small-scale features with the PS backend, it
seems that there's a granularity at which things cannot be further
specified. I cannot remember encoutering this before, although I can't
be sure it's not an old phenomenon. Anyhow, the following script
illustrates the issue.
Hi,
I've encountered behavior in the svn trunk that I think is a bug.
Namely, the axes view limits are reset to the data limits upon a UI
event callback. In the attached test script for example, the plot
initially displays with the correct view limits (between -10 and 10 on
the X axis). However, w
John Hunter wrote:
> On Thu, Jul 17, 2008 at 7:48 AM, Sandro Tosi <[EMAIL PROTECTED]> wrote:
>
>> Hi All,
>> I'd like to "resubmit" the request below: any new version to be
>> released soon? in the process to generate the doc in Debian, something
>> got fixed upstream, so a new release would be
Michael Droettboom wrote:
> Should be fixed in r5775.
>
> It seems Agg doesn't like MOVETO commands and the end of a path. Since
> the update is in a C++ header file, you will need to force a full
> rebuild (by removing your build directory, for instance.)
Thanks, I tested and this fixes the iss
I just spent a little time getting hexbin to discard nans without
failing in mysterious ways.
I'm sending 2 patches: one will detect nans and raise a suitable
exception. The other will automatically drop the nans and continue with
hexbin. The 2nd seems a little nicer in functionality, but the code
It appears the current svn trunk has a problem in that gtk.main() in
backend_gtk.py line 71 never returns, even after all windows have been
closed. To reproduce, run "python simple_plot.py -dGTKAgg" and close the
window. This does not happen with WXAgg or TkAgg.
-Andrew
--
John Hunter wrote:
> On Fri, Jul 18, 2008 at 2:49 PM, Andrew Straw <[EMAIL PROTECTED]> wrote:
>
>> I just spent a little time getting hexbin to discard nans without
>> failing in mysterious ways.
>>
>> I'm sending 2 patches: one will detect nans and rais
Eric Firing wrote:
> John Hunter wrote:
>> On Fri, Jul 18, 2008 at 4:42 PM, Andrew Straw <[EMAIL PROTECTED]>
>> wrote:
>>
>>> If you're happy with that extra cost, I'll modify
>>> axes.delete_masked_points() so that hexbin and scatter are
Eric Firing wrote:
> Ryan May wrote:
>
>> Eric Firing wrote:
>>
>>> Ryan May wrote:
>>>
Hi,
In looking over trying to support masked arrays in wind barbs, I noticed
a problem. I had originally copied the model of quiver, wherein masked
arrays are supported f
Ryan May wrote:
> Hi,
>
> I noticed that offset_copy() went away in the transforms rewrite and was
> replaced with a trans + transfroms.Affine2D().translate(x,y). This
> works fine for x,y in pixels. However, offset_copy would also let you
> specify x,y in points. How can I get that to work
I just fixed a small bug when bins were not filled and C was specified.
Attached is the revised version.
Index: lib/matplotlib/axes.py
===
--- lib/matplotlib/axes.py (revision 5892)
+++ lib/matplotlib/axes.py (working copy)
@@ -4941,24
Eric Firing wrote:
> Andrew Straw wrote:
>> Hi all,
>>
>> I've added some functionality to my copy hexbin, and I thought I'd
>> bounce it off folks (esp. Michael) to see if it seems like a good idea
>> to add it to MPL.
>>
>> Here's
Hi all,
Shocked by news of John Hunter's untimely severe health problems and now
death, I have been thinking about what we could do as a community to 1)
fuel matplotlib to further heights and 2) give everyone, but especially
John's family, some appreciation for how wide, and ongoing, his impact
201 - 244 of 244 matches
Mail list logo
