On Fri, Jul 4, 2014 at 9:48 PM, Charles R Harris
wrote:
>
> On Fri, Jul 4, 2014 at 2:41 PM, Nathaniel Smith wrote:
>>
>> On Fri, Jul 4, 2014 at 9:33 PM, Charles R Harris
>> wrote:
>> >
>> > On Fri, Jul 4, 2014 at 2:09 PM, Nathaniel Smith wrote:
>> >>
>> >> On Fri, Jul 4, 2014 at 9:02 PM, Ralf G
On 10 Jun 2014 19:07, "Eric Firing" wrote:
>
> This is just a heads-up: some indexing changes in the numpy 1.9rc break
> matplotlib, as revealed in the mpl tests; there is a discussion on the
> numpy-discussion list about what to do about it. It looks like they
> will back off on the changes and
This is just a heads-up: some indexing changes in the numpy 1.9rc break
matplotlib, as revealed in the mpl tests; there is a discussion on the
numpy-discussion list about what to do about it. It looks like they
will back off on the changes and put in deprecations, giving us time to
modify mpl.
On Wed, Jul 3, 2013 at 3:13 PM, Derek Homeier <
de...@astro.physik.uni-goettingen.de> wrote:
>
> On 03.07.2013, at 10:03PM, Damon McDougall
> wrote:
>
> > On Tue, Jul 2, 2013 at 11:39 AM, Michael Droettboom
> wrote:
> > [Apologies for cross-posting]
> >
> > The matplotlib developers want to hear
On 03.07.2013, at 10:03PM, Damon McDougall wrote:
> On Tue, Jul 2, 2013 at 11:39 AM, Michael Droettboom wrote:
> [Apologies for cross-posting]
>
> The matplotlib developers want to hear from you!
>
> We are conducting a user survey to determine how and where matplotlib is
> being used in ord
On Tue, Jul 2, 2013 at 11:39 AM, Michael Droettboom wrote:
> [Apologies for cross-posting]
>
> The matplotlib developers want to hear from you!
>
> We are conducting a user survey to determine how and where matplotlib is
> being used in order to focus its further development.
>
> This should onl
>> We can't put python-matplotlib in main because of *its* dependencies.
>>
>
> As a digression, I think the python-matplotlib dependencies could be
> significantly reduced. For a number of use cases (this is one of them,
> but there are others), you don't need any GUI backend. Independent of
On Feb 11, 2011, at 05:18 PM, Jouni K. Seppänen wrote:
>[Crossposting to matplotlib devel list]
>
>Robert Kern writes:
>
>> On Thu, Feb 10, 2011 at 11:22, Barry Warsaw wrote:
>>
>>> Here's the problem: for Ubuntu, we've had to disable the building of
>>> the numpy documentation package, because
On Friday, February 11, 2011, Benjamin Root wrote:
> On Friday, February 11, 2011, Jouni K. Seppänen wrote:
>> [Crossposting to matplotlib devel list]
>>
>> Robert Kern writes:
>>
>>> On Thu, Feb 10, 2011 at 11:22, Barry Warsaw wrote:
>>>
Here's the problem: for Ubuntu, we've had to disabl
On Friday, February 11, 2011, Jouni K. Seppänen wrote:
> [Crossposting to matplotlib devel list]
>
> Robert Kern writes:
>
>> On Thu, Feb 10, 2011 at 11:22, Barry Warsaw wrote:
>>
>>> Here's the problem: for Ubuntu, we've had to disable the building of
>>> the numpy documentation package, becaus
On 2010-02-18 16:18 PM, David Warde-Farley wrote:
> Just noticed this when I tried to build (I have numpy from svn):
>
> REQUIRED DEPENDENCIES
> * numpy 1.1 or later is required; you have
> * 2.0.0.dev8125
>
> :)
This has been fixed in SVN.
--
Just noticed this when I tried to build (I have numpy from svn):
REQUIRED DEPENDENCIES
* numpy 1.1 or later is required; you have
* 2.0.0.dev8125
:)
--
Download Intel® Pa
2010/1/25 Nicolas Rougier :
>
>
> Hello,
>
> This is an update about glumpy, a fast-OpenGL based numpy visualization.
> I modified the code such that the only dependencies are PyOpenGL and
> IPython (for interactive sessions). You will also need matplotlib and
> scipy for some demos.
>
> Sources: h
On Mon, Jan 4, 2010 at 5:48 PM, Dag Sverre Seljebotn
wrote:
>
> Rolling this into the Python package distribution scheme seems backwards
> though, since a lot of binary packages that have nothing to do with Python
> are used as well
Yep, exactly.
>
> To solve the exact problem you (and me) have
Nathaniel Smith wrote:
> On Sun, Jan 3, 2010 at 4:23 AM, David Cournapeau
> wrote:
>> Another way is to provide our own repository for a few major
>> distributions, with automatically built packages. This is how most
>> open source providers work. Miguel de Icaza explains this well:
>>
>> http://
On Mon, Jan 4, 2010 at 8:42 AM, Nathaniel Smith wrote:
> On Sun, Jan 3, 2010 at 4:23 AM, David Cournapeau wrote:
>> On Sun, Jan 3, 2010 at 8:05 PM, Nathaniel Smith wrote:
>>> What I do -- and documented for people in my lab to do -- is set up
>>> one virtualenv in my user account, and use it as
On Sun, Jan 3, 2010 at 4:23 AM, David Cournapeau wrote:
> On Sun, Jan 3, 2010 at 8:05 PM, Nathaniel Smith wrote:
>> What I do -- and documented for people in my lab to do -- is set up
>> one virtualenv in my user account, and use it as my default python. (I
>> 'activate' it from my login scripts.
On Sun, Jan 3, 2010 at 8:05 PM, Nathaniel Smith wrote:
> On Tue, Dec 29, 2009 at 6:34 AM, David Cournapeau wrote:
>> Buildout, virtualenv all work by sandboxing from the system python:
>> each of them do not see each other, which may be useful for
>> development, but as a deployment solution to t
On Tue, Dec 29, 2009 at 6:34 AM, David Cournapeau wrote:
> Buildout, virtualenv all work by sandboxing from the system python:
> each of them do not see each other, which may be useful for
> development, but as a deployment solution to the casual user who may
> not be familiar with python, it is u
On Sun, Jan 03, 2010 at 03:05:54AM -0800, Nathaniel Smith wrote:
> What I do -- and documented for people in my lab to do -- is set up
> one virtualenv in my user account, and use it as my default python. (I
> 'activate' it from my login scripts.) The advantage of this is that
> easy_install (or pi
David wrote:
> Repository
>
>
> The goal here is to have something like CRAN
> (http://cran.r-project.org/web/views/), ideally with a build farm so
> that whenever anyone submits a package to our repository, it would
> automatically be checked, and built for windows/mac os x and maybe a
>
On Sat, Jan 02, 2010 at 11:32:00AM +0900, David Cournapeau wrote:
> [snip]
> - supporting different variants of the same package in the
> dependency graph at install time
> [snip]
> The second issue is more challenging. It complicates the dependency
> handling quite a bit, and may cause difficu
Hi David,
Following your announcement for the 'toydist' module, I think that
your project is very promising: this is certainly a great idea and it
will be very controversial but that's because people expectactions are
great on this matter (distutils is so disappointing indeed).
Anyway, if I may b
On Wed, Dec 30, 2009 at 11:26 PM, Darren Dale wrote:
> Hi David,
>
> On Mon, Dec 28, 2009 at 9:03 AM, David Cournapeau wrote:
>> Executable: grin
>> module: grin
>> function: grin_main
>>
>> Executable: grind
>> module: grin
>> function: grind_main
>
> Have you thought at all about op
On Wed, Dec 30, 2009 at 11:26 PM, Darren Dale wrote:
> Hi David,
>
> On Mon, Dec 28, 2009 at 9:03 AM, David Cournapeau wrote:
>> Executable: grin
>> module: grin
>> function: grin_main
>>
>> Executable: grind
>> module: grin
>> function: grind_main
>
> Have you thought at all about op
On Wed, Dec 30, 2009 at 8:15 PM, René Dudfield wrote:
>
> Sitting down with Tarek(who is one of the current distutils
> maintainers) in Berlin we had a little discussion about packaging over
> pizza and beer... and he was quite mindful of OS packagers problems
> and issues.
This has been said ma
Hi David,
On Mon, Dec 28, 2009 at 9:03 AM, David Cournapeau wrote:
> Executable: grin
> module: grin
> function: grin_main
>
> Executable: grind
> module: grin
> function: grind_main
Have you thought at all about operations that are currently performed
by post-installation scripts? F
On Wed, Dec 30, 2009 at 3:36 AM, René Dudfield wrote:
> On Tue, Dec 29, 2009 at 2:34 PM, David Cournapeau wrote:
>> On Tue, Dec 29, 2009 at 10:27 PM, René Dudfield wrote:
>>
>>> Buildout is what a lot of the python community are using now.
>>
>> I would like to note that buildout is a solution t
David Cournapeau wrote:
> Buildout, virtualenv all work by sandboxing from the system python:
> each of them do not see each other, which may be useful for
> development,
And certain kinds of deployment, like web servers or installed tools.
> but as a deployment solution to the casual user who m
On Tue, Dec 29, 2009 at 11:34:44PM +0900, David Cournapeau wrote:
> Buildout, virtualenv all work by sandboxing from the system python:
> each of them do not see each other, which may be useful for
> development, but as a deployment solution to the casual user who may
> not be familiar with python,
On Tue, Dec 29, 2009 at 10:27 PM, René Dudfield wrote:
> Buildout is what a lot of the python community are using now.
I would like to note that buildout is a solution to a problem that I
don't care to solve. This issue is particularly difficult to explain
to people accustomed with buildout in m
On Tue, Dec 29, 2009 at 10:27 PM, René Dudfield wrote:
> Hi,
>
> In the toydist proposal/release notes, I would address 'what does
> toydist do better' more explicitly.
>
>
>
> A big problem for science users is that numpy does not work with
> pypi + (easy_install, buildout or pip) and python
On Tue, Dec 29, 2009 at 3:49 AM, Dag Sverre Seljebotn
wrote:
>
> Do you here mean automatic generation of Ubuntu debs, Debian debs, Windows
> MSI installer, Windows EXE installer, and so on? (If so then great!)
Yes (although this is not yet implemented). In particular on windows,
I want to imple
On 19-Nov-09, at 5:36 PM, Scot Denhalter wrote:
> On Thu, Nov 19, 2009 at 2:46 PM, Eric Firing
> wrote:
>>
>> You don't need a fortran compiler for numpy, even if you are building
>> from source; and you probably don't need to build from source. Did
>> you
>> try the suggested binary package
A humble suggestion--for the March meeting of the american physical society,
there is a roommate finder for splitting hotel rooms. This could be useful
in keeping expenses down for some. There should be a way to do it without
liability
Cheers,
William
On Wed, Jul 15, 2009 at 10:13 PM, Gael V
Mon, 16 Feb 2009 13:36:07 -0600, Robert Kern wrote:
[clip]
> At one point, some of us had a plan to keep all of these "scientific"
> extensions collected here:
>
> http://sphinx.googlecode.com/svn/contrib/trunk/numpyext/
>
> SVN-using projects could use svn:externals to include these in their
>
On Sun, Feb 15, 2009 at 08:04, Gael Varoquaux
wrote:
> Hi all,
>
> Sorry for the multiple posting, this concerns various groups, and I'd
> rather the information not be lost.
>
> While working on getting our in-lab library ready to be merged with NiPy,
> I ran into some sort of 'sphinx extension m
Hmm, I tried "svnmerge.py avail" from the branch after committing to the
trunk. I see now that I should have committed to the branch first (which
seems an inversion to me). Duly noted for the future, though.
Still working on seamless git-svn and svnmerge.py integration,
Andrew
John Hunter wrote:
On Fri, Jan 16, 2009 at 12:38 PM, Andrew Straw wrote:
> John Hunter wrote:
>> Andrew, since you are the original author of the isnan port, could you
>> patch the branch and the trunk to take care of this?
>
> Done in r6791 and r6792.
>
> Sorry for the trouble.
>
> Now I just hope we don't get a pr
John Hunter wrote:
> Andrew, since you are the original author of the isnan port, could you
> patch the branch and the trunk to take care of this?
Done in r6791 and r6792.
Sorry for the trouble.
Now I just hope we don't get a problem with "long long", although now if
_ISOC99_SOURCE is defined, w
Manuel Metz wrote:
>x = np.asarray(x).astype(np.float32)
>x = np.zeros( x, np.float_ )
>x = np.ones((col,), float)
>
> Is there a preferred one to stick to ?!
Michael Droettboom wrote:
> x = np.asarray(x, np.float_)
I'd vote for:
x = np.asarray(x, np.float)
It ends up resulting i
On Thu, Jun 12, 2008 at 8:20 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
>> Both `np.float_` and the Python `float` are interpreted as
>> `np.float64`. The only time you really need something other than
>> `float` is if you require a width other than 64 (like in the first
>> line you showed
This suggests that maybe the first line is a buglet (without any real
consequence), since there happens to be no good reason to require that
array to be single precision. I think it's reasonable to say that we
should use double precision (float/float_/float64) everywhere floating
point is need
2008/6/12 Manuel Metz <[EMAIL PROTECTED]>:
> When looking, e.g. at axes.py, I see 3 different arguments passed to
> numpy astype()/array()/zero() and friends:
>
> x = np.asarray(x).astype(np.float32)
> x = np.zeros( x, np.float_ )
> x = np.ones((col,), float)
>
> Is there a preferred one to s
When looking, e.g. at axes.py, I see 3 different arguments passed to
numpy astype()/array()/zero() and friends:
x = np.asarray(x).astype(np.float32)
x = np.zeros( x, np.float_ )
x = np.ones((col,), float)
Is there a preferred one to stick to ?!
Manuel
---
Eric Firing wrote:
> Manuel Metz wrote:
>> Hi,
>>while adding the step-histogram I learned about the change of
>> numpy.histogram. As MPL trunk relies in numpy 1.1, I think its a good
>> idea to switch to the new histogram, i.e. use "new=True". Indeed, this
>> is required to be able to allow
Manuel Metz wrote:
> Hi,
>while adding the step-histogram I learned about the change of
> numpy.histogram. As MPL trunk relies in numpy 1.1, I think its a good
> idea to switch to the new histogram, i.e. use "new=True". Indeed, this
> is required to be able to allow to give bin-edges, which
Here's the link to the numpy wiki:
http://projects.scipy.org/scipy/numpy/roadmap#Semanticchangeforhistogram
Manuel Metz wrote:
> Hi,
>while adding the step-histogram I learned about the change of
> numpy.histogram. As MPL trunk relies in numpy 1.1, I think its a good
> idea to switch to the
Hi,
while adding the step-histogram I learned about the change of
numpy.histogram. As MPL trunk relies in numpy 1.1, I think its a good
idea to switch to the new histogram, i.e. use "new=True". Indeed, this
is required to be able to allow to give bin-edges, which is possible
with MPL 0.91.
This is inherent; mpl 0.90.1 is permanently incompatible with numpy 1.1,
short of each user making the change suggested below. The earliest mpl
that should work with numpy 1.1 is 0.91.2.
The change in masked array module is a major reason why numpy is getting
a version bump to 1.1.0 instead of
I will forward it to the matplotlib-devel mailing list on your behalf.
Cheers,
Mike
lorenzo bolla wrote:
> Hello,
>
> the latest svn numpy version 1.1.0.dev5061 does not work with
> matplotlib 0.90.1 (version shipped with enthought distribution),
> unless a change in
> Python25/Lib/site-packag
I have made changes in matplotlib svn to facilitate experimentation with
the maskedarray module; I hope this will speed up the process of testing
it and incorporating it into numpy as a replacement for numpy.core.ma.
mpl scripts now accept the switches --maskedarray and --ma to force the
use of
Pierre GM wrote:
[...]
>
> David, I wouldn't speak about compatibility, just about bugs: the problem was
> in the implementation of .max() w/ maskedarray. The origin of the problem was
> (is still) in umath.maximum.reduce that doesn't accept axis=None, so a numpy
> problem ;). But I agree: swit
On 2/15/07, Robert Kern <[EMAIL PROTECTED]> wrote:
> On 2/15/07, Keir Mierle <[EMAIL PROTECTED]> wrote:
> > On the DocstringStandard page I have also put a completely re-done docstring
> > for the 'contour' function from matplotlib. I think it is far more readable
> > than the original [3]. JDH and
> "Steven" == Steven Chaplin <[EMAIL PROTECTED]> writes:
Steven> Does mpl only work with specific versions of numpy?
Steven> Should mpl check for a required version and report an
Steven> error if its not there?
numpy has been a bit of a moving target of late, and typically the
la
When using the latest matplotlib from svn and numpy version 0.9.6 I get:
$ ./simple_plot.py
Traceback (most recent call last):
File "./simple_plot.py", line 6, in ?
from pylab import *
File "/usr/lib/python2.4/site-packages/pylab.py", line 1, in ?
from matplotlib.pylab import *
File
John Hunter wrote:
>>"Eric" == Eric Firing <[EMAIL PROTECTED]> writes:
>>
>>
>
>Eric> Correction: I did fix the first problem, and the second
>Eric> problem is not at all what I thought. Instead, the
>Eric> examples/data/lena.jpg file in my svn mpl directory is
On 7/11/06, John Hunter <[EMAIL PROTECTED]> wrote:
> > "Eric" == Eric Firing <[EMAIL PROTECTED]> writes:
>
> Eric> Correction: I did fix the first problem, and the second
> Eric> problem is not at all what I thought. Instead, the
> Eric> examples/data/lena.jpg file in my svn mpl di
> "Eric" == Eric Firing <[EMAIL PROTECTED]> writes:
Eric> Correction: I did fix the first problem, and the second
Eric> problem is not at all what I thought. Instead, the
Eric> examples/data/lena.jpg file in my svn mpl directory is
Eric> corrupted. I have no idea why. Lookin
Eric Firing wrote:
> Andrew Straw wrote:
>
>
>>Actually, this has been in MPL for a while. For example, see the
>>image_demo3.py example. You don't need the __array_interface__ for this
>>bit of functionality.
>
>
> It's broken.
>
> The first problem is that the kw "aspect = 'preserve'" is no
With the latest svn matplotlib and numpy 0.9.8 I'm now getting:
Python 2.4.3 (#1, Mar 30 2006, 13:31:07)
[GCC 4.0.1 (Apple Computer, Inc. build 5247)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import pylab
Traceback (most recent call last):
File "", l
61 matches
Mail list logo
