On 2014/9/24 12:52, Charles R Harris wrote:
On Tue, Sep 23, 2014 at 10:30 PM, Charles R Harris
mailto:charlesr.har...@gmail.com>> wrote:
On Tue, Sep 23, 2014 at 10:20 PM, Charles R Harris
mailto:charlesr.har...@gmail.com>> wrote:
Looks like you need to do
>>> import numpy.f2py as
On Tue, Sep 23, 2014 at 10:30 PM, Charles R Harris <
charlesr.har...@gmail.com> wrote:
>
>
> On Tue, Sep 23, 2014 at 10:20 PM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>>
>>
>>
Looks like you need to do
>>> import numpy.f2py as f2py
>>> f2py.test()
To run tests with the redhat
On Tue, Sep 23, 2014 at 10:20 PM, Charles R Harris <
charlesr.har...@gmail.com> wrote:
>
>
> On Tue, Sep 23, 2014 at 9:21 PM, Romu Hu wrote:
>
>> Hi,
>>
>> I'm using python27-numpy-f2py-1.7.1-9.el6.x86_64 from RHEL6, the package
>> has a test directory
>> "/usr/lib64/python2.7/site-packages/numpy
On Tue, Sep 23, 2014 at 9:21 PM, Romu Hu wrote:
> Hi,
>
> I'm using python27-numpy-f2py-1.7.1-9.el6.x86_64 from RHEL6, the package
> has a test directory
> "/usr/lib64/python2.7/site-packages/numpy/f2py/tests", when I run
> unittest in the directory, all 358 testcases fail:
>
> # cd /usr/lib64/py
Hi,
I'm using python27-numpy-f2py-1.7.1-9.el6.x86_64 from RHEL6, the package
has a test directory
"/usr/lib64/python2.7/site-packages/numpy/f2py/tests", when I run
unittest in the directory, all 358 testcases fail:
# cd /usr/lib64/python2.7/site-packages/numpy/f2py/tests
# python27 -m unittest
On Tue, Sep 23, 2014 at 4:59 PM, Charles R Harris wrote:
> Hi All,
>
> The question has come up as the whether of not to treat the new gufunc
> behavior as a bug fix, keeping the old constructor name, or have a
> different constructor. Keeping the name makes life easier as we don't need
> to edit
Hi All,
The question has come up as the whether of not to treat the new gufunc
behavior as a bug fix, keeping the old constructor name, or have a
different constructor. Keeping the name makes life easier as we don't need
to edit the code where numpy currently uses gufuncs, but is risky if some
thi
Travis,
Thank you for your perspective on this issue. Such input is always valuable
in helping us see where we came from and where we might go.
My perspective on NumPy is fairly different, having come into Python right
after the whole Numeric/NumArray transition to NumPy. One of the things
that r
For the 0.15.0 release of pandas (coming 2nd week of oct), we are going to
include memory info printing:
see here: https://github.com/pydata/pandas/pull/7619
This will be controllable by an option display.memory_usage.
My question to the community should this be by default True, e.g. show the
me
On Sun, Sep 21, 2014 at 6:50 PM, Stephan Hoyer wrote:
> pandas has some hacks to support custom types of data for which numpy
> can't handle well enough or at all. Examples include datetime and
> Categorical [1], and others like GeoArray [2] that haven't make it into
> pandas yet.
>
> Most of the
On Tuesday, September 23, 2014, Todd wrote:
> On Mon, Sep 22, 2014 at 5:31 AM, Nathaniel Smith > wrote:
>
>> On Sun, Sep 21, 2014 at 7:50 PM, Stephan Hoyer > > wrote:
>> My feeling though is that in most of the cases you mention,
>> implementing a new array-like type is huge overkill. ndarray's
On Mon, Sep 22, 2014 at 5:31 AM, Nathaniel Smith wrote:
> On Sun, Sep 21, 2014 at 7:50 PM, Stephan Hoyer wrote:
> My feeling though is that in most of the cases you mention,
> implementing a new array-like type is huge overkill. ndarray's
> interface is vast and reimplementing even 90% of it is
On Mon, Sep 22, 2014 at 4:31 AM, Nathaniel Smith wrote:
> On Sun, Sep 21, 2014 at 7:50 PM, Stephan Hoyer wrote:
> > pandas has some hacks to support custom types of data for which numpy
> can't
> > handle well enough or at all. Examples include datetime and Categorical
> [1],
> > and others like
13 matches
Mail list logo
