Re: [Numpy-discussion] array_equal too strict?

[Chris Barker - NOAA Federal]

> If you have some spare cycles, maybe you can open a pull request to add
> np.isclose to the "See Also" section?

That would be great.

Remember that equality for flits is bit-for but equality ( baring NaN
and inf...).

But you hardly ever actually want to do that with floats.

But probably np.allclose is most appropriate here.

CHB

>
> - Sebastian
>
>
>> ```
>> print(numpy.array_equal(a1, a2))
>>
>> # output: true
>> ```
>> That's expected because the difference is only in the 18th overall
>> digit, and the mantissa length of float64 is 52 bits [1], i.e., approx
>> 15.6 decimal digits. Moving the difference to the 17th overall digit
>> should also be fine, however:
>> ```
>> a1 = numpy.array(
>>[3.1415926535897930],
>>dtype=numpy.float64
>>)
>> a2 = numpy.array(
>>[3.1415926535897939],
>>dtype=numpy.float64
>>)
>>
>>
>> print(numpy.array_equal(a1, a2))
>> # output: false
>> ```
>> It gets even more visible with float32 and its 23 mantissa bits (i.e.,
>> 6.9 decimal digits):
>> ```
>> a1 = numpy.array(
>>[3.14159260],
>>dtype=numpy.float32
>>)
>> a2 = numpy.array(
>>[3.14159269],
>>dtype=numpy.float32
>>)
>>
>>
>> print(numpy.array_equal(a1, a2))
>> # output: false
>> ```
>> The difference is only in the 9th decimal digit, still `array_equal_
>> detects the difference.
>>
>>
>> I'm not sure where I'm going wrong here. Any hints?
>>
>>
>> Cheers,
>> Nico
>>
>>
>>
>>
>> [1] https://docs.scipy.org/doc/numpy-1.10.1/user/basics.types.html
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org
>> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] A minor clarification no why count_nonzero is faster for boolean arrays

[Raghav R V]

Thanks a lot everyone!

I am time and again amazed by how optimized numpy is! Hats off to you guys!

R

On Thu, Dec 17, 2015 at 11:02 PM, Jaime Fernández del Río <
jaime.f...@gmail.com> wrote:

> On Thu, Dec 17, 2015 at 7:37 PM, CJ Carey 
> wrote:
>
>> I believe this line is the reason:
>>
>> https://github.com/numpy/numpy/blob/c0e48cfbbdef9cca954b0c4edd0052e1ec8a30aa/numpy/core/src/multiarray/item_selection.c#L2110
>>
>
> The magic actually happens in  count_nonzero_bytes_384, a few lines
> before that (line 1986).
>
> Jaime
>
> --
> (\__/)
> ( O.o)
> ( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes
> de dominación mundial.
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] A minor clarification no why count_nonzero is faster for boolean arrays

[Jaime Fernández del Río]

On Thu, Dec 17, 2015 at 7:37 PM, CJ Carey  wrote:

> I believe this line is the reason:
>
> https://github.com/numpy/numpy/blob/c0e48cfbbdef9cca954b0c4edd0052e1ec8a30aa/numpy/core/src/multiarray/item_selection.c#L2110
>

The magic actually happens in  count_nonzero_bytes_384, a few lines before
that (line 1986).

Jaime

-- 
(\__/)
( O.o)
( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes
de dominación mundial.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] performance solving system of equations in numpy and MATLAB

[Edward Richards]

Thanks everyone for helping me glimpse the secret world of FORTRAN 
compilers. I am running a Linux machine, so I will look into MKL and 
openBLAS. It was easy for me to get a Intel parallel studio XE license 
as a student, so I have options.

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] A minor clarification no why count_nonzero is faster for boolean arrays

[Benjamin Root]

Would it make sense to at all to bring that optimization to np.sum()? I
know that I have np.sum() all over the place instead of count_nonzero,
partly because it is a MatLab-ism and partly because it is easier to write.
I had no clue that there was a performance difference.

Cheers!
Ben Root


On Thu, Dec 17, 2015 at 1:37 PM, CJ Carey  wrote:

> I believe this line is the reason:
>
> https://github.com/numpy/numpy/blob/c0e48cfbbdef9cca954b0c4edd0052e1ec8a30aa/numpy/core/src/multiarray/item_selection.c#L2110
>
> On Thu, Dec 17, 2015 at 11:52 AM, Raghav R V  wrote:
>
>> I was just playing with `count_nonzero` and found it to be significantly
>> faster for boolean arrays compared to integer arrays
>>
>>
>> >>> a = np.random.randint(0, 2, (100, 5))
>> >>> a_bool = a.astype(bool)
>>
>> >>> %timeit np.sum(a)
>> 10 loops, best of 3: 5.64 µs per loop
>>
>> >>> %timeit np.count_nonzero(a)
>> 100 loops, best of 3: 1.42 us per loop
>>
>> >>> %timeit np.count_nonzero(a_bool)
>> 100 loops, best of 3: 279 ns per loop (but why?)
>>
>> I tried looking into the code and dug my way through to this line
>> .
>> I am unable to dig further.
>>
>> I know this is probably a trivial question, but was wondering if anyone
>> could provide insight on why this is so?
>>
>> Thanks
>>
>> R
>>
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org
>> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] A minor clarification no why count_nonzero is faster for boolean arrays

[CJ Carey]

I believe this line is the reason:
https://github.com/numpy/numpy/blob/c0e48cfbbdef9cca954b0c4edd0052e1ec8a30aa/numpy/core/src/multiarray/item_selection.c#L2110

On Thu, Dec 17, 2015 at 11:52 AM, Raghav R V  wrote:

> I was just playing with `count_nonzero` and found it to be significantly
> faster for boolean arrays compared to integer arrays
>
>
> >>> a = np.random.randint(0, 2, (100, 5))
> >>> a_bool = a.astype(bool)
>
> >>> %timeit np.sum(a)
> 10 loops, best of 3: 5.64 µs per loop
>
> >>> %timeit np.count_nonzero(a)
> 100 loops, best of 3: 1.42 us per loop
>
> >>> %timeit np.count_nonzero(a_bool)
> 100 loops, best of 3: 279 ns per loop (but why?)
>
> I tried looking into the code and dug my way through to this line
> .
> I am unable to dig further.
>
> I know this is probably a trivial question, but was wondering if anyone
> could provide insight on why this is so?
>
> Thanks
>
> R
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] performance solving system of equations in numpy and MATLAB

[Gregory Lee]

Hi,

I just ran both on the same hardware and got a slightly faster computation
with numpy:

Matlab R2012a:  16.78 s  (best of 3)
numpy (python 3.4, numpy 1.10.1, anaconda accelerate (MKL)):  14.8 s  (best
of 3)

The difference could because my Matlab version is a few years old, so it's
MKL would be less up to date.

Greg

On Thu, Dec 17, 2015 at 9:29 AM, Andy Ray Terrel 
wrote:

>
>
> On Thu, Dec 17, 2015 at 5:52 AM, Sturla Molden 
> wrote:
>
>> On 17/12/15 12:06, Francesc Alted wrote:
>>
>> Pretty good.  I did not know that OpenBLAS was so close in performance
>>> to MKL.
>>>
>>
>> MKL, OpenBLAS and Accelerate are very close in performance, except for
>> level-1 BLAS where Accelerate and MKL are better than OpenBLAS.
>>
>> MKL requires the number of threads to be a multiple of four to achieve
>> good performance, OpenBLAS and Accelerate do not. It e.g. matters if you
>> have an online data acquisition and DSP system and want to dedicate one
>> processor to take care of i/o tasks. In this case OpenBLAS and Accelerate
>> are likely to perform better than MKL.
>>
>>
> The last time I benchmarked them MKL was much better at tall skinny
> matrices.
>
>
>>
>> Sturla
>>
>>
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org
>> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] A minor clarification no why count_nonzero is faster for boolean arrays

[Raghav R V]

I was just playing with `count_nonzero` and found it to be significantly
faster for boolean arrays compared to integer arrays


>>> a = np.random.randint(0, 2, (100, 5))
>>> a_bool = a.astype(bool)

>>> %timeit np.sum(a)
10 loops, best of 3: 5.64 µs per loop

>>> %timeit np.count_nonzero(a)
100 loops, best of 3: 1.42 us per loop

>>> %timeit np.count_nonzero(a_bool)
100 loops, best of 3: 279 ns per loop (but why?)

I tried looking into the code and dug my way through to this line
.
I am unable to dig further.

I know this is probably a trivial question, but was wondering if anyone
could provide insight on why this is so?

Thanks

R
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] performance solving system of equations in numpy and MATLAB

[Andy Ray Terrel]

On Thu, Dec 17, 2015 at 5:52 AM, Sturla Molden 
wrote:

> On 17/12/15 12:06, Francesc Alted wrote:
>
> Pretty good.  I did not know that OpenBLAS was so close in performance
>> to MKL.
>>
>
> MKL, OpenBLAS and Accelerate are very close in performance, except for
> level-1 BLAS where Accelerate and MKL are better than OpenBLAS.
>
> MKL requires the number of threads to be a multiple of four to achieve
> good performance, OpenBLAS and Accelerate do not. It e.g. matters if you
> have an online data acquisition and DSP system and want to dedicate one
> processor to take care of i/o tasks. In this case OpenBLAS and Accelerate
> are likely to perform better than MKL.
>
>
The last time I benchmarked them MKL was much better at tall skinny
matrices.


>
> Sturla
>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] array_equal too strict?

[Sebastian Berg]

On Do, 2015-12-17 at 13:43 +, Nico Schlömer wrote:
> Hi everyone,
> 
> 
> I noticed a funny behavior in numpy's array_equal. The two arrays
> ```
> a1 = numpy.array(
> [3.14159265358979320],
> dtype=numpy.float64
> )
> a2 = numpy.array(
> [3.14159265358979329],
> dtype=numpy.float64
> )
> ```
> (differing the in the 18th overall digit) are reported equal by
> array_equal:

If you have some spare cycles, maybe you can open a pull request to add
np.isclose to the "See Also" section?

- Sebastian


> ```
> print(numpy.array_equal(a1, a2))
> 
> # output: true
> ```
> That's expected because the difference is only in the 18th overall
> digit, and the mantissa length of float64 is 52 bits [1], i.e., approx
> 15.6 decimal digits. Moving the difference to the 17th overall digit
> should also be fine, however:
> ```
> a1 = numpy.array(
> [3.1415926535897930],
> dtype=numpy.float64
> )
> a2 = numpy.array(
> [3.1415926535897939],
> dtype=numpy.float64
> )
> 
> 
> print(numpy.array_equal(a1, a2))
> # output: false
> ```
> It gets even more visible with float32 and its 23 mantissa bits (i.e.,
> 6.9 decimal digits):
> ```
> a1 = numpy.array(
> [3.14159260],
> dtype=numpy.float32
> )
> a2 = numpy.array(
> [3.14159269],
> dtype=numpy.float32
> )
> 
> 
> print(numpy.array_equal(a1, a2))
> # output: false
> ```
> The difference is only in the 9th decimal digit, still `array_equal_
> detects the difference.
> 
> 
> I'm not sure where I'm going wrong here. Any hints?
> 
> 
> Cheers,
> Nico
> 
> 
> 
> 
> [1] https://docs.scipy.org/doc/numpy-1.10.1/user/basics.types.html
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion



signature.asc
Description: This is a digitally signed message part
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] array_equal too strict?

[Daπid]

On 17 December 2015 at 14:43, Nico Schlömer 
wrote:

> I'm not sure where I'm going wrong here. Any hints?


You are dancing around the boundary between close floating point numbers,
and when you are dealing with ULPs, number of decimal places is a bad
measure. Working with plain numbers, instead of arrays (just so that the
numbers are printed in full detail)

a1 = np.float64(3.1415926535897930)
a2 = np.float64(3.1415926535897939)

They are numerically different:
a2 - a1
8.8817841970012523e-16

In epsilons (defined as the smallest number such that (1 + eps) - 1 > 0):
(a2 - a1) / np.finfo(np.float64).eps
4.0

In fact, there is one number in between, two epsilons away from each one:
np.nextafter(a1, a2)
3.1415926535897936

np.nextafter(np.nextafter(a1, 10), 10) - a2
0.0

The next number on the other side:
np.nextafter(a1, 0)
3.1415926535897927

For more information:

print np.finfo(np.float64)
Machine parameters for float64
---
precision= 15   resolution= 1.0001e-15
machep=   -52   eps=2.2204460492503131e-16
negep =   -53   epsneg= 1.1102230246251565e-16
minexp= -1022   tiny=   2.2250738585072014e-308
maxexp=  1024   max=1.7976931348623157e+308
nexp  =11   min=-max
---


/David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] array_equal too strict?

[Nico Schlömer]

Hi everyone,

I noticed a funny behavior in numpy's array_equal. The two arrays
```
a1 = numpy.array(
[3.14159265358979320],
dtype=numpy.float64
)
a2 = numpy.array(
[3.14159265358979329],
dtype=numpy.float64
)
```
(differing the in the 18th overall digit) are reported equal by array_equal:
```
print(numpy.array_equal(a1, a2))
# output: true
```
That's expected because the difference is only in the 18th overall digit,
and the mantissa length of float64 is 52 bits [1], i.e., approx 15.6
decimal digits. Moving the difference to the 17th overall digit should also
be fine, however:
```
a1 = numpy.array(
[3.1415926535897930],
dtype=numpy.float64
)
a2 = numpy.array(
[3.1415926535897939],
dtype=numpy.float64
)

print(numpy.array_equal(a1, a2))
# output: false
```
It gets even more visible with float32 and its 23 mantissa bits (i.e., 6.9
decimal digits):
```
a1 = numpy.array(
[3.14159260],
dtype=numpy.float32
)
a2 = numpy.array(
[3.14159269],
dtype=numpy.float32
)

print(numpy.array_equal(a1, a2))
# output: false
```
The difference is only in the 9th decimal digit, still `array_equal_
detects the difference.

I'm not sure where I'm going wrong here. Any hints?

Cheers,
Nico


[1] https://docs.scipy.org/doc/numpy-1.10.1/user/basics.types.html
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] performance solving system of equations in numpy and MATLAB

[Sturla Molden]

On 16/12/15 20:47, Derek Homeier wrote:


Getting around 30 s wall time here on a not so recent 4-core iMac, so that 
would seem to fit
(iirc Accelerate should actually largely be using the same machine code as MKL).


Yes, the same kernels, but not the same threadpool. Accelerate uses the 
GCD, MKL uses Intel TBB and Intel OpenMP (both of them). GCD scales 
better than TBB, even in Intel's own benchmarks. However, GCD uses a 
kernel threadpool (accesible via kqueue) which is not fork-safe, whereas 
MKL's threadpool is fork-safe (but will leak memory on fork).


Sturla




___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] performance solving system of equations in numpy and MATLAB

[Sturla Molden]

On 17/12/15 12:06, Francesc Alted wrote:


Pretty good.  I did not know that OpenBLAS was so close in performance
to MKL.


MKL, OpenBLAS and Accelerate are very close in performance, except for 
level-1 BLAS where Accelerate and MKL are better than OpenBLAS.


MKL requires the number of threads to be a multiple of four to achieve 
good performance, OpenBLAS and Accelerate do not. It e.g. matters if you 
have an online data acquisition and DSP system and want to dedicate one 
processor to take care of i/o tasks. In this case OpenBLAS and 
Accelerate are likely to perform better than MKL.



Sturla

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] performance solving system of equations in numpy and MATLAB

[Francesc Alted]

2015-12-17 12:00 GMT+01:00 Daπid :

> On 16 December 2015 at 18:59, Francesc Alted  wrote:
>
>> Probably MATLAB is shipping with Intel MKL enabled, which probably is the
>> fastest LAPACK implementation out there.  NumPy supports linking with MKL,
>> and actually Anaconda does that by default, so switching to Anaconda would
>> be a good option for you.
>
>
> A free alternative is OpenBLAS. I am getting 20 s in an i7 Haswell with 8
> cores.
>

Pretty good.  I did not know that OpenBLAS was so close in performance to
MKL.

-- 
Francesc Alted
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] performance solving system of equations in numpy and MATLAB

[Daπid]

On 16 December 2015 at 18:59, Francesc Alted  wrote:

> Probably MATLAB is shipping with Intel MKL enabled, which probably is the
> fastest LAPACK implementation out there.  NumPy supports linking with MKL,
> and actually Anaconda does that by default, so switching to Anaconda would
> be a good option for you.


A free alternative is OpenBLAS. I am getting 20 s in an i7 Haswell with 8
cores.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion