>> In that case, would you agree that it is a bug for
>> assert_array_almost_equal to use repr() to display the arrays, since it
>> is printing identical values and saying they are different? Or is there
>> also a reason to do that?
>>
>
> It should probably use np.array_repr(x, precision=16
Robert Kern wrote:
> On Tue, Mar 15, 2011 at 12:39, Charles R Harris
> wrote:
>
>
>> Yes, I think it is a bug. IIRC, it also shows up for object arrays.
>>
>
> It's extremely long-standing, documented, intentional behavior dating
> back to Numeric.
>
> [~]
> |1> import Numeric
>
> [~]
> |2
The usual expectation is that (when possible) repr() returns a value
that you can eval() to get the original data back. But,
>>> from numpy import *
>>> a = array( [ 16.5069863163822 ] )
>>> b = eval(repr(a))
>>> a-b
array([ -3.6111e-09])
>>> import numpy.testing
>>> numpy.testing
>> 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
Hi,
I looked on the web site, but I couldn't find a list of python versions that
numpy expects to work on. Is the trunk still expected to work in Python 2.5 ?
I'm asking because it doesn't, but I don't want to file a bug report if it is
not expected to. The problem shows up when I run numpy.t
Robert Kern wrote:
> On Tue, Dec 8, 2009 at 15:36, Mark Sienkiewicz wrote:
>
>>
>> ( Presumably, some other version of gfortan does accept -arch, or this
>> code wouldn't be here, right? )
>>
>
> Right. The -arch flag was added by Apple to GCC and
When I compile scipy on a mac, the build fails with:
...
gfortran:f77: scipy/fftpack/src/dfftpack/dcosqb.f
f951: error: unrecognized command line option "-arch"
f951: error: unrecognized command line option "-arch"
f951: error: unrecognized command line option "-arch"
f951: error: unrecognized com
> In the source build folder, all numpy test scripts have the correct
> permissions and are not marked as executable,
>
> but in the install directory
> (/usr/local/lib/python2.6/dist-packages/numpy/), the test test scripts
> have completely different permissions, and are all marked as
> executabl
Robert Kern wrote:
> On Wed, Sep 23, 2009 at 10:52, Mark Sienkiewicz wrote:
>
>> I have discovered the hard way that numpy depends on openssl.
>>
>> I am building a 64 bit python environment for the macintosh. I
>> currently do not have a 64 bit openssl li
I have discovered the hard way that numpy depends on openssl.
I am building a 64 bit python environment for the macintosh. I
currently do not have a 64 bit openssl library installed, so the python
interpreter does not have hashlib. (hashlib gets its md5 function from
the openssl library.)
Th
I have this configuration:
numpy 1.3.0 rc1
Solaris 10
Python 2.5.4 compiled as a 64 bit executable
When I try to install numpy, it says:
C compiler: cc -DNDEBUG -O -xarch=native64 -xcode=pic32
compile options: '-Inumpy/core/src -Inumpy/core/include
-I/usr/stsci/Python-2.5.4/include/python2.5 -
Pauli Virtanen wrote:
>
> Probably they are both related to unspecified sort order for
> the duplicates. There were some sort-order ignoring missing in the test.
>
> I think the test is now fixed in trunk:
>
> http://projects.scipy.org/numpy/changeset/6827
>
The test passes in 1.4.0.dev68
>> ==
>> FAIL: Test find_duplicates
>> --
>> ...
>> AssertionError:
>> Arrays are not equal
>>
>> (mismatch 50.0%)
>> x: array([(1, (2.0, 'B')), (2, (2.0, 'B')),
Numpy 1.3.0 rc1 fails this self-test on Solaris.
==
FAIL: Test find_duplicates
--
Traceback (most recent call last):
File "/usr/ra/pyssg/2.5.1/numpy/lib/tests/
14 matches
Mail list logo
