attribution to the original author(s).
Michael Droettboom, chair
Jacob Vanderplas
Phil Elson
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
polation
* control of baselines in stackplot
* many improvements to text and color handling
For a complete list of what's new, see
<http://matplotlib.org/users/whats_new.html#new-in-matplotlib-1-3>http://matplotlib.org/users/whats_new.html#new-in-matplotlib-1-3
Have fun, and enjo
Apologies: I didn't realize the link to the raw results only exists for
users with edit permissions. The public URL for the raw results is:
https://docs.google.com/spreadsheet/ccc?key=0AjrPjlTMRTwTdHpQS25pcTZIRWdqX0pNckNSU01sMHc&usp=sharing
Mike
On 07/18/2013 09:42 AM, Michael D
We have had 508 responses to the matplotlib user survey. Quite a nice
turnout!
You can view the results here:
https://docs.google.com/spreadsheet/viewanalytics?key=0AjrPjlTMRTwTdHpQS25pcTZIRWdqX0pNckNSU01sMHc&gridId=0#chart
and from there, you can access the complete raw results.
I will be d
ing lists.
Cheers,
Michael Droettboom, and the matplotlib team
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
I'm pleased to announce the release of matplotlib 1.2.1. This is a bug
release and improves stability and quality over the 1.2.0 release from
four months ago. All users on 1.2.0 are encouraged to upgrade.
Since github no longer provides download hosting, our tarballs and
binaries are back on
<http://scipy.us1.list-manage.com/profile?u=e91b4574d5d1709a9dc4f7ab7&id=069dcb6ee4&e=7c1fb2879c>
*Our mailing address is:*
Enthought, Inc.
515 Congress Ave.
Austin, TX 78701
Add us to your address book
<http://scipy.us1.list-manage.com/vcard?u=e91b4574d5d1709a9dc4f7ab7&id=069d
Austin TX *
Winners will be announced during the conference days
* Friday-Saturday, June 27 - 28: SciPy 2013 Sprints, Austin TX & remote
We look forward to exciting submissions that push the boundaries of
plotting, in this, our first attempt at this kind of competition.
The SciPy Pl
If I may also point out another simple (but critical for astropy) bugfix
related to masked arrays:
https://github.com/numpy/numpy/pull/2747
Mike
On 11/14/2012 02:46 PM, Thomas Robitaille wrote:
I've recently opened a couple of pull requests that fix bugs with
MaskedArray - these are pretty st
On 04/03/2012 12:48 PM, Chris Barker wrote:
It would be nice to have a clean C++ wrapper around ndarrays, but that
doesn't exist yet (is there a good reason for that?)
Check out:
http://code.google.com/p/numpy-boost/
Mike
___
NumPy-Discussion mailing
The return type of PyArray_BYTES in the old API compatibility code seems
to have changed recently to (void *) which breaks matplotlib builds.
This pull request changes it back. Is this correct?
https://github.com/numpy/numpy/pull/121
Mike
___
NumPy-
ions ``numpy.unique1d``, ``numpy.setmember1d``,
> ``numpy.intersect1d_nu`` and ``numpy.lib.ufunclike.log2`` were removed.
>
>
> ``numpy.ma``
>
>
> Several deprecated items were removed from the ``numpy.ma`` module::
>
>* ``numpy.ma.MaskedArray`` "raw_data" method
>* ``numpy.ma.
idate next weekend if
> these are solved. As far as I know no one is working on the doc
> issues right now. It would be great if someone could step up and do
> this.
>
> Thanks,
> Ralf
> ___
> NumPy-Discussion mailing list
>
Just wanted to make the developers aware of this bug that causes one of
our pyfits unit tests to fail:
http://projects.scipy.org/numpy/ticket/1733
Mike
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/
Christian
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
--
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Mar
http://mail.scipy.org/mailman/listinfo/numpy-discussion
--
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA
Changes in HEAD
Modified doc/sphinxext/docscrape.py
diff --git a/doc/sphinxext/docscrape.py b/doc/sphinxext/docscra
.scipy.org/doc/numpy/reference/generated/numpy.recarray.html
Is this a bug?
Mike
--
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On 08/17/2010 08:10 PM, Ralf Gommers wrote:
On Wed, Aug 18, 2010 at 3:08 AM, Charles R Harris
mailto:charlesr.har...@gmail.com>> wrote:
On Tue, Aug 17, 2010 at 11:27 AM, Michael Droettboom
mailto:md...@stsci.edu>> wrote:
I'm getting one unit test e
-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
--
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
htt
> negligible:
>
> import time
> def f(x):
>time.sleep(0.5)
>return 2*x
>
> df = deco.persistent_locals(f)
>
> %timeit f(1)
> 10 loops, best of 3: 501 ms per loop
> %timeit df(1)
> 10 loops, best of 3: 502 ms per loop
>
> Conclusion
>
&g
1 == a2
array([ True, True], dtype=bool) # Looks good
>> a2 == a1
False # Should I have expected this?
--
Michael Droettboom
Science Software Branch
Space Telescope Science Institut
et around it from your code is to cast the chararray
pyfits returns to a regular ndarray. The cast does not perform a copy,
so should be very efficient:
In [6]: from numpy import char
In [7]: import numpy as np
In [8]: c = char.array(['a ', 'b '])
In [9]: c
Out[9]:
chararray(
building numpy on various flavors
> of
> CentOS/RHEL5.x.
>
We (STScI) routinely build Numpy on RHEL5.x 64-bit systems for our internal
use. We need more detail about what you're doing and what errors you're seeing
to diagnose the problem.
Mike
--
Michael Droettboom
Science Soft
e the "array too large" exception before
trying to dereference the NULL array pointer (ret) in PyArray_FromFile
(see attached patch). But my question is: is this an appropriate fix
for 1.4 (it seems pretty straightforward), or should I only make this to
the trunk?
Mike
--
Mic
t doing doctests
as a matter of course to keep the docs accurate.
Mike
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
___
NumPy-Discussion mailing list
rrect?
http://projects.scipy.org/numpy/ticket/1173
http://projects.scipy.org/numpy/ticket/1174
Mike
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
___
Pauli Virtanen wrote:
> ma, 2009-12-07 kello 09:50 -0500, Michael Droettboom kirjoitti:
>
>> Pauli Virtanen wrote:
>>
> [clip]
>
>>> The character 'B' is already by unsigned bytes -- I wonder if it's easy
>>> to support &#x
Pauli Virtanen wrote:
> ma, 2009-12-07 kello 09:12 -0500, Michael Droettboom kirjoitti:
>
>>> We need character arrays for the astro people. I assume these will be
>>> byte arrays. Maybe Michael will weigh in here.
>>>
>> I can't find in th
s there a way to
explicitly list the methods for the chararray class?
Mike
Michael Droettboom wrote:
> If this:
>
> http://docs.scipy.org/numpy/docs/numpy.core.defchararray.chararray/
>
> is the most recent revision, then it looks good to me. It does seem to
> incorporate my n
t strings. Hopefully all the new chararray unit tests
will help with this transition.
Mike
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
___
NumPy-Discussion
gt; returned as a value.
>>
>
> Maybe it is so because some code paths are shared with the == operation?
>
> But in any case, NotImplemented should never be returned to the user --
> I believe it's only meant to be an internal value used in determining
> the prope
mPy-Discussion@scipy.org>
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
> Thanks, guys!
>
> DG
>
>
> _______
> NumPy-Discussion mailing list
> NumPy-Discussi
Unfortunately, I can't reproduce it on Solaris/SPARC (SVN r7878,
trunk). Could it be Linux/SPARC-specific? (We don't have a Linux/SPARC
machine lying around, I don't think).
Mike
Michael Droettboom wrote:
> Charles R Harris wrote:
>
>> On Thu, Dec 3, 2009
em_INCREF call (though
> it uses the new copy-object-before-refcount-changes semantics).
>
>
> Would that cause a bus error? That looks like an alignment issue.
> There was another buffer alignment issue a while back that I fixed,
> I'll try to track it down. Maybe we can g
)
>
> window.show()
>
> gtk.main()
>
>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
vs. OSX installations?Generally
> speaking can I / should I be relying on casting from object arrays
> to do the "right" (or "intuitive") thing?
>
> thanks,
> Dan
>
>
>
t - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
>
>
> _______
>
On 11/12/2009 05:56 PM, David Cournapeau wrote:
> On Thu, Nov 12, 2009 at 11:34 PM, Michael Droettboom wrote:
>
>> I'm happy to make these changes, since I've got access to the "finicky"
>> platform, but want to confirm how you would prefer it done firs
s, since I've got access to the "finicky"
platform, but want to confirm how you would prefer it done first.
Mike
David Cournapeau wrote:
> On Thu, Nov 12, 2009 at 12:45 AM, David Cournapeau wrote:
>
>
>> I will implement this, but I would prefer using this met
O, np.PZERO))
False (Solaris) True (other)
The easy fix seems to be to force it to use the npy_math version of
atan2 on Solaris (as we already do for MS Windows). (Patch attached).
Indeed this fixes the unit tests. Does that seem right?
Mike
--
Michael Droettboom
Science Software B
Forgot to attach the patch.
Mike
Michael Droettboom wrote:
Thanks. Behind that, however, it runs into this compiler shortcoming:
cc: build/src.solaris-2.8-sun4u-2.5/numpy/core/src/npymath/npy_math.c
"numpy/core/src/npymath/npy_math_private.h", line 229: invalid type
for bit-f
l in terms of those, just for consistency.
Cheers,
Mike
David Cournapeau wrote:
> On Wed, Nov 11, 2009 at 6:18 AM, Michael Droettboom wrote:
>
>> I don't know if your 'long double' detection code is complete yet, but I
>> thought I'd share the curr
e_sources
source = func(extension, build_dir)
File "numpy/core/setup.py", line 425, in generate_config_h
raise ValueError("Unrecognized long double format: %s" % rep)
ValueError: Unrecognized long double format: IEEE_QUAD_BE
David Cournapeau wrote:
> On Thu, N
David Cournapeau wrote:
> On Thu, Nov 5, 2009 at 2:15 AM, Michael Droettboom wrote:
>
>> I'm getting the following from r7603 on Solaris Sparc -- somehow related
>> to not having a long double version of next after available. I realise
>> not everyone has access
p failed for numpy/core/src/npymath/ieee754.c
"numpy/core/src/npymath/ieee754.c", line 172: #error: Needs nextafterl
implementation for this platform
cc: acomp failed for numpy/core/src/npymath/ieee754.c
Cheers,
Mike
--
Michael Droettboom
Science Software Branch
Operations and Engineeri
Travis Oliphant wrote:
> On Oct 27, 2009, at 2:31 PM, Michael Droettboom wrote:
>
>
>> Christopher Barker wrote:
>>
>>> Nadav Horesh wrote:
>>>
>>>
>>>> np.equal(a,a).sum(0)
>>>>
>>>> but, for un
t;==" reverting to plain old generic
> python sequence comparison, which would partly explain why it is so slow.
>
It looks as if "a == a" (that is array_richcompare) is triggering
special case code for strings, so it is fast. However, IMHO np.equal
should be made to work as
On 10/27/2009 05:11 AM, Pauli Virtanen wrote:
> Mon, 26 Oct 2009 14:26:20 -0400, Michael Droettboom wrote:
>
>> I know David Cournapeau has done some work on using gcov for coverage
>> with Numpy.
>>
>> Unaware of this, (doh! -- I should have Googled first), I wr
e results occasionally misses lines that clearly must have
been run. This usually can be traced back to the compiler optimizer
removing lines because they are tautologically impossible or to
combine lines together. Compiling Numpy without optimizations helps,
but not completely. Even despite
Done. Issue #50.
Thanks,
Mike
On 10/23/2009 02:56 PM, David Goldsmith wrote:
The proper thing to do is file an "enhancement" ticket, at:
http://code.google.com/p/pydocweb/issues/list
Thanks.
DG
On Fri, Oct 23, 2009 at 9:13 AM, Michael Droettboom <mailto:md...@stsci.edu>&
On 10/23/2009 09:39 AM, Pauli Virtanen wrote:
> Fri, 23 Oct 2009 09:25:12 -0400, Michael Droettboom wrote:
>
>> Is there a way to use numpydoc without putting an autosummary table at
>> the head of each class? I'm using numpydoc primarily for the
>> sectioniz
Is there a way to use numpydoc without putting an autosummary table at
the head of each class? I'm using numpydoc primarily for the
sectionized docstring support, but the autosummaries are somewhat
overkill for my project.
Mike
___
NumPy-Discussion m
Sorry for the noise. Found the instructions in HOWTO_BUILD_DOCS.txt .
Mike
Michael Droettboom wrote:
> I'm in the process of converting a project to use Sphinx for
> documentation, and would like to use the Numpy docstring standard with
> its sections etc. It appears, how
for numpy? Or is
there a way for my project to use it that I'm missing?
Cheers,
Mike
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
___
NumPy-Dis
Thanks. It's passing the related unit tests on Sparc SunOS 5, and Linux
x86.
Cheers,
Mike
Charles R Harris wrote:
>
>
> On Tue, Oct 20, 2009 at 10:13 AM, Charles R Harris
> mailto:charlesr.har...@gmail.com>> wrote:
>
>
>
> On Tue, Oct 20,
eserve hard tabs when your editor
> uses spaces and has hard tabs set to 8 spaces. That file is on my
> cleanup list anyway, I'll try to get to it this weekend.
>
> Chuck
>
> --------
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
changed in npy_cpu.h if necessary.
Mike
Charles R Harris wrote:
>
>
> On Sun, Oct 18, 2009 at 6:04 AM, Michael Droettboom <mailto:md...@stsci.edu>> wrote:
>
> On 10/16/2009 11:35 PM, Travis Oliphant wrote:
> >
> > On Oct 15, 2009, at 11:40 AM, Micha
On 10/16/2009 11:35 PM, Travis Oliphant wrote:
>
> On Oct 15, 2009, at 11:40 AM, Michael Droettboom wrote:
>
>> I recently committed a regression test and bugfix for object pointers in
>> record arrays of unaligned size (meaning where each record is not a
>>
On 10/16/2009 07:53 AM, Pauli Virtanen wrote:
> Fri, 16 Oct 2009 12:07:10 +0200, Francesc Alted wrote:
> [clip]
>
>> IMO, NumPy can be improved for unaligned data handling. For example,
>> Numexpr is using this small snippet:
>>
>> from cpuinfo import cpu
>> if cpu.is_AMD() or cpu.is_Intel():
would affect regular numerical arrays.
If we choose not to fix it, perhaps we should we try to warn when
creating an unaligned recarray on platforms where it matters? I do
worry about having something that works perfectly well on one platform
fail on another.
In the meantime, I'll ju
The fix is in SVN r7530.
Mike
Michael Droettboom wrote:
> That's my bad. I will commit a fix to SVN shortly.
>
> Mike
>
> Nils Wagner wrote:
>
>> >>> numpy.__version__
>> '1.4.0.dev7528'
>>
>> =
--
> Ran 2277 tests in 18.933s
>
> FAILED (KNOWNFAIL=1, errors=1)
>
> _______
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
Thanks! I guess I won't file a bug then ;)
Mike
Travis Oliphant wrote:
> On Oct 7, 2009, at 10:28 AM, Michael Droettboom wrote:
>
>
>> I'm noticing an inconsistency as to how complex numbers are
>> byteswapped
>> as arrays vs. scalars, and w
>>> z = np.fromstring(y.tostring(), dtype='>c8')
>>> assert z[0] == -1j
Traceback (most recent call last):
File "", line 1, in
AssertionError
>>>
Any thoughts?
Mike
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
quires manual effort is if there are changes
> in the wiki and the object got moved in svn.
>
>
> And, as above, updating the status in the Wiki. :-)
>
> DG
>
>
> Cheers,
> Ralf
>
>
>
> DG
>
>
> On Wed, Sep 30, 2009 at
Ralf Gommers wrote:
>
>
> On Wed, Sep 30, 2009 at 9:03 AM, Michael Droettboom <mailto:md...@stsci.edu>> wrote:
>
> In the source in my working copy. Is that going to cause problems? I
> wasn't sure if it was possible to document methods that didn't
In the source in my working copy. Is that going to cause problems? I
wasn't sure if it was possible to document methods that didn't yet exist
in the code in the wiki.
Mike
David Goldsmith wrote:
> On Tue, Sep 29, 2009 at 10:55 AM, Michael Droettboom <mailto:md...@s
y ignores exception)
This bug probably needs review by someone deeply familiar with the
low-level internals, as it affects more than just string and unicode
arrays. It doesn't break any of the unit tests, for what it's worth ;)
Cheers,
Mike
David Goldsmith wrote:
> Great, thanks!
>
KeyError: 'numbered'
The full traceback has been saved in /tmp/sphinx-err-QYFjBP.log, if you
want to report the issue to the author.
Please also report this if it was a user error, so that a better error
message can be provided next time.
Send reports to sphinx-...@googlegroups.co
Ah, I missed the fact that Numpy unicode characters are always 4-bytes,
unlike Python unicode objects. Divide by 4 is easy enough. Sorry for
the noise.
Mike
Michael Droettboom wrote:
> Is there a way to get the number of characters in a fixed-size 'U'
> array? I can,
Is there a way to get the number of characters in a fixed-size 'U'
array? I can, of course, parse dtype.str, or divide dtype.itemsize by
the size of a unicode character, but neither seems terribly elegant or
future proof. Does numpy provide (to Python) a method for getting this
that I'm just
David Goldsmith wrote:
> On Tue, Sep 22, 2009 at 4:02 PM, Ralf Gommers
> mailto:ralf.gomm...@googlemail.com>> wrote:
>
>
> On Tue, Sep 22, 2009 at 1:58 PM, Michael Droettboom
> mailto:md...@stsci.edu>> wrote:
>
> Trac has these
I have filed a bug against this, along with a patch that fixes casting
to fixed-size string arrays:
http://projects.scipy.org/numpy/ticket/1235
Undefined-sized string arrays is a harder problem, which I'm deferring
for later.
Mike
On 09/24/2009 01:19 PM, Michael Droettboom wrote:
>
On 09/24/2009 01:02 PM, Christopher Barker wrote:
> Michael Droettboom wrote:
>
>> As I'm looking into fixing a number of bugs in chararray, I'm running
>> into some surprising behavior.
>> In [14]: x = np.array(['abcdefgh', 'ijklmnop'], &
As I'm looking into fixing a number of bugs in chararray, I'm running
into some surprising behavior. One of the things chararray needs to do
occasionally is build up an object array of string objects, and then
convert that back to a fixed-length string array. This length is
sometimes predeter
now what this means -- but I do find the fact that it's a
view class with methods a little bit clumsy. Is that what you meant?
So here's my TODO list related to all this:
1) Fix bugs in Trac
2) Improve documentation (though probably not in a method-by-method way)
Christopher Barker wrote:
> Michael Droettboom wrote:
>
>> The PSF will do the work of applying to Google -- we can encourage
>> prospective students and mentors to apply through the PSF.
>>
>
> hmmm -- I wonder if that is best -- it would put MPL projects in
--
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receiv
F8H
> ----
>
> ___
> Matplotlib-devel mailing list
> matplotlib-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
--
Michael
I've filed a bug, with a patch to address all these issues, here:
http://scipy.org/scipy/numpy/ticket/877
Cheers,
Mike
Michael Droettboom wrote:
> I also noticed that the inverse operation, PyArray_Item_INCREF has the
> potential to leak memory as it will doubly-increment each ob
ng the
objects twice when iterating through the fields dictionary.
Cheers,
Mike
Michael Droettboom wrote:
> I've run into a segfault that occurs in the array destructor with
> arrays containing object references with both names and titles.
>
> When a field contains both
:416
#5 0x08085a1e in _PyModule_Clear (m=0xb7f3e0ec) at Objects/moduleobject.c:136
#6 0x080d7138 in PyImport_Cleanup () at Python/import.c:439
#7 0x080e4343 in Py_Finalize () at Python/pythonrun.c:399
#8 0x08056633 in Py_Main (argc=1, argv=0xbff1ca24) at Modules/main.c:545
#9 0x08056323 in
__setitem__(self, indx, value)
1437 # raise IndexError, msg
1438 if isinstance(indx, basestring):
-> 1439 ndarray.__setitem__(self._data, indx, value)
1440 ndarray.__setitem__(self._mask, indx, getmask(value))
1441 return
: field named foo not found.
The included patch delegates the
on mailing list
> Numpy-discussion@scipy.org
> http://projects.scipy.org/mailman/listinfo/numpy-discussion
>
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
__
84 matches
Mail list logo
