>> 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
On Tue, Mar 15, 2011 at 13:10, Mark Sienkiewicz wrote:
> 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
>>
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
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> a = Numeric.array( [ 16.5069863163822 ] )
[~]
On Tue, Mar 15, 2011 at 10:20 AM, Mark Sienkiewicz wrote:
> 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
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
