Travis Oliphant | 8 Oct 01:32 2014

Re: Copyright status of NumPy binaries on Windows/OS X

Hey Andrew, 

You can use any of the binaries from Anaconda and redistribute them as long as you "cite" Anaconda --- i.e. tell your users that they are using Anaconda-derived binaries.     The Anaconda binaries link against ATLAS.    

The binaries are all at http://repo.continuum.io/pkgs/ 

In case you weren't aware: 

Another way you can build and distribute an "application" is to build a 'conda' meta-package which lists all the dependencies.   If you add to this meta-package 1) an icon and 2) an entry-point, then your application will automatically show up in the "Anaconda Launcher" (see this blog-post:  http://www.continuum.io/blog/new-launcher ) and anyone with the Anaconda Launcher app can install/update your package by clicking on the icon next to it.  

Users can also install your package with conda install or using the conda-gui.  

Best,

-Travis


On Mon, Oct 6, 2014 at 11:54 AM, Andrew Collette <andrew.collette <at> gmail.com> wrote:
Hi all,

I am working with the HDF Group on a new open-source viewer program
for HDF5 files, powered by NumPy, h5py, and wxPython.  On Windows,
since people don't typically have Python installed, we are looking to
distribute the application using PyInstaller, which embeds
dependencies like NumPy.  Likewise for OS X (using Py2App).

We would like to make sure we don't accidentally include
non-open-source components... I recall there was some discussion here
about using the Intel math libraries for binary releases on various
platforms.  Do the releases on SourceForge or PyPI use any proprietary
code?  We'd like to avoid building NumPy ourselves if we can avoid it.

Apologies if this is explained somewhere, but I couldn't find it.

Thanks!
Andrew Collette
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion <at> scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion



--

Travis Oliphant
CEO
Continuum Analytics, Inc.
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion <at> scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Julian Taylor | 7 Oct 23:13 2014

Re: Copyright status of NumPy binaries on Windows/OS X

On 06.10.2014 18:54, Andrew Collette wrote:
> Hi all,
> 
> I am working with the HDF Group on a new open-source viewer program
> for HDF5 files, powered by NumPy, h5py, and wxPython.  On Windows,
> since people don't typically have Python installed, we are looking to
> distribute the application using PyInstaller, which embeds
> dependencies like NumPy.  Likewise for OS X (using Py2App).
> 
> We would like to make sure we don't accidentally include
> non-open-source components... I recall there was some discussion here
> about using the Intel math libraries for binary releases on various
> platforms.  Do the releases on SourceForge or PyPI use any proprietary
> code?  We'd like to avoid building NumPy ourselves if we can avoid it.
> 
> Apologies if this is explained somewhere, but I couldn't find it.
> 
> Thanks!
> Andrew Collette

Hi,
the numpy win32 binaries on sourceforge do not contain any proprietary
code. They are build with mingw 3.4.5 and are using a f2c'd version of
netlib blas and lapack which so far I know is public domain.
I think the macos wheels on pypi are built using ATLAS but they do also
contain libquadmath which is LGPL licensed. Its probably pulled in by
fortran (could maybe be removed by a rebuild as neither blas nor numpy
use it)

There are also unofficial win64 binaries floating around, I don't know
what they are using, but its possible they contain MKL, you need to
check with who is building these (Christoph Gohlke I think).

Cheers,
Julian

_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion <at> scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Ariel Rokem | 4 Oct 20:37 2014
Picon

Changed behavior of np.gradient

Hi everyone, 

>>> import numpy as np

>>> np.__version__

'1.9.0'

>>> np.gradient(np.array([[1, 2, 6], [3, 4, 5]], dtype=np.float))

[array([[ 2.,  2., -1.],

       [ 2.,  2., -1.]]), array([[-0.5,  2.5,  5.5],

       [ 1. ,  1. ,  1. ]])]


On the other hand: 

>>> import numpy as np

>>> np.__version__

'1.8.2'

>>> np.gradient(np.array([[1, 2, 6], [3, 4, 5]], dtype=np.float))

[array([[ 2.,  2., -1.],

       [ 2.,  2., -1.]]), array([[ 1. ,  2.5,  4. ],

       [ 1. ,  1. ,  1. ]])]


For what it's worth, the 1.8 version of this function seems to be in agreement with the Matlab equivalent function ('gradient'): 

>> gradient([[1, 2, 6]; [3, 4, 5]])


ans =


    1.0000    2.5000    4.0000

    1.0000    1.0000    1.0000


This seems like a regression to me, but maybe it's an improvement? 

Cheers, 
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion <at> scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Stephan Hoyer | 3 Oct 09:33 2014
Picon

Re: 0/0 == 0?

On Thu, Oct 2, 2014 at 11:29 PM, Nathaniel Smith <njs <at> pobox.com> wrote:
The seterr warning system makes a lot of sense for IEEE754 floats,
which are specifically designed so that 0/0 has a unique well-defined
answer. For ints though this seems really broken to me. 0 / 0 = 0 is
just the wrong answer. It would be nice if we had something reasonable
to return, but we don't, and I'd rather raise an error than return the
wrong answer.

+1

An even worse offender (in my opinion) is in-place addition of an integer array with np.nan:

>>> x = np.zeros(1, dtype=int)
>>> x += np.nan
RuntimeWarning: invalid value encountered in add
>>> x
array([-9223372036854775808])

_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion <at> scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Robert Kern | 3 Oct 09:12 2014
Picon

Re: 0/0 == 0?

On Fri, Oct 3, 2014 at 4:29 AM, Nathaniel Smith <njs <at> pobox.com> wrote:
> On Fri, Oct 3, 2014 at 3:20 AM, Charles R Harris
> <charlesr.harris <at> gmail.com> wrote:
>>
>> On Thu, Oct 2, 2014 at 7:06 PM, Benjamin Root <ben.root <at> ou.edu> wrote:
>>>
>>> Out[1] has an integer divided by an integer, and you can't represent nan
>>> as an integer. Perhaps something weird was happening with type promotion
>>> between versions?
>>
>>
>> Also note that in python3 the '/' operator does float rather than integer
>> division.
>>
>>>>> np.array(0) / np.array(0)
>> __main__:1: RuntimeWarning: invalid value encountered in true_divide
>> nan
>
> Floor division still acts the same though:
>
>>>> np.array(0) // np.array(0)
> __main__:1: RuntimeWarning: divide by zero encountered in floor_divide
> 0
>
> The seterr warning system makes a lot of sense for IEEE754 floats,
> which are specifically designed so that 0/0 has a unique well-defined
> answer. For ints though this seems really broken to me. 0 / 0 = 0 is
> just the wrong answer. It would be nice if we had something reasonable
> to return, but we don't, and I'd rather raise an error than return the
> wrong answer.

Well, actually, that's the really nice thing about seterr for ints!
CPUs have hardware floating point exception flags to work with. We had
to build one for ints. If you want an error, you can get an error. *I*
don't want an error, and I don't have to have one!

--

-- 
Robert Kern
Charles R Harris | 3 Oct 06:12 2014
Picon

Re: 0/0 == 0?



On Thu, Oct 2, 2014 at 9:29 PM, Nathaniel Smith <njs <at> pobox.com> wrote:
On Fri, Oct 3, 2014 at 3:20 AM, Charles R Harris
<charlesr.harris <at> gmail.com> wrote:
>
> On Thu, Oct 2, 2014 at 7:06 PM, Benjamin Root <ben.root <at> ou.edu> wrote:
>>
>> Out[1] has an integer divided by an integer, and you can't represent nan
>> as an integer. Perhaps something weird was happening with type promotion
>> between versions?
>
>
> Also note that in python3 the '/' operator does float rather than integer
> division.
>
>>>> np.array(0) / np.array(0)
> __main__:1: RuntimeWarning: invalid value encountered in true_divide
> nan

Floor division still acts the same though:

>>> np.array(0) // np.array(0)
__main__:1: RuntimeWarning: divide by zero encountered in floor_divide
0

The seterr warning system makes a lot of sense for IEEE754 floats,
which are specifically designed so that 0/0 has a unique well-defined
answer. For ints though this seems really broken to me. 0 / 0 = 0 is
just the wrong answer. It would be nice if we had something reasonable
to return, but we don't, and I'd rather raise an error than return the
wrong answer.

That's an option, although arguable for arrays of numbers. However, the fact that we don't know *which* numbers caused the problem strengthens the argument for an error.

Chuck
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion <at> scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
John Zwinck | 3 Oct 05:00 2014
Picon

Re: Round away from zero (towards +/- infinity)

On 3 Oct 2014 07:09, "T J" <tjhnson <at> gmail.com> wrote:
>
> Any bites on this?
>
> On Wed, Sep 24, 2014 at 12:23 PM, T J <tjhnson <at> gmail.com> wrote:
>> Python's round function goes away from zero, so I am looking for the NumPy equivalent (and using vectorize() seems undesirable). In this sense, it seems that having a ufunc for this type of rounding could be helpful.
>>
>> Aside: Is there interest in a more general around() that allows users to specify alternative tie-breaking rules, with the default staying 'round half to nearest even'? [1] 
>> ---
>> [1] http://stackoverflow.com/questions/16000574/tie-breaking-of-round-with-numpy

I like the solution given in that Stack Overflow post, namely using ctypes to call fesetround(). Does that work for you?

_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion <at> scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Reynolds, Jay | 3 Oct 02:18 2014

Problem building 64 bit numpy using MKL on Windows

 

Hi, I’ve built numpy 64 bit using vc11, the Intel Fortran compiler and the MKL ‘mkl_rt’ library.

*why? (see end of message for the reason, if interested)

 

Any advice or assistance would be greatly appreciated.  If I can offer additional information, I will happily do so.

 

 

The build appears to go just fine (no errors noted), and numpy loads into python just fine as well.

(I note a warning:  ### Warning:  python_xerbla.c is disabled ### -- however, it doesn’t appear to be problematic?)

 

I have also confirmed that numpy sees the mkl blas and lapack libs. 

 

>>> numpy.__config__.show()

lapack_opt_info:

    libraries = ['mkl_lapack', 'mkl_rt']

    library_dirs = ['C:\\Program Files (x86)\\Intel\\Composer XE 2015\\mkl\\lib\\intel64']

    define_macros = [('SCIPY_MKL_H', None)]

    include_dirs = ['C:\\Program Files (x86)\\Intel\\Composer XE 2015\\mkl\\include']

blas_opt_info:

    libraries = ['mkl_rt']

    library_dirs = ['C:\\Program Files (x86)\\Intel\\Composer XE 2015\\mkl\\lib\\intel64']

    define_macros = [('SCIPY_MKL_H', None)]

    include_dirs = ['C:\\Program Files (x86)\\Intel\\Composer XE 2015\\mkl\\include']

openblas_lapack_info:

  NOT AVAILABLE

lapack_mkl_info:

    libraries = ['mkl_lapack', 'mkl_rt']

    library_dirs = ['C:\\Program Files (x86)\\Intel\\Composer XE 2015\\mkl\\lib\\intel64']

    define_macros = [('SCIPY_MKL_H', None)]

    include_dirs = ['C:\\Program Files (x86)\\Intel\\Composer XE 2015\\mkl\\include']

blas_mkl_info:

    libraries = ['mkl_rt']

    library_dirs = ['C:\\Program Files (x86)\\Intel\\Composer XE 2015\\mkl\\lib\\intel64']

    define_macros = [('SCIPY_MKL_H', None)]

    include_dirs = ['C:\\Program Files (x86)\\Intel\\Composer XE 2015\\mkl\\include']

mkl_info:

    libraries = ['mkl_rt']

    library_dirs = ['C:\\Program Files (x86)\\Intel\\Composer XE 2015\\mkl\\lib\\intel64']

    define_macros = [('SCIPY_MKL_H', None)]

    include_dirs = ['C:\\Program Files (x86)\\Intel\\Composer XE 2015\\mkl\\include']

 

Everything *looks* to be in order upon casual inspection (*I think*, please correct me if I’m wrong!)

However, there is no performance boost when running a few different tests in numpy (singular value decomposition, for example), and only a single thread appears to be in play.

 

Running numpy.test(‘full’) reveals 21 errors.

 

For instance,

LINK : fatal error LNK1104: cannot open file 'ifconsol.lib'

 

And, the other being a recurring error with f2py,

 

ERROR: test_size.TestSizeSumExample.test_transpose

----------------------------------------------------------------------

Traceback (most recent call last):

  File "C:\Program Files\Side Effects Software\Houdini 13.0.509\python27\lib\site-packages\nose\case.py", line 371, in setUp

    try_run(self.inst, ('setup', 'setUp'))

  File "C:\Program Files\Side Effects Software\Houdini 13.0.509\python27\lib\site-packages\nose\util.py", line 478, in try_run

    return func()

  File "C:\Program Files\Side Effects Software\Houdini 13.0.509\python27\lib\site-packages\numpy\f2py\tests\util.py", line 353, in setUp

    module_name=self.module_name)

  File "C:\Program Files\Side Effects Software\Houdini 13.0.509\python27\lib\site-packages\numpy\f2py\tests\util.py", line 80, in wrapper

   raise ret

RuntimeError: Running f2py failed: ['-m', '_test_ext_module_5403', 'c:\\users\\jareyn~1\\appdata\\local\\temp\\tmpvykewl

\\foo.f90']

Reading .f2py_f2cmap ...

        Mapping "real(kind=rk)" to "double"

Succesfully applied user defined changes from .f2py_f2cmap

 

 

Everything that requires configuration appears to be in agreement with this Intel Application Note, minus use of the Intel C++ compiler:

https://software.intel.com/en-us/articles/numpyscipy-with-intel-mkl

 

I have also referenced the Windows build docs on scipy.org:

http://www.scipy.org/scipylib/building/windows.html#building-scipy

 

Some info about my configuration:

 

site.cfg:

 

include_dirs = C:\Program Files (x86)\Intel\Composer XE 2015\mkl\include

library_dirs = C:\Program Files (x86)\Intel\Composer XE 2015\mkl\lib\intel64

mkl_libs = mkl_rt

 

PATH = (paths separated by line for easy reading)

C:\Program Files\Side Effects Software\Houdini 13.0.509\python27;

C:\Program Files\Side Effects Software\Houdini 13.0.509\python27\Scripts;

C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\x86_amd64;

C:\Program Files (x86)\Intel\Composer XE 2015\bin\intel64

 

LD_LIBRARY_PATH =

C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\x86_amd64;

C:\Program Files (x86)\Intel\Composer XE 2015\bin\intel64;

C:\Program Files (x86)\Intel\Composer XE 2015\mkl\lib\intel64;

C:\Program Files (x86)\Intel\Composer XE 2015\compiler\lib\intel64

 

Thank you in advance for your time,

 

-Jay

 

=====

*why am I doing this? 

The reason I’m doing this is because I need numpy with MKL to run with the version of python that comes packaged with Houdini (Python 2.7.5 (default, Oct 24 2013, 17:49:49) [MSC v.1700 64 bit (AMD64)] on win32).

So, downloading a prebuilt 64 bit numpy isn’t an option due to the unavailability of a compatible compiler version.

 

_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion <at> scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
T J | 3 Oct 01:02 2014
Picon

0/0 == 0?

Hi, I'm using NumPy 1.8.2:

In [1]: np.array(0) / np.array(0)
Out[1]: 0

In [2]: np.array(0) / np.array(0.0)
Out[2]: nan

In [3]: np.array(0.0) / np.array(0)                                                                                                   Out[3]: nan

In [4]: np.array(0.0) / np.array(0.0)
Out[4]: nan

In [5]: 0/0
---------------------------------------------------------------------------
ZeroDivisionError                         Traceback (most recent call last)
<ipython-input-6-6549dea6d1ae> in <module>()
----> 1 0/0

ZeroDivisionError: integer division or modulo by zero


Out[1] seems odd. I get the right value in 1.8.1.  Was this fixed for 1.9.0?
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion <at> scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Brad Buran | 2 Oct 17:42 2014
Picon

skip samples in random number generator

Given the following:

from numpy import random
rs = random.RandomState(seed=1)
# skip the first X billion samples
x = rs.uniform(0, 10)

How do I accomplish "skip the first X billion samples" (e.g. 7.2
billion)?  I see that there's a numpy.random.RandomState.set_state
which accepts (among other parameters) a value called "pos".  This
sounds promising, but the other parameters I'm not sure how to compute
(e.g. the 1D array of 624 unsigned integers, etc.).  I need to be able
to skip ahead in the sequence to reproduce some signals that were
generated for experiments.  I could certainly consume and discard the
first X billion samples; however, that seems to be computationally
inefficient.

Brad
Bayard | 30 Sep 15:15 2014
Picon

f2py and debug mode

Hello to all.
I'm aiming to wrap a Fortran program into Python. I started to work with 
f2py, and am trying to setup a debug mode where I could reach 
breakpoints in Fortran module launched by Python. I've been looking in 
the existing post, but not seeing things like that.

I'm used to work with visual studio 2012 and Intel Fortran compiler, I 
have tried to get that point doing :
1) Run f2py -m to get *.c wrapper
2) Embed it in a C Project in Visual Studio, containing also with 
fortranobject.c and fortranobject.h,
3) Create a solution which also contains my fortran files compiled as a lib
4) Generate in debug mode a "dll" with extension pyd (to get to that 
point name of the "main" function in Fortran by "_main").

I compiled without any error, and reach break point in C Wrapper, but 
not in Fortran, and the fortran code seems not to be executed (whereas 
it is when compiling with f2py -c). Trying to understand f2py code, I 
noticed that f2py is not only writing c-wrapper, but compiling it in a 
specific way. Is there a way to get a debug mode in Visual Studio with 
f2py (some members of the team are used to it) ? Any alternative tool we 
should use for debugging ?

Thanks for answering
Ferdinand

---
Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection avast!
Antivirus est active.
http://www.avast.com

_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion <at> scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Gmane