Re: [Numpy-discussion] Any plans for windows 64-bit installer for 1.7?

[Ondřej Čertík]

On Wed, Feb 6, 2013 at 10:41 PM, Matthew Brett  wrote:
> Hi,
>
> On Wed, Feb 6, 2013 at 10:21 PM, Ondřej Čertík  
> wrote:
>> On Wed, Feb 6, 2013 at 9:20 PM, Dag Sverre Seljebotn
>>  wrote:
>>> On 02/07/2013 12:16 AM, Matthew Brett wrote:
>> [...]
 Can you clarify the people you think will get stuck?  I think I'm
 right in saying that anyone with a C extension should be able to build
 them against numpy, by installing the free (as-in-beer) MS tools?  So
 do you just mean people needing a Fortran compiler?  That's a small
 constituency, I think.
>>>
>>> Off the top of my head there's SciPy and pymc...
>>>
>>> Anyway, I'm butting in because I wish this discussion could separate
>>> between the user perspective and the developer perspective.
>>>
>>> FWIW,
>>>
>>> 1) From a user's perspective, I don't understand this either. If you are
>>> already using a closed source, not-free-as-in-beer operating system, why
>>> would you not use (or buy!) a closed source, not-free-as-in-beer Fortran
>>> compiler?
>>
>> Indeed. Though I really have no clue on the Windows use cases. Maybe
>> most Windows users don't want to compile anything, just
>> use numpy and scipy from Python?
>
> Well - yes - as a packager I really want to be able to provide a
> binary so my binary consumers don't have to have a C compiler
> installed.   I imagine it's the same for all of us packagers out
> there.
>
>>> 2) BUT, the argument I've seen that I can at least understand is that
>>> the release manager should be able to do a release using only open
>>> source tools (even using Wine instead of Windows) and not rely on a
>>> limited number of licenses. And that the release manager must be able to
>>> perform all the official builds directly.
>>
>> As the release manager, I really only have two requirements:
>>
>> * I want to ssh in there from my Ubuntu
>> * I want to automate the whole process
>>
>> For Mac, linux and Wine I can do that. So I have just spend few hours
>> browsing the net and it looks like that the combination of Windows
>> PowerShell 2.0:
>>
>> http://en.wikipedia.org/wiki/Windows_PowerShell
>>
>> and some SSH server, there are quite a few, one commercial but free
>> for one user one connection (perfect for me!):
>>
>> http://www.powershellinside.com/powershell/ssh/
>>
>> So if I understand the pages correctly, I can login there from linux,
>> and then I use the PowerShell commands to script anything. It looks
>> like I can even use my Fabric fabfiles with powershell:
>>
>> https://gist.github.com/diyan/2850866
>>
>> I can also use git with PowerShell:
>>
>> http://windows.github.com/
>> http://haacked.com/archive/2011/12/13/better-git-with-powershell.aspx
>>
>>
>> So the final problem is how to execute MSVC and Fortran from Power
>> Shell on Windows. These links might help for MSVC:
>>
>> http://stackoverflow.com/questions/4398136/use-powershell-for-visual-studio-command-prompt
>> http://geekswithblogs.net/dwdii/archive/2011/05/20/automating-a-visual-studio-build-with-powershell---part-1.aspx
>>
>> Finally, for Intel Fortran + powershell:
>>
>> http://software.intel.com/en-us/forums/topic/284425
>>
>>
>> So I think it is all possible. If somebody can provide a machine with
>> Windows, MSVC, PowerShell2.0, SSH server and some Fortran compiler, it
>> should be possible for me to automate everything from Ubuntu using my
>> Fabric files (https://github.com/certik/numpy-vendor).
>
> Many many thanks for trying to solve this.  I had really started to
> give up hope.
>
> I think you will need a developer's license for MKL for Numpy.  Ralf -
> any ETA for those?
>
> I think I'm right in thinking you'll need a Fortran compiler for Scipy
> but not Numpy?  Can we defer the Scipy build until after the Numpy
> build?
>
> I will try to get you set up with ssh on my Windows 7 machine in case
> you can use it.  It has the MS tools.

That would be amazing! If you can set me up with the Power Shell
and some ssh server, I'll start playing with this right away.

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

Re: [Numpy-discussion] Any plans for windows 64-bit installer for 1.7?

[Matthew Brett]

Hi,

On Wed, Feb 6, 2013 at 10:21 PM, Ondřej Čertík  wrote:
> On Wed, Feb 6, 2013 at 9:20 PM, Dag Sverre Seljebotn
>  wrote:
>> On 02/07/2013 12:16 AM, Matthew Brett wrote:
> [...]
>>> Can you clarify the people you think will get stuck?  I think I'm
>>> right in saying that anyone with a C extension should be able to build
>>> them against numpy, by installing the free (as-in-beer) MS tools?  So
>>> do you just mean people needing a Fortran compiler?  That's a small
>>> constituency, I think.
>>
>> Off the top of my head there's SciPy and pymc...
>>
>> Anyway, I'm butting in because I wish this discussion could separate
>> between the user perspective and the developer perspective.
>>
>> FWIW,
>>
>> 1) From a user's perspective, I don't understand this either. If you are
>> already using a closed source, not-free-as-in-beer operating system, why
>> would you not use (or buy!) a closed source, not-free-as-in-beer Fortran
>> compiler?
>
> Indeed. Though I really have no clue on the Windows use cases. Maybe
> most Windows users don't want to compile anything, just
> use numpy and scipy from Python?

Well - yes - as a packager I really want to be able to provide a
binary so my binary consumers don't have to have a C compiler
installed.   I imagine it's the same for all of us packagers out
there.

>> 2) BUT, the argument I've seen that I can at least understand is that
>> the release manager should be able to do a release using only open
>> source tools (even using Wine instead of Windows) and not rely on a
>> limited number of licenses. And that the release manager must be able to
>> perform all the official builds directly.
>
> As the release manager, I really only have two requirements:
>
> * I want to ssh in there from my Ubuntu
> * I want to automate the whole process
>
> For Mac, linux and Wine I can do that. So I have just spend few hours
> browsing the net and it looks like that the combination of Windows
> PowerShell 2.0:
>
> http://en.wikipedia.org/wiki/Windows_PowerShell
>
> and some SSH server, there are quite a few, one commercial but free
> for one user one connection (perfect for me!):
>
> http://www.powershellinside.com/powershell/ssh/
>
> So if I understand the pages correctly, I can login there from linux,
> and then I use the PowerShell commands to script anything. It looks
> like I can even use my Fabric fabfiles with powershell:
>
> https://gist.github.com/diyan/2850866
>
> I can also use git with PowerShell:
>
> http://windows.github.com/
> http://haacked.com/archive/2011/12/13/better-git-with-powershell.aspx
>
>
> So the final problem is how to execute MSVC and Fortran from Power
> Shell on Windows. These links might help for MSVC:
>
> http://stackoverflow.com/questions/4398136/use-powershell-for-visual-studio-command-prompt
> http://geekswithblogs.net/dwdii/archive/2011/05/20/automating-a-visual-studio-build-with-powershell---part-1.aspx
>
> Finally, for Intel Fortran + powershell:
>
> http://software.intel.com/en-us/forums/topic/284425
>
>
> So I think it is all possible. If somebody can provide a machine with
> Windows, MSVC, PowerShell2.0, SSH server and some Fortran compiler, it
> should be possible for me to automate everything from Ubuntu using my
> Fabric files (https://github.com/certik/numpy-vendor).

Many many thanks for trying to solve this.  I had really started to
give up hope.

I think you will need a developer's license for MKL for Numpy.  Ralf -
any ETA for those?

I think I'm right in thinking you'll need a Fortran compiler for Scipy
but not Numpy?  Can we defer the Scipy build until after the Numpy
build?

I will try to get you set up with ssh on my Windows 7 machine in case
you can use it.  It has the MS tools.

Thanks again,

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

Re: [Numpy-discussion] Will numpy 1.7.0 final be binary compatible with the rc?

[Ondřej Čertík]

On Wed, Feb 6, 2013 at 2:37 AM, Peter Cock  wrote:
> On Wed, Feb 6, 2013 at 3:46 AM, Ondřej Čertík  wrote:
>> On Tue, Feb 5, 2013 at 12:22 PM, Ralf Gommers  wrote:
>>> On Tue, Feb 5, 2013 at 3:01 PM, Peter Cock 
>>> wrote:

 Hello all,

 Will the numpy 1.7.0 'final' be binary compatible with the release
 candidate(s)? i.e. Would it be safe for me to release a Windows
 installer for a package using the NumPy C API compiled against
 the NumPy 1.7.0rc?
>>>
>>>
>>> Yes, that should be safe.
>>
>> Yes. I plan to release rc2 immediately once
>>
>> https://github.com/numpy/numpy/pull/2964
>>
>> is merged (e.g. I am hoping for today). The final should then be
>> identical to rc2.
>>
>> Ondrej
>
> Great - in that case I'll wait a couple of days and use rc2 for this
> (just in case there is a subtle difference from rc1).

Awesome. The rc2 is out.

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

Re: [Numpy-discussion] Any plans for windows 64-bit installer for 1.7?

[Ondřej Čertík]

Christoph,

On Tue, Feb 5, 2013 at 3:04 PM, Christoph Gohlke  wrote:
[...]
>> In order not to leave this discussion without a resolution:
>>
>> Christophe - would you allow us to distribute your numpy binaries for
>> 1.7 from the numpy sourceforge page?
>>
>> Cheers,
>>
>> Matthew
>
>
> I am OK with providing 64 bit "numpy-MKL" binaries (that is numpy
> compiled with MSVC compilers and linked to Intel's MKL) for official
> numpy releases.
>
> However:
>
> 1) There seems to be no real consensus and urge for doing this. Using a
> free toolchain capable of building the whole scipy-stack would be much
> preferred. Several 64 bit Python distributions containing numpy-MKL are
> already available, some for free.
>
> 2) Releasing 64 bit numpy without matching scipy binaries would make
> little sense to me.
>
> 3) Please do not just redistribute the binaries from my website and
> declare them official. They might contain unreleased fixes from git
> master and pull requests that are needed for my work and other packages.
>
> 4) Numpy-MKL requires the Intel runtime DLLs (MKL is linked statically
> btw). I ship those with the installers and append the directory
> containing the DLLs to os.environ['PATH'] in numpy/__init__.py. This is
> a big no-no according to numpy developers. I don't agree. Anyway, those
> changes are not in the numpy source repositories.
>
> 5) My numpy-MKL installers are Python distutils bdist_wininst
> installers. That means if Python was installed for all users, installing
> numpy-MKL on Windows >6.0 will prompt for UAC elevation. Another no-no?

I think that all these things should be possible to fix so that the
binary is acceptable
for the official NumPy binary.

How exactly do you build the binaries? I wasn't able to find the info at:

http://www.lfd.uci.edu/~gohlke/pythonlibs/

Do you have some scripts to do that? Do you use PowerShell? Or you do
it by hand by mouse and clicks in Visual Studio somehow? If I can
figure out how to do these builds, I'll be happy to figure out how to
automate it and then we can try to figure out a solution that works
for NumPy.

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

Re: [Numpy-discussion] Any plans for windows 64-bit installer for 1.7?

[Ondřej Čertík]

On Wed, Feb 6, 2013 at 9:20 PM, Dag Sverre Seljebotn
 wrote:
> On 02/07/2013 12:16 AM, Matthew Brett wrote:
[...]
>> Can you clarify the people you think will get stuck?  I think I'm
>> right in saying that anyone with a C extension should be able to build
>> them against numpy, by installing the free (as-in-beer) MS tools?  So
>> do you just mean people needing a Fortran compiler?  That's a small
>> constituency, I think.
>
> Off the top of my head there's SciPy and pymc...
>
> Anyway, I'm butting in because I wish this discussion could separate
> between the user perspective and the developer perspective.
>
> FWIW,
>
> 1) From a user's perspective, I don't understand this either. If you are
> already using a closed source, not-free-as-in-beer operating system, why
> would you not use (or buy!) a closed source, not-free-as-in-beer Fortran
> compiler?

Indeed. Though I really have no clue on the Windows use cases. Maybe
most Windows users don't want to compile anything, just
use numpy and scipy from Python?

>
> 2) BUT, the argument I've seen that I can at least understand is that
> the release manager should be able to do a release using only open
> source tools (even using Wine instead of Windows) and not rely on a
> limited number of licenses. And that the release manager must be able to
> perform all the official builds directly.

As the release manager, I really only have two requirements:

* I want to ssh in there from my Ubuntu
* I want to automate the whole process

For Mac, linux and Wine I can do that. So I have just spend few hours
browsing the net and it looks like that the combination of Windows
PowerShell 2.0:

http://en.wikipedia.org/wiki/Windows_PowerShell

and some SSH server, there are quite a few, one commercial but free
for one user one connection (perfect for me!):

http://www.powershellinside.com/powershell/ssh/

So if I understand the pages correctly, I can login there from linux,
and then I use the PowerShell commands to script anything. It looks
like I can even use my Fabric fabfiles with powershell:

https://gist.github.com/diyan/2850866

I can also use git with PowerShell:

http://windows.github.com/
http://haacked.com/archive/2011/12/13/better-git-with-powershell.aspx


So the final problem is how to execute MSVC and Fortran from Power
Shell on Windows. These links might help for MSVC:

http://stackoverflow.com/questions/4398136/use-powershell-for-visual-studio-command-prompt
http://geekswithblogs.net/dwdii/archive/2011/05/20/automating-a-visual-studio-build-with-powershell---part-1.aspx

Finally, for Intel Fortran + powershell:

http://software.intel.com/en-us/forums/topic/284425


So I think it is all possible. If somebody can provide a machine with
Windows, MSVC, PowerShell2.0, SSH server and some Fortran compiler, it
should be possible for me to automate everything from Ubuntu using my
Fabric files (https://github.com/certik/numpy-vendor).

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

Re: [Numpy-discussion] Any plans for windows 64-bit installer for 1.7?

[Matthew Brett]

Hi,

On Wed, Feb 6, 2013 at 9:20 PM, Dag Sverre Seljebotn
 wrote:
> On 02/07/2013 12:16 AM, Matthew Brett wrote:
>> Hi,
>>
>> On Wed, Feb 6, 2013 at 1:36 PM, Ralf Gommers  wrote:
>>>
>>>
>>>
>>> On Wed, Feb 6, 2013 at 8:46 PM, Matthew Brett 
>>> wrote:

 Hi,

 On Wed, Feb 6, 2013 at 10:48 AM, Ralf Gommers 
 wrote:
>
>
>
> On Wed, Feb 6, 2013 at 1:32 AM, Matthew Brett 
> wrote:
>>
>> Hi,
>>
>> On Tue, Feb 5, 2013 at 3:04 PM, Christoph Gohlke 
>> wrote:
>>> On 2/5/2013 10:51 AM, Matthew Brett wrote:
 Hi,

 On Mon, Feb 4, 2013 at 5:09 PM, Matthew Brett
 
 wrote:
> Hi,
>
> On Mon, Feb 4, 2013 at 3:46 PM, Charles R Harris
>  wrote:
>>
>>
>> On Mon, Feb 4, 2013 at 4:04 PM, Robert Kern
>> 
>> wrote:
>>>
>>> On Mon, Feb 4, 2013 at 10:38 PM, Matthew Brett
>>> 
>>> wrote:
 Hi,

 On Mon, Feb 4, 2013 at 1:15 PM, Ralf Gommers
 
 wrote:
>>>
> MSVC + Intel Fortran + MKL, yes. But those aren't free. So how
> can
> you
> provide an Amazon image for those?

 You can make an image that is not public, I guess.   I suppose
 anyone
 who uses the image would have to have their own licenses for the
 Intel
 stuff?   Does anyone have experience of this?
>>>
>>> You need to purchase one license per developer:
>>>
>>>
>>>
>>>
>>> http://software.intel.com/en-us/articles/intel-math-kernel-library-licensing-faq#eula1
>>>
>>
>> I think 64 bits on windows is best pushed off to 1.7.1 or 1.8. It
>> would be a
>> bit much to get it implemented in the next week or two.
>
> The problem with not providing these binaries is that they are at
> the
> bottom of everyone's stack, so a delay in numpy holds everyone
> back.
>
> I can't find completely convincing stats, but it looks as though 64
> bit windows 7 is now the most common version of Windows, at least
> for
> Gamers [1] around now, and it was getting that way for everyone in
> 2010 [2].
>
> It don't think it reflects well on on us that we don't appear to
> support 64 bits out of the box; just for example, R already has a
> 32
> bit / 64 bit installer.
>
> If I understand correctly, the options for doing this right now
> are:
>
> 1) Minimal cost in time : ask Christophe nicely whether we can
> distribute his binaries via the Numpy page
> 2) Small cost in time / money : pay for licenses for Ondrej or me
> or
> someone to install the dependencies on my Berkeley machine / an
> Amazon
> image.

 In order not to leave this discussion without a resolution:

 Christophe - would you allow us to distribute your numpy binaries
 for
 1.7 from the numpy sourceforge page?

 Cheers,

 Matthew
>>>
>>>
>>> I am OK with providing 64 bit "numpy-MKL" binaries (that is numpy
>>> compiled with MSVC compilers and linked to Intel's MKL) for official
>>> numpy releases.
>>
>> Thank you - that is great.
>>
>>> However:
>>>
>>> 1) There seems to be no real consensus and urge for doing this.
>>
>> I certainly feel the urge and feel it strongly. As a packager for two
>> or three projects myself, it's a royal pain having to tell someone to
>> go to two different places for binaries depending on the number of
>> bits of their Windows.
>
>
> If you're relying on .exe installers on SF, then you have to send your
> users
> to more places than that probably. Really the separate installers are a
> poor
> alternative to the available scientific distributions. And the more
> packages
> you need as a user, the more annoying these separate installers are.
>
>>
>>   I think Chuck was worried about the time it
>> would take to do it, and I think you've already solved this problem.
>> Ralf was worried about Scipy - see below.
>
>
> Not just Scipy - that would be my worry number one, but the same holds
> for
> all packages based on Numpy. You double the number of Windows installers
> that every single project needs to provide.
>
>>
>>
>>> Using a
>>> free toolchain capable of building the whole scipy-stack would be
>>> much
>>> preferred.
>>
>> That's true, but there seems general agreement this is not practical
>> in the very near future.
>>
>>> Several 64 bit Python dist

Re: [Numpy-discussion] Any plans for windows 64-bit installer for 1.7?

[Dag Sverre Seljebotn]

On 02/07/2013 12:16 AM, Matthew Brett wrote:
> Hi,
>
> On Wed, Feb 6, 2013 at 1:36 PM, Ralf Gommers  wrote:
>>
>>
>>
>> On Wed, Feb 6, 2013 at 8:46 PM, Matthew Brett 
>> wrote:
>>>
>>> Hi,
>>>
>>> On Wed, Feb 6, 2013 at 10:48 AM, Ralf Gommers 
>>> wrote:



 On Wed, Feb 6, 2013 at 1:32 AM, Matthew Brett 
 wrote:
>
> Hi,
>
> On Tue, Feb 5, 2013 at 3:04 PM, Christoph Gohlke 
> wrote:
>> On 2/5/2013 10:51 AM, Matthew Brett wrote:
>>> Hi,
>>>
>>> On Mon, Feb 4, 2013 at 5:09 PM, Matthew Brett
>>> 
>>> wrote:
 Hi,

 On Mon, Feb 4, 2013 at 3:46 PM, Charles R Harris
  wrote:
>
>
> On Mon, Feb 4, 2013 at 4:04 PM, Robert Kern
> 
> wrote:
>>
>> On Mon, Feb 4, 2013 at 10:38 PM, Matthew Brett
>> 
>> wrote:
>>> Hi,
>>>
>>> On Mon, Feb 4, 2013 at 1:15 PM, Ralf Gommers
>>> 
>>> wrote:
>>
 MSVC + Intel Fortran + MKL, yes. But those aren't free. So how
 can
 you
 provide an Amazon image for those?
>>>
>>> You can make an image that is not public, I guess.   I suppose
>>> anyone
>>> who uses the image would have to have their own licenses for the
>>> Intel
>>> stuff?   Does anyone have experience of this?
>>
>> You need to purchase one license per developer:
>>
>>
>>
>>
>> http://software.intel.com/en-us/articles/intel-math-kernel-library-licensing-faq#eula1
>>
>
> I think 64 bits on windows is best pushed off to 1.7.1 or 1.8. It
> would be a
> bit much to get it implemented in the next week or two.

 The problem with not providing these binaries is that they are at
 the
 bottom of everyone's stack, so a delay in numpy holds everyone
 back.

 I can't find completely convincing stats, but it looks as though 64
 bit windows 7 is now the most common version of Windows, at least
 for
 Gamers [1] around now, and it was getting that way for everyone in
 2010 [2].

 It don't think it reflects well on on us that we don't appear to
 support 64 bits out of the box; just for example, R already has a
 32
 bit / 64 bit installer.

 If I understand correctly, the options for doing this right now
 are:

 1) Minimal cost in time : ask Christophe nicely whether we can
 distribute his binaries via the Numpy page
 2) Small cost in time / money : pay for licenses for Ondrej or me
 or
 someone to install the dependencies on my Berkeley machine / an
 Amazon
 image.
>>>
>>> In order not to leave this discussion without a resolution:
>>>
>>> Christophe - would you allow us to distribute your numpy binaries
>>> for
>>> 1.7 from the numpy sourceforge page?
>>>
>>> Cheers,
>>>
>>> Matthew
>>
>>
>> I am OK with providing 64 bit "numpy-MKL" binaries (that is numpy
>> compiled with MSVC compilers and linked to Intel's MKL) for official
>> numpy releases.
>
> Thank you - that is great.
>
>> However:
>>
>> 1) There seems to be no real consensus and urge for doing this.
>
> I certainly feel the urge and feel it strongly. As a packager for two
> or three projects myself, it's a royal pain having to tell someone to
> go to two different places for binaries depending on the number of
> bits of their Windows.


 If you're relying on .exe installers on SF, then you have to send your
 users
 to more places than that probably. Really the separate installers are a
 poor
 alternative to the available scientific distributions. And the more
 packages
 you need as a user, the more annoying these separate installers are.

>
>   I think Chuck was worried about the time it
> would take to do it, and I think you've already solved this problem.
> Ralf was worried about Scipy - see below.


 Not just Scipy - that would be my worry number one, but the same holds
 for
 all packages based on Numpy. You double the number of Windows installers
 that every single project needs to provide.

>
>
>> Using a
>> free toolchain capable of building the whole scipy-stack would be
>> much
>> preferred.
>
> That's true, but there seems general agreement this is not practical
> in the very near future.
>
>> Several 64 bit Python distributions containing numpy-MKL are
>> already available, some for free.
>
> You mean EPD and AnacondaCE?   I don't think we should withhold easily
> available vanilla builds because they are also available i

[Numpy-discussion] ANN: NumPy 1.7.0rc2 release

[Ondřej Čertík]

Hi,

I'm pleased to announce the availability of the second release candidate of
NumPy 1.7.0rc2.

Sources and binary installers can be found at
https://sourceforge.net/projects/numpy/files/NumPy/1.7.0rc2/

We have fixed all issues known to us since the 1.7.0rc1 release.

Please test this release and report any issues on the numpy-discussion
mailing list. If there are no further problems, I plan to release the final
version in a few days.

I would like to thank Sandro Tosi, Sebastian Berg, Charles Harris,
Marcin Juszkiewicz, Mark Wiebe, Ralf Gommers and Nathaniel J. Smith
for sending patches, fixes and helping with reviews for this release since
1.7.0rc1, and Vincent Davis for providing the Mac build machine.

Cheers,
Ondrej




=
NumPy 1.7.0 Release Notes
=

This release includes several new features as well as numerous bug fixes and
refactorings. It supports Python 2.4 - 2.7 and 3.1 - 3.3 and is the last
release that supports Python 2.4 - 2.5.

Highlights
==

* ``where=`` parameter to ufuncs (allows the use of boolean arrays to choose
  where a computation should be done)
* ``vectorize`` improvements (added 'excluded' and 'cache' keyword, general
  cleanup and bug fixes)
* ``numpy.random.choice`` (random sample generating function)


Compatibility notes
===

In a future version of numpy, the functions np.diag, np.diagonal, and the
diagonal method of ndarrays will return a view onto the original array,
instead of producing a copy as they do now. This makes a difference if you
write to the array returned by any of these functions. To facilitate this
transition, numpy 1.7 produces a FutureWarning if it detects that you may
be attempting to write to such an array. See the documentation for
np.diagonal for details.

Similar to np.diagonal above, in a future version of numpy, indexing a
record array by a list of field names will return a view onto the original
array, instead of producing a copy as they do now. As with np.diagonal,
numpy 1.7 produces a FutureWarning if it detects that you may be attempting
to write to such an array. See the documentation for array indexing for
details.

In a future version of numpy, the default casting rule for UFunc out=
parameters will be changed from 'unsafe' to 'same_kind'. (This also applies
to in-place operations like a += b, which is equivalent to np.add(a, b,
out=a).) Most usages which violate the 'same_kind' rule are likely bugs, so
this change may expose previously undetected errors in projects that depend
on NumPy. In this version of numpy, such usages will continue to succeed,
but will raise a DeprecationWarning.

Full-array boolean indexing has been optimized to use a different,
optimized code path.   This code path should produce the same results,
but any feedback about changes to your code would be appreciated.

Attempting to write to a read-only array (one with ``arr.flags.writeable``
set to ``False``) used to raise either a RuntimeError, ValueError, or
TypeError inconsistently, depending on which code path was taken. It now
consistently raises a ValueError.

The .reduce functions evaluate some reductions in a different order
than in previous versions of NumPy, generally providing higher performance.
Because of the nature of floating-point arithmetic, this may subtly change
some results, just as linking NumPy to a different BLAS implementations
such as MKL can.

If upgrading from 1.5, then generally in 1.6 and 1.7 there have been
substantial code added and some code paths altered, particularly in the
areas of type resolution and buffered iteration over universal functions.
This might have an impact on your code particularly if you relied on
accidental behavior in the past.

New features


Reduction UFuncs Generalize axis= Parameter
---

Any ufunc.reduce function call, as well as other reductions like sum, prod,
any, all, max and min support the ability to choose a subset of the axes to
reduce over. Previously, one could say axis=None to mean all the axes or
axis=# to pick a single axis.  Now, one can also say axis=(#,#) to pick a
list of axes for reduction.

Reduction UFuncs New keepdims= Parameter


There is a new keepdims= parameter, which if set to True, doesn't throw
away the reduction axes but instead sets them to have size one.  When this
option is set, the reduction result will broadcast correctly to the
original operand which was reduced.

Datetime support


.. note:: The datetime API is *experimental* in 1.7.0, and may undergo changes
   in future versions of NumPy.

There have been a lot of fixes and enhancements to datetime64 compared
to NumPy 1.6:

* the parser is quite strict about only accepting ISO 8601 dates, with a few
  convenience extensions
* converts between units correctly
* datetime arithmetic works correctly
* business day functionality (allows the datetime to be

Re: [Numpy-discussion] Any plans for windows 64-bit installer for 1.7?

[Chris Barker - NOAA Federal]

On Wed, Feb 6, 2013 at 3:16 PM, Matthew Brett  wrote:

> Can you clarify the people you think will get stuck?  I think I'm
> right in saying that anyone with a C extension should be able to build
> them against numpy, by installing the free (as-in-beer) MS tools?

yup -- and that's the recommended (easiest) way to do it against the
the python.org python.

and you can use mingw to compile extensions that will run with the
python.org python (built with MSVC), can you not use mingw to build
extensions that will work with a MSVC-build numpy?

> So
> do you just mean people needing a Fortran compiler?  That's a small
> constituency, I think.

particularly small overlap between needing fortran (and knowing how to
deal with building it) and needing binaries of numpy

if someone has a fortran-extension-building solution -- is it likeley
not to work with a MSVC-built numpy?

> And, if we start providing installers, I
> suspect we'll find that people start solving the remaining issues much
> more quickly than would happen if we don't provide them.

+1

-Chris

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Any plans for windows 64-bit installer for 1.7?

[Matthew Brett]

Hi,

On Wed, Feb 6, 2013 at 1:36 PM, Ralf Gommers  wrote:
>
>
>
> On Wed, Feb 6, 2013 at 8:46 PM, Matthew Brett 
> wrote:
>>
>> Hi,
>>
>> On Wed, Feb 6, 2013 at 10:48 AM, Ralf Gommers 
>> wrote:
>> >
>> >
>> >
>> > On Wed, Feb 6, 2013 at 1:32 AM, Matthew Brett 
>> > wrote:
>> >>
>> >> Hi,
>> >>
>> >> On Tue, Feb 5, 2013 at 3:04 PM, Christoph Gohlke 
>> >> wrote:
>> >> > On 2/5/2013 10:51 AM, Matthew Brett wrote:
>> >> >> Hi,
>> >> >>
>> >> >> On Mon, Feb 4, 2013 at 5:09 PM, Matthew Brett
>> >> >> 
>> >> >> wrote:
>> >> >>> Hi,
>> >> >>>
>> >> >>> On Mon, Feb 4, 2013 at 3:46 PM, Charles R Harris
>> >> >>>  wrote:
>> >> 
>> >> 
>> >>  On Mon, Feb 4, 2013 at 4:04 PM, Robert Kern
>> >>  
>> >>  wrote:
>> >> >
>> >> > On Mon, Feb 4, 2013 at 10:38 PM, Matthew Brett
>> >> > 
>> >> > wrote:
>> >> >> Hi,
>> >> >>
>> >> >> On Mon, Feb 4, 2013 at 1:15 PM, Ralf Gommers
>> >> >> 
>> >> >> wrote:
>> >> >
>> >> >>> MSVC + Intel Fortran + MKL, yes. But those aren't free. So how
>> >> >>> can
>> >> >>> you
>> >> >>> provide an Amazon image for those?
>> >> >>
>> >> >> You can make an image that is not public, I guess.   I suppose
>> >> >> anyone
>> >> >> who uses the image would have to have their own licenses for the
>> >> >> Intel
>> >> >> stuff?   Does anyone have experience of this?
>> >> >
>> >> > You need to purchase one license per developer:
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > http://software.intel.com/en-us/articles/intel-math-kernel-library-licensing-faq#eula1
>> >> >
>> >> 
>> >>  I think 64 bits on windows is best pushed off to 1.7.1 or 1.8. It
>> >>  would be a
>> >>  bit much to get it implemented in the next week or two.
>> >> >>>
>> >> >>> The problem with not providing these binaries is that they are at
>> >> >>> the
>> >> >>> bottom of everyone's stack, so a delay in numpy holds everyone
>> >> >>> back.
>> >> >>>
>> >> >>> I can't find completely convincing stats, but it looks as though 64
>> >> >>> bit windows 7 is now the most common version of Windows, at least
>> >> >>> for
>> >> >>> Gamers [1] around now, and it was getting that way for everyone in
>> >> >>> 2010 [2].
>> >> >>>
>> >> >>> It don't think it reflects well on on us that we don't appear to
>> >> >>> support 64 bits out of the box; just for example, R already has a
>> >> >>> 32
>> >> >>> bit / 64 bit installer.
>> >> >>>
>> >> >>> If I understand correctly, the options for doing this right now
>> >> >>> are:
>> >> >>>
>> >> >>> 1) Minimal cost in time : ask Christophe nicely whether we can
>> >> >>> distribute his binaries via the Numpy page
>> >> >>> 2) Small cost in time / money : pay for licenses for Ondrej or me
>> >> >>> or
>> >> >>> someone to install the dependencies on my Berkeley machine / an
>> >> >>> Amazon
>> >> >>> image.
>> >> >>
>> >> >> In order not to leave this discussion without a resolution:
>> >> >>
>> >> >> Christophe - would you allow us to distribute your numpy binaries
>> >> >> for
>> >> >> 1.7 from the numpy sourceforge page?
>> >> >>
>> >> >> Cheers,
>> >> >>
>> >> >> Matthew
>> >> >
>> >> >
>> >> > I am OK with providing 64 bit "numpy-MKL" binaries (that is numpy
>> >> > compiled with MSVC compilers and linked to Intel's MKL) for official
>> >> > numpy releases.
>> >>
>> >> Thank you - that is great.
>> >>
>> >> > However:
>> >> >
>> >> > 1) There seems to be no real consensus and urge for doing this.
>> >>
>> >> I certainly feel the urge and feel it strongly. As a packager for two
>> >> or three projects myself, it's a royal pain having to tell someone to
>> >> go to two different places for binaries depending on the number of
>> >> bits of their Windows.
>> >
>> >
>> > If you're relying on .exe installers on SF, then you have to send your
>> > users
>> > to more places than that probably. Really the separate installers are a
>> > poor
>> > alternative to the available scientific distributions. And the more
>> > packages
>> > you need as a user, the more annoying these separate installers are.
>> >
>> >>
>> >>  I think Chuck was worried about the time it
>> >> would take to do it, and I think you've already solved this problem.
>> >> Ralf was worried about Scipy - see below.
>> >
>> >
>> > Not just Scipy - that would be my worry number one, but the same holds
>> > for
>> > all packages based on Numpy. You double the number of Windows installers
>> > that every single project needs to provide.
>> >
>> >>
>> >>
>> >> > Using a
>> >> > free toolchain capable of building the whole scipy-stack would be
>> >> > much
>> >> > preferred.
>> >>
>> >> That's true, but there seems general agreement this is not practical
>> >> in the very near future.
>> >>
>> >> > Several 64 bit Python distributions containing numpy-MKL are
>> >> > already available, some for free.
>> >>
>> >> You mean EPD and AnacondaCE?   I don't think we should withhold easily
>> >> available vanilla bui

Re: [Numpy-discussion] Any plans for windows 64-bit installer for 1.7?

[Chris Barker - NOAA Federal]

I'm trying to weed out the issues here:

1) what should the binary installer for Windows look like:
* bdist_wininst is the obvious choice but apparently has issues
with the newer Windows security stuff -- the real solution is for
distutils to be fixed/use something else/ etc -- but is there anyone
here that has expertise, interest or time to get in and add-to or fix
distutils?

Do binary eggs solve any of this ? maybe, but pip doesn't support that
last I saw, and setuptools easy-install is kind-of sort-of broken.

But coming up with the best binary installer tool is orthogonal to the
other questions:

2) Should we distribute binaries at all?
  - No: most people need a whole stack anyway, so they should get all
that from the same place:
 - Enthought
 - Python(x.y)
 - Chris Gohlke's repository...
  - Yes:
  Some folks just want numpy damn it! Those big ol' distributions
are a mess that don't work for everyone. (I'm in that camp.)

But if we distribute binaries, we really should:
  - distribute them for 32 & 64 bit
  - Clearly define what the "official" binaries are, so that
third-party packagers can build against that.

Historically, this has been a huge mess on the Mac, as there are many
options for Python itself: Apple's builds, Python,org builds,
macports, fink, homebrew, .. Over the years, we in teh MacPython
community have tried hard to establish that the python.org builds are
the "official" builds that folks should support with binaries -- this
has kind-of, sort-of worked, but I still don't see a better solution.
(macports et al aren't really the issue, they aren't based on binaries
anyway)

On Windows, this has been pretty much a non-issue: MS doesn't provide
a build, and the pyton.org builds are well accepted as the default
binaries. AFAIU, third party distributions are compatible as well
(Active State, Enthought)

The parallel here is that we can establish in the scientific python
community (that is, folks building packages based on numpy) that the
binaries distributed by numpy are the "official" ones that should be
supported by third part binaries. If we succeed in that, then folks
can get the rest of the stack from any number of sources.

the python.org python builds are built with the MS compilers, is there
any reason we HAVE to build with a open-source stack? Can you build
third party packages against an MS-built binary numpy with open-source
compilers?

-Chris



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Any plans for windows 64-bit installer for 1.7?

[Ralf Gommers]

On Wed, Feb 6, 2013 at 8:46 PM, Matthew Brett wrote:

> Hi,
>
> On Wed, Feb 6, 2013 at 10:48 AM, Ralf Gommers 
> wrote:
> >
> >
> >
> > On Wed, Feb 6, 2013 at 1:32 AM, Matthew Brett 
> > wrote:
> >>
> >> Hi,
> >>
> >> On Tue, Feb 5, 2013 at 3:04 PM, Christoph Gohlke 
> wrote:
> >> > On 2/5/2013 10:51 AM, Matthew Brett wrote:
> >> >> Hi,
> >> >>
> >> >> On Mon, Feb 4, 2013 at 5:09 PM, Matthew Brett <
> matthew.br...@gmail.com>
> >> >> wrote:
> >> >>> Hi,
> >> >>>
> >> >>> On Mon, Feb 4, 2013 at 3:46 PM, Charles R Harris
> >> >>>  wrote:
> >> 
> >> 
> >>  On Mon, Feb 4, 2013 at 4:04 PM, Robert Kern  >
> >>  wrote:
> >> >
> >> > On Mon, Feb 4, 2013 at 10:38 PM, Matthew Brett
> >> > 
> >> > wrote:
> >> >> Hi,
> >> >>
> >> >> On Mon, Feb 4, 2013 at 1:15 PM, Ralf Gommers
> >> >> 
> >> >> wrote:
> >> >
> >> >>> MSVC + Intel Fortran + MKL, yes. But those aren't free. So how
> can
> >> >>> you
> >> >>> provide an Amazon image for those?
> >> >>
> >> >> You can make an image that is not public, I guess.   I suppose
> >> >> anyone
> >> >> who uses the image would have to have their own licenses for the
> >> >> Intel
> >> >> stuff?   Does anyone have experience of this?
> >> >
> >> > You need to purchase one license per developer:
> >> >
> >> >
> >> >
> >> >
> http://software.intel.com/en-us/articles/intel-math-kernel-library-licensing-faq#eula1
> >> >
> >> 
> >>  I think 64 bits on windows is best pushed off to 1.7.1 or 1.8. It
> >>  would be a
> >>  bit much to get it implemented in the next week or two.
> >> >>>
> >> >>> The problem with not providing these binaries is that they are at
> the
> >> >>> bottom of everyone's stack, so a delay in numpy holds everyone back.
> >> >>>
> >> >>> I can't find completely convincing stats, but it looks as though 64
> >> >>> bit windows 7 is now the most common version of Windows, at least
> for
> >> >>> Gamers [1] around now, and it was getting that way for everyone in
> >> >>> 2010 [2].
> >> >>>
> >> >>> It don't think it reflects well on on us that we don't appear to
> >> >>> support 64 bits out of the box; just for example, R already has a 32
> >> >>> bit / 64 bit installer.
> >> >>>
> >> >>> If I understand correctly, the options for doing this right now are:
> >> >>>
> >> >>> 1) Minimal cost in time : ask Christophe nicely whether we can
> >> >>> distribute his binaries via the Numpy page
> >> >>> 2) Small cost in time / money : pay for licenses for Ondrej or me or
> >> >>> someone to install the dependencies on my Berkeley machine / an
> Amazon
> >> >>> image.
> >> >>
> >> >> In order not to leave this discussion without a resolution:
> >> >>
> >> >> Christophe - would you allow us to distribute your numpy binaries for
> >> >> 1.7 from the numpy sourceforge page?
> >> >>
> >> >> Cheers,
> >> >>
> >> >> Matthew
> >> >
> >> >
> >> > I am OK with providing 64 bit "numpy-MKL" binaries (that is numpy
> >> > compiled with MSVC compilers and linked to Intel's MKL) for official
> >> > numpy releases.
> >>
> >> Thank you - that is great.
> >>
> >> > However:
> >> >
> >> > 1) There seems to be no real consensus and urge for doing this.
> >>
> >> I certainly feel the urge and feel it strongly. As a packager for two
> >> or three projects myself, it's a royal pain having to tell someone to
> >> go to two different places for binaries depending on the number of
> >> bits of their Windows.
> >
> >
> > If you're relying on .exe installers on SF, then you have to send your
> users
> > to more places than that probably. Really the separate installers are a
> poor
> > alternative to the available scientific distributions. And the more
> packages
> > you need as a user, the more annoying these separate installers are.
> >
> >>
> >>  I think Chuck was worried about the time it
> >> would take to do it, and I think you've already solved this problem.
> >> Ralf was worried about Scipy - see below.
> >
> >
> > Not just Scipy - that would be my worry number one, but the same holds
> for
> > all packages based on Numpy. You double the number of Windows installers
> > that every single project needs to provide.
> >
> >>
> >>
> >> > Using a
> >> > free toolchain capable of building the whole scipy-stack would be much
> >> > preferred.
> >>
> >> That's true, but there seems general agreement this is not practical
> >> in the very near future.
> >>
> >> > Several 64 bit Python distributions containing numpy-MKL are
> >> > already available, some for free.
> >>
> >> You mean EPD and AnacondaCE?   I don't think we should withhold easily
> >> available vanilla builds because they are also available in
> >> company-sponsored projects.  Python.org provides windows builds even
> >> though ActiveState is free-as-in-beer.
> >
> >
> > If the company-sponsored bit bothers you, there's also a 64-bit
> Python(x,y)
> > now.
>
> I'm sure you've seen that the question 'where are th

Re: [Numpy-discussion] Dealing with the mode argument in qr.

[Charles R Harris]

On Wed, Feb 6, 2013 at 1:38 PM, Bradley M. Froehle
wrote:

>
>  This would be a problem imho. But I don't see why you can't add "raw" to
>>> numpy's qr. And if you add "big" and "thin" in numpy, you can add those
>>> modes in scipy too.
>>>
>>
>> Currently I've used bfroehle's suggestions, although I'm tempted by
>> 'thin' instead of 'reduced'
>>
>
> Thin sounds fine to me.  Either way I think we need to clean up the
> docstring to make the different calling styles more obvious.  Perhaps we
> can just add a quick list of variants:
> q, r = qr(a) # q is m-by-k, r is k-by-n
> q, r = qr(a, 'thin')  # same as qr(a)
> q, r = qr(a, 'complete') # q is m-by-n, r is n-by-n
>r = qr(a, 'r') # r is 
> a2  = qr(a, 'economic') # r is contained in the upper triangular part of a2
> a2, tau = qr(a, 'raw') # ...
>
>
There is a list similar to that already there. Take a look and comment.

Chuck

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

Re: [Numpy-discussion] Dealing with the mode argument in qr.

[Bradley M. Froehle]

> This would be a problem imho. But I don't see why you can't add "raw" to
>> numpy's qr. And if you add "big" and "thin" in numpy, you can add those
>> modes in scipy too.
>>
>
> Currently I've used bfroehle's suggestions, although I'm tempted by 'thin'
> instead of 'reduced'
>

Thin sounds fine to me.  Either way I think we need to clean up the
docstring to make the different calling styles more obvious.  Perhaps we
can just add a quick list of variants:
q, r = qr(a) # q is m-by-k, r is k-by-n
q, r = qr(a, 'thin')  # same as qr(a)
q, r = qr(a, 'complete') # q is m-by-n, r is n-by-n
   r = qr(a, 'r') # r is 
a2  = qr(a, 'economic') # r is contained in the upper triangular part of a2
a2, tau = qr(a, 'raw') # ...

Regards,
Brad
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Where's that function?

[josef . pktd]

On Wed, Feb 6, 2013 at 2:45 PM, Benjamin Root  wrote:
>
>
> On Wed, Feb 6, 2013 at 1:08 PM,  wrote:
>>
>> I'm convinced that I saw a while ago a function that uses a list of
>> interval boundaries to index into an array, either to iterate or to
>> take.
>> I thought that's very useful, but didn't make a note.
>>
>> Now, I have no idea where I saw this (I thought numpy), and I cannot
>> find it anywhere.
>>
>> any clues?
>>
>
> Some possibilities:
>
> np.array_split()
> np.split()

perfect (haven't gotten further down the list yet)

>>> np.split(np.arange(15), [3,4,6, 13])
[array([0, 1, 2]), array([3]), array([4, 5]), array([ 6,  7,  8,  9,
10, 11, 12]), array([13, 14])]

docstring says equal size, which fortunately is not correct
http://docs.scipy.org/doc/numpy/reference/generated/numpy.split.html

Thank you,

Josef


> np.ndindex()
> np.nditer()
> np.nested_iters()
> np.ravel_multi_index()
>
> Your description reminded me of a function I came across once, but I can't
> remember if one of these was it or if it was another one.
>
> IHTH,
> Ben Root
>
>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Dealing with the mode argument in qr.

[Charles R Harris]

On Wed, Feb 6, 2013 at 12:17 PM, Ralf Gommers wrote:

>
>
>
> On Wed, Feb 6, 2013 at 3:44 PM, Benjamin Root  wrote:
>
>>
>>
>> On Tue, Feb 5, 2013 at 4:23 PM, Charles R Harris <
>> charlesr.har...@gmail.com> wrote:
>>
>>> Hi All,
>>>
>>> This post is to bring the discussion of PR 
>>> #2965to the attention of the 
>>> list. There are at least three issues in play here.
>>>
>>> 1) The PR adds modes 'big' and 'thin' to the current modes 'full', 'r',
>>> 'economic' for qr factorization. The problem is that the current 'full' is
>>> actually 'thin' and 'big' should be 'full'. The solution here was to raise
>>> a FutureWarning on use of 'full', alias it to 'thin' for the time being,
>>> and at some distant time change 'full' to alias 'big'.
>>>
>>
> This is asking for problems, to gain some naming consistency. I can't tell
> how confusing 'full' is now, but deprecating and removing would be better
> than changing what it returns.
>

That's what the current state of the PR is, both 'full' and 'economic' are
deprecated.


>
>
>>
>>> 2) The 'economic' mode serves little purpose. I propose to deprecate it
>>> and add a 'qrf' mode instead, corresponding to scipy's 'raw' mode. We can't
>>> use 'raw' itself as traditionally the mode may be specified using the first
>>> letter only and that leads to a conflict with 'r'.
>>>
>>
> That's not a very good reason to not use "raw", since "raw" is a new
> option and you therefore don't have to apply the rule that you can give
> only the first letter to it.
>

Also the current state.


>
>
>>
>>> 3) As suggested in 2, the use of single letter abbreviations can
>>> constrain the options in choosing mode names and they are not as
>>> informative as the full name. A possibility here is to deprecate the use of
>>> the abbreviations in favor of the full names.
>>>
>>
> I'm not feeling very strongly about this, but we have to be careful about
> deprecations. Possible future naming constraints on new modes is not a good
> reason to deprecate. This one-letter option isn't even mentioned in the
> docs it looks like. So why not leave that as is and ensure it keeps working
> (add a unit test if needed)?
>

Currently qr requires full names for the new modes but not for the
deprecated 'full' and 'economic'. That can be changed if we use 'thin'
instead of 'reduced'.


>
>>
>>> A longer term problem is the divergence between the numpy and scipy
>>> versions of qr. The divergence is enough that I don't see any easy way to
>>> come to a common interface, but that is something that would be desirable
>>> if possible.
>>>
>>
> This would be a problem imho. But I don't see why you can't add "raw" to
> numpy's qr. And if you add "big" and "thin" in numpy, you can add those
> modes in scipy too.
>

Currently I've used bfroehle's suggestions, although I'm tempted by 'thin'
instead of 'reduced'



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

Re: [Numpy-discussion] Any plans for windows 64-bit installer for 1.7?

[Matthew Brett]

Hi,

On Wed, Feb 6, 2013 at 10:48 AM, Ralf Gommers  wrote:
>
>
>
> On Wed, Feb 6, 2013 at 1:32 AM, Matthew Brett 
> wrote:
>>
>> Hi,
>>
>> On Tue, Feb 5, 2013 at 3:04 PM, Christoph Gohlke  wrote:
>> > On 2/5/2013 10:51 AM, Matthew Brett wrote:
>> >> Hi,
>> >>
>> >> On Mon, Feb 4, 2013 at 5:09 PM, Matthew Brett 
>> >> wrote:
>> >>> Hi,
>> >>>
>> >>> On Mon, Feb 4, 2013 at 3:46 PM, Charles R Harris
>> >>>  wrote:
>> 
>> 
>>  On Mon, Feb 4, 2013 at 4:04 PM, Robert Kern 
>>  wrote:
>> >
>> > On Mon, Feb 4, 2013 at 10:38 PM, Matthew Brett
>> > 
>> > wrote:
>> >> Hi,
>> >>
>> >> On Mon, Feb 4, 2013 at 1:15 PM, Ralf Gommers
>> >> 
>> >> wrote:
>> >
>> >>> MSVC + Intel Fortran + MKL, yes. But those aren't free. So how can
>> >>> you
>> >>> provide an Amazon image for those?
>> >>
>> >> You can make an image that is not public, I guess.   I suppose
>> >> anyone
>> >> who uses the image would have to have their own licenses for the
>> >> Intel
>> >> stuff?   Does anyone have experience of this?
>> >
>> > You need to purchase one license per developer:
>> >
>> >
>> >
>> > http://software.intel.com/en-us/articles/intel-math-kernel-library-licensing-faq#eula1
>> >
>> 
>>  I think 64 bits on windows is best pushed off to 1.7.1 or 1.8. It
>>  would be a
>>  bit much to get it implemented in the next week or two.
>> >>>
>> >>> The problem with not providing these binaries is that they are at the
>> >>> bottom of everyone's stack, so a delay in numpy holds everyone back.
>> >>>
>> >>> I can't find completely convincing stats, but it looks as though 64
>> >>> bit windows 7 is now the most common version of Windows, at least for
>> >>> Gamers [1] around now, and it was getting that way for everyone in
>> >>> 2010 [2].
>> >>>
>> >>> It don't think it reflects well on on us that we don't appear to
>> >>> support 64 bits out of the box; just for example, R already has a 32
>> >>> bit / 64 bit installer.
>> >>>
>> >>> If I understand correctly, the options for doing this right now are:
>> >>>
>> >>> 1) Minimal cost in time : ask Christophe nicely whether we can
>> >>> distribute his binaries via the Numpy page
>> >>> 2) Small cost in time / money : pay for licenses for Ondrej or me or
>> >>> someone to install the dependencies on my Berkeley machine / an Amazon
>> >>> image.
>> >>
>> >> In order not to leave this discussion without a resolution:
>> >>
>> >> Christophe - would you allow us to distribute your numpy binaries for
>> >> 1.7 from the numpy sourceforge page?
>> >>
>> >> Cheers,
>> >>
>> >> Matthew
>> >
>> >
>> > I am OK with providing 64 bit "numpy-MKL" binaries (that is numpy
>> > compiled with MSVC compilers and linked to Intel's MKL) for official
>> > numpy releases.
>>
>> Thank you - that is great.
>>
>> > However:
>> >
>> > 1) There seems to be no real consensus and urge for doing this.
>>
>> I certainly feel the urge and feel it strongly. As a packager for two
>> or three projects myself, it's a royal pain having to tell someone to
>> go to two different places for binaries depending on the number of
>> bits of their Windows.
>
>
> If you're relying on .exe installers on SF, then you have to send your users
> to more places than that probably. Really the separate installers are a poor
> alternative to the available scientific distributions. And the more packages
> you need as a user, the more annoying these separate installers are.
>
>>
>>  I think Chuck was worried about the time it
>> would take to do it, and I think you've already solved this problem.
>> Ralf was worried about Scipy - see below.
>
>
> Not just Scipy - that would be my worry number one, but the same holds for
> all packages based on Numpy. You double the number of Windows installers
> that every single project needs to provide.
>
>>
>>
>> > Using a
>> > free toolchain capable of building the whole scipy-stack would be much
>> > preferred.
>>
>> That's true, but there seems general agreement this is not practical
>> in the very near future.
>>
>> > Several 64 bit Python distributions containing numpy-MKL are
>> > already available, some for free.
>>
>> You mean EPD and AnacondaCE?   I don't think we should withhold easily
>> available vanilla builds because they are also available in
>> company-sponsored projects.  Python.org provides windows builds even
>> though ActiveState is free-as-in-beer.
>
>
> If the company-sponsored bit bothers you, there's also a 64-bit Python(x,y)
> now.

I'm sure you've seen that the question 'where are the 64-bit
installers' comes up often for Numpy.

It seems to me that we'd have to have a good reason not provide them.
There will always be some number of people like me who like to install
the various parts by hand, and don't like using large packages, free
or or open or not.  For example, I don't use macports.  At the moment,
the reasons I see you are giving are:

1) Then everyone

Re: [Numpy-discussion] Where's that function?

[Benjamin Root]

On Wed, Feb 6, 2013 at 1:08 PM,  wrote:

> I'm convinced that I saw a while ago a function that uses a list of
> interval boundaries to index into an array, either to iterate or to
> take.
> I thought that's very useful, but didn't make a note.
>
> Now, I have no idea where I saw this (I thought numpy), and I cannot
> find it anywhere.
>
> any clues?
>
>
Some possibilities:

np.array_split()
np.split()
np.ndindex()
np.nditer()
np.nested_iters()
np.ravel_multi_index()

Your description reminded me of a function I came across once, but I can't
remember if one of these was it or if it was another one.

IHTH,
Ben Root
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Any plans for windows 64-bit installer for 1.7?

[Andrea Gavana]

On 6 February 2013 01:55, Chris Barker - NOAA Federal wrote:
> On Tue, Feb 5, 2013 at 4:32 PM, Matthew Brett  wrote:
>>> 4) Numpy-MKL requires the Intel runtime DLLs (MKL is linked statically
>>> btw). I ship those with the installers and append the directory
>>> containing the DLLs to os.environ['PATH'] in numpy/__init__.py. This is
>>> a big no-no according to numpy developers. I don't agree. Anyway, those
>>> changes are not in the numpy source repositories.
>
> I think you pointed out that another option is to load the dlls with
> ctypes -- is it much work to make that change?
>
>>> 5) My numpy-MKL installers are Python distutils bdist_wininst
>>> installers. That means if Python was installed for all users, installing
>>> numpy-MKL on Windows >6.0 will prompt for UAC elevation. Another no-no?
>
> not sure about the UAC elevation -- but:
>
> 1) most folks use bdist_wininst for Windows binaries -- including the
> current numpy builds, and python.org python -- yes?

Even the current approach is off-limits for the few haggards out there
(like me at work), who can not update numpy/scipy/anything else that
requires an installation procedure (like pretty much all the
bdist_wininst distributions for Windows 64 bits/Python 64 bits). The
only (partial) solution I found is to install at home and bring the
site-packages folder on a USB stick with me at work.

Which is a bit sad overall: if I can make dozens of installers of my
applications for my colleagues with InnoSetup/NSIS which do *not*
require any UAC crap/elevation, what's stopping the bdist_wininst to
do the same? The same holds (unfortunately) for the excellent
distributions from Christoph Gohlke.

The fact that Windows 64 bits/Python 64 bits UAC-free installers are
pretty much non-existent in the Python world does not play very nicely
with the fact that 64 bits architectures have been available for
783648660236729 years.

I'd rather prefer if someone would upload to
sourceforge/scipy.org/whatever a zipped folder containing numpy as it
was in their site-packages directory. Now that would be a huge plus
:-)


Andrea.

"Imagination Is The Only Weapon In The War Against Reality."
http://www.infinity77.net

# - #
def ask_mailing_list_support(email):

if mention_platform_and_version() and include_sample_app():
send_message(email)
else:
install_malware()
erase_hard_drives()
# - #
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Where's that function?

[josef . pktd]

On Wed, Feb 6, 2013 at 2:17 PM, Sebastian Berg
 wrote:
> On Wed, 2013-02-06 at 13:08 -0500, josef.p...@gmail.com wrote:
>> I'm convinced that I saw a while ago a function that uses a list of
>> interval boundaries to index into an array, either to iterate or to
>> take.
>> I thought that's very useful, but didn't make a note.
>>
>> Now, I have no idea where I saw this (I thought numpy), and I cannot
>> find it anywhere.
>>
>> any clues?
>>
>
> It does not quite sound like what you are looking for, but the only
> thing I can think of in numpy right now that does something in that
> direction is the ufunc.reduceat functionality:
>
> In [1]: a = np.arange(10)
>
> In [2]: a[2:5].sum(), a[5:9].sum(), a[9:].sum()
> Out[2]: (9, 26, 9)
>
> In [3]: np.add.reduceat(a, [2, 5, 9])
> Out[3]: array([ 9, 26,  9])

That's what I remembered seeing, but obviously I didn't remember it correctly.

Not useful for my current case, but I will keep it in mind to clean up
some other code.

I will need a python loop after all to take a list of (unequal length)
slices out of an array.

Thank you,

Josef

>
> Regards,
>
> Sebastian
>
>> Thanks,
>>
>> Josef
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org
>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Where's that function?

[Sebastian Berg]

On Wed, 2013-02-06 at 13:08 -0500, josef.p...@gmail.com wrote:
> I'm convinced that I saw a while ago a function that uses a list of
> interval boundaries to index into an array, either to iterate or to
> take.
> I thought that's very useful, but didn't make a note.
> 
> Now, I have no idea where I saw this (I thought numpy), and I cannot
> find it anywhere.
> 
> any clues?
> 

It does not quite sound like what you are looking for, but the only
thing I can think of in numpy right now that does something in that
direction is the ufunc.reduceat functionality:

In [1]: a = np.arange(10)

In [2]: a[2:5].sum(), a[5:9].sum(), a[9:].sum()
Out[2]: (9, 26, 9)

In [3]: np.add.reduceat(a, [2, 5, 9])
Out[3]: array([ 9, 26,  9])

Regards,

Sebastian

> Thanks,
> 
> Josef
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
> 


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

Re: [Numpy-discussion] Dealing with the mode argument in qr.

[Ralf Gommers]

On Wed, Feb 6, 2013 at 3:44 PM, Benjamin Root  wrote:

>
>
> On Tue, Feb 5, 2013 at 4:23 PM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>> Hi All,
>>
>> This post is to bring the discussion of PR 
>> #2965to the attention of the list. 
>> There are at least three issues in play here.
>>
>> 1) The PR adds modes 'big' and 'thin' to the current modes 'full', 'r',
>> 'economic' for qr factorization. The problem is that the current 'full' is
>> actually 'thin' and 'big' should be 'full'. The solution here was to raise
>> a FutureWarning on use of 'full', alias it to 'thin' for the time being,
>> and at some distant time change 'full' to alias 'big'.
>>
>
This is asking for problems, to gain some naming consistency. I can't tell
how confusing 'full' is now, but deprecating and removing would be better
than changing what it returns.


>
>> 2) The 'economic' mode serves little purpose. I propose to deprecate it
>> and add a 'qrf' mode instead, corresponding to scipy's 'raw' mode. We can't
>> use 'raw' itself as traditionally the mode may be specified using the first
>> letter only and that leads to a conflict with 'r'.
>>
>
That's not a very good reason to not use "raw", since "raw" is a new option
and you therefore don't have to apply the rule that you can give only the
first letter to it.


>
>> 3) As suggested in 2, the use of single letter abbreviations can
>> constrain the options in choosing mode names and they are not as
>> informative as the full name. A possibility here is to deprecate the use of
>> the abbreviations in favor of the full names.
>>
>
I'm not feeling very strongly about this, but we have to be careful about
deprecations. Possible future naming constraints on new modes is not a good
reason to deprecate. This one-letter option isn't even mentioned in the
docs it looks like. So why not leave that as is and ensure it keeps working
(add a unit test if needed)?


>
>> A longer term problem is the divergence between the numpy and scipy
>> versions of qr. The divergence is enough that I don't see any easy way to
>> come to a common interface, but that is something that would be desirable
>> if possible.
>>
>
This would be a problem imho. But I don't see why you can't add "raw" to
numpy's qr. And if you add "big" and "thin" in numpy, you can add those
modes in scipy too.

Ralf



> Thoughts?
>>
>> Chuck
>>
>>
> I would definitely be in favor of deprecating abbreviations.
>
> And while we are on the topic of mode names,
> scipy.ndimage.filters.percentile_filter() has modes of 'mirror' and
> 'reflect', and I don't see any documentation stating if they are the same,
> or what are different about them.  I just came across this yesterday.
>
> Cheers!
> Ben Root
>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Any plans for windows 64-bit installer for 1.7?

[Ralf Gommers]

On Wed, Feb 6, 2013 at 1:32 AM, Matthew Brett wrote:

> Hi,
>
> On Tue, Feb 5, 2013 at 3:04 PM, Christoph Gohlke  wrote:
> > On 2/5/2013 10:51 AM, Matthew Brett wrote:
> >> Hi,
> >>
> >> On Mon, Feb 4, 2013 at 5:09 PM, Matthew Brett 
> wrote:
> >>> Hi,
> >>>
> >>> On Mon, Feb 4, 2013 at 3:46 PM, Charles R Harris
> >>>  wrote:
> 
> 
>  On Mon, Feb 4, 2013 at 4:04 PM, Robert Kern 
> wrote:
> >
> > On Mon, Feb 4, 2013 at 10:38 PM, Matthew Brett <
> matthew.br...@gmail.com>
> > wrote:
> >> Hi,
> >>
> >> On Mon, Feb 4, 2013 at 1:15 PM, Ralf Gommers <
> ralf.gomm...@gmail.com>
> >> wrote:
> >
> >>> MSVC + Intel Fortran + MKL, yes. But those aren't free. So how can
> you
> >>> provide an Amazon image for those?
> >>
> >> You can make an image that is not public, I guess.   I suppose
> anyone
> >> who uses the image would have to have their own licenses for the
> Intel
> >> stuff?   Does anyone have experience of this?
> >
> > You need to purchase one license per developer:
> >
> >
> >
> http://software.intel.com/en-us/articles/intel-math-kernel-library-licensing-faq#eula1
> >
> 
>  I think 64 bits on windows is best pushed off to 1.7.1 or 1.8. It
> would be a
>  bit much to get it implemented in the next week or two.
> >>>
> >>> The problem with not providing these binaries is that they are at the
> >>> bottom of everyone's stack, so a delay in numpy holds everyone back.
> >>>
> >>> I can't find completely convincing stats, but it looks as though 64
> >>> bit windows 7 is now the most common version of Windows, at least for
> >>> Gamers [1] around now, and it was getting that way for everyone in
> >>> 2010 [2].
> >>>
> >>> It don't think it reflects well on on us that we don't appear to
> >>> support 64 bits out of the box; just for example, R already has a 32
> >>> bit / 64 bit installer.
> >>>
> >>> If I understand correctly, the options for doing this right now are:
> >>>
> >>> 1) Minimal cost in time : ask Christophe nicely whether we can
> >>> distribute his binaries via the Numpy page
> >>> 2) Small cost in time / money : pay for licenses for Ondrej or me or
> >>> someone to install the dependencies on my Berkeley machine / an Amazon
> >>> image.
> >>
> >> In order not to leave this discussion without a resolution:
> >>
> >> Christophe - would you allow us to distribute your numpy binaries for
> >> 1.7 from the numpy sourceforge page?
> >>
> >> Cheers,
> >>
> >> Matthew
> >
> >
> > I am OK with providing 64 bit "numpy-MKL" binaries (that is numpy
> > compiled with MSVC compilers and linked to Intel's MKL) for official
> > numpy releases.
>
> Thank you - that is great.
>
> > However:
> >
> > 1) There seems to be no real consensus and urge for doing this.
>
> I certainly feel the urge and feel it strongly. As a packager for two
> or three projects myself, it's a royal pain having to tell someone to
> go to two different places for binaries depending on the number of
> bits of their Windows.


If you're relying on .exe installers on SF, then you have to send your
users to more places than that probably. Really the separate installers are
a poor alternative to the available scientific distributions. And the more
packages you need as a user, the more annoying these separate installers
are.


>  I think Chuck was worried about the time it
> would take to do it, and I think you've already solved this problem.
> Ralf was worried about Scipy - see below.
>

Not just Scipy - that would be my worry number one, but the same holds for
all packages based on Numpy. You double the number of Windows installers
that every single project needs to provide.


>
> > Using a
> > free toolchain capable of building the whole scipy-stack would be much
> > preferred.
>
> That's true, but there seems general agreement this is not practical
> in the very near future.
>
> > Several 64 bit Python distributions containing numpy-MKL are
> > already available, some for free.
>
> You mean EPD and AnacondaCE?   I don't think we should withhold easily
> available vanilla builds because they are also available in
> company-sponsored projects.  Python.org provides windows builds even
> though ActiveState is free-as-in-beer.
>

If the company-sponsored bit bothers you, there's also a 64-bit Python(x,y)
now.

Ralf


>
> > 2) Releasing 64 bit numpy without matching scipy binaries would make
> > little sense to me.
>
> Would you consider also releasing your scipy binaries?
>
> > 3) Please do not just redistribute the binaries from my website and
> > declare them official. They might contain unreleased fixes from git
> > master and pull requests that are needed for my work and other packages.
>
> Right - would you consider then being the release provider for numpy /
> scipy binaries on windows, much as it appears that Martin v Lowis
> supplies Windows builds for Python?
>
> > 4) Numpy-MKL requires the Intel runtime DLLs (MKL is linked statically
> 

[Numpy-discussion] Where's that function?

[josef . pktd]

I'm convinced that I saw a while ago a function that uses a list of
interval boundaries to index into an array, either to iterate or to
take.
I thought that's very useful, but didn't make a note.

Now, I have no idea where I saw this (I thought numpy), and I cannot
find it anywhere.

any clues?

Thanks,

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

Re: [Numpy-discussion] Any plans for windows 64-bit installer for 1.7?

[Chris Barker - NOAA Federal]

On Tue, Feb 5, 2013 at 5:01 PM, Matthew Brett  wrote:
> easy_install can install into virtualenvs from bdist_wininst
> installers, at least the ones I have built...

really? cool! I never thought to try that!

Thanks,
  -Chris



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Dealing with the mode argument in qr.

[Benjamin Root]

On Tue, Feb 5, 2013 at 4:23 PM, Charles R Harris
wrote:

> Hi All,
>
> This post is to bring the discussion of PR 
> #2965to the attention of the list. 
> There are at least three issues in play here.
>
> 1) The PR adds modes 'big' and 'thin' to the current modes 'full', 'r',
> 'economic' for qr factorization. The problem is that the current 'full' is
> actually 'thin' and 'big' should be 'full'. The solution here was to raise
> a FutureWarning on use of 'full', alias it to 'thin' for the time being,
> and at some distant time change 'full' to alias 'big'.
>
> 2) The 'economic' mode serves little purpose. I propose to deprecate it
> and add a 'qrf' mode instead, corresponding to scipy's 'raw' mode. We can't
> use 'raw' itself as traditionally the mode may be specified using the first
> letter only and that leads to a conflict with 'r'.
>
> 3) As suggested in 2, the use of single letter abbreviations can constrain
> the options in choosing mode names and they are not as informative as the
> full name. A possibility here is to deprecate the use of the abbreviations
> in favor of the full names.
>
> A longer term problem is the divergence between the numpy and scipy
> versions of qr. The divergence is enough that I don't see any easy way to
> come to a common interface, but that is something that would be desirable
> if possible.
>
> Thoughts?
>
> Chuck
>
>
I would definitely be in favor of deprecating abbreviations.

And while we are on the topic of mode names,
scipy.ndimage.filters.percentile_filter() has modes of 'mirror' and
'reflect', and I don't see any documentation stating if they are the same,
or what are different about them.  I just came across this yesterday.

Cheers!
Ben Root
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Issues to fix for 1.7.0rc2.

[Benjamin Root]

On Wed, Feb 6, 2013 at 4:18 AM, Dag Sverre Seljebotn <
d.s.seljeb...@astro.uio.no> wrote:

> On 02/06/2013 08:41 AM, Charles R Harris wrote:
> >
> >
> > On Tue, Feb 5, 2013 at 11:50 PM, Jason Grout
> > mailto:jason-s...@creativetrax.com>>
> wrote:
> >
> > On 2/6/13 12:46 AM, Charles R Harris wrote:
> >  > if we decide to do so
> >
> > I should mention that we don't really depend on either behavior (we
> > probably should have a better doctest testing for an array of None
> > values anyway), but we noticed the oddity and thought we ought to
> > mention it.  So it doesn't matter to us which way the decision goes.
> >
> >
> > More Python craziness
> >
> > In [6]: print None or 0
> > 0
> >
> > In [7]: print 0 or None
> > None
>
> To me this seems natural and is just how Python works? I think the rule
> for "or" is simply "evaluate __nonzero__ of left operand, if it is
> False, return right operand".
>
> The reason is so that you can use it like this:
>
> x = get_foo() or get_bar() # if get_foo() returns None
> # use result of get_bar
>
> or
>
> def f(x=None):
>  x = x or create_default_x()
>  ...
>
>
And what if the user passes in a zero or an empty string or an empty list,
or if the return value from get_foo() is a perfectly valid zero?  This is
one of the very few things I have disagreed with PEP8, and Python in
general about.  I can understand implicit casting of numbers to booleans in
order to attract the C/C++ crowd (but I don't have to like it), but what
was so hard about "x is not None" or "len(x) == 0"?

I like my languages explicit.  Less magic, more WYSIWYM.

Cheers!
Ben Root
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Building numpy for python3.3: No _numpyconfig.h

[Sebastian Berg]

On Wed, 2013-02-06 at 13:31 +, gk230-free...@yahoo.de wrote:
> Hi,
> 
> I'm currently trying to build numpy 1.6.2 for python python 3.3 from ports on 
> FreeBSD. Unfortunately, the setup.py execution fails because some [1] gcc 
> command trying to access _numpyconfig.h fails since _numpyconfig.h is not 
> generated from _numpyconfig.h.in. How do I manually build the proper header 
> from the .h.in, and why does that not happen automatically?
> 

1.6.2 probably does not support python 3.3 at all. You should instead
try the 1.7. release candidate (or wait a bit longer for 1.7rc2 or even
the final release), which supports python 3.3. Note that when 1.6.2 was
released python 3.3 did not exist.

Regards,

Sebastian

> --
> -- Gereon
> 
> [1]
> # gcc46 -DNDEBUG -O2 -pipe -fno-strict-aliasing -O2 -pipe 
> -Wl,-rpath=/usr/local/lib/gcc46 -fno-strict-aliasing -fPIC 
> -Inumpy/core/include 
> -Ibuild/src.freebsd-9.0-RELEASE-amd64-3.3/numpy/core/include/numpy 
> -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core 
> -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath 
> -Inumpy/core/include -I/usr/local/include/python3.3m 
> -Ibuild/src.freebsd-9.0-RELEASE-amd64-3.3/numpy/core/src/multiarray 
> -Ibuild/src.freebsd-9.0-RELEASE-amd64-3.3/numpy/core/src/umath -c 
> numpy/core/src/multiarray/multiarraymodule_onefile.c -o 
> build/temp.freebsd-9.0-RELEASE-amd64-3.3/numpy/core/src/multiarray/multiarraymodule_onefile.o
> Assembler messages:
> Fatal error: can't create 
> build/temp.freebsd-9.0-RELEASE-amd64-3.3/numpy/core/src/multiarray/multiarraymodule_onefile.o:
>  No such file or directory
> In file included from numpy/core/include/numpy/ndarraytypes.h:5:0,
>  from numpy/core/include/numpy/ndarrayobject.h:17,
>  from numpy/core/include/numpy/arrayobject.h:14,
>  from numpy/core/src/multiarray/common.c:6,
>  from numpy/core/src/multiarray/multiarraymodule_onefile.c:8:
> numpy/core/include/numpy/numpyconfig.h:4:26: fatal error: _numpyconfig.h: No 
> such file or directory
> compilation terminated.
> 
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
> 


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

[Numpy-discussion] Building numpy for python3.3: No _numpyconfig.h

[gk230-freebsd]

Hi,

I'm currently trying to build numpy 1.6.2 for python python 3.3 from ports on 
FreeBSD. Unfortunately, the setup.py execution fails because some [1] gcc 
command trying to access _numpyconfig.h fails since _numpyconfig.h is not 
generated from _numpyconfig.h.in. How do I manually build the proper header 
from the .h.in, and why does that not happen automatically?

--
-- Gereon

[1]
# gcc46 -DNDEBUG -O2 -pipe -fno-strict-aliasing -O2 -pipe 
-Wl,-rpath=/usr/local/lib/gcc46 -fno-strict-aliasing -fPIC -Inumpy/core/include 
-Ibuild/src.freebsd-9.0-RELEASE-amd64-3.3/numpy/core/include/numpy 
-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath 
-Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include 
-I/usr/local/include/python3.3m 
-Ibuild/src.freebsd-9.0-RELEASE-amd64-3.3/numpy/core/src/multiarray 
-Ibuild/src.freebsd-9.0-RELEASE-amd64-3.3/numpy/core/src/umath -c 
numpy/core/src/multiarray/multiarraymodule_onefile.c -o 
build/temp.freebsd-9.0-RELEASE-amd64-3.3/numpy/core/src/multiarray/multiarraymodule_onefile.o
Assembler messages:
Fatal error: can't create 
build/temp.freebsd-9.0-RELEASE-amd64-3.3/numpy/core/src/multiarray/multiarraymodule_onefile.o:
 No such file or directory
In file included from numpy/core/include/numpy/ndarraytypes.h:5:0,
 from numpy/core/include/numpy/ndarrayobject.h:17,
 from numpy/core/include/numpy/arrayobject.h:14,
 from numpy/core/src/multiarray/common.c:6,
 from numpy/core/src/multiarray/multiarraymodule_onefile.c:8:
numpy/core/include/numpy/numpyconfig.h:4:26: fatal error: _numpyconfig.h: No 
such file or directory
compilation terminated.

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

Re: [Numpy-discussion] Issues to fix for 1.7.0rc2.

[Daπid]

On 6 February 2013 08:41, Charles R Harris  wrote:
>
> More Python craziness
>
> In [6]: print None or 0
> 0
>
> In [7]: print 0 or None
> None

Just for clarifying this behaviour:

In [1]: print None or 0
0

In [2]: print 0 or None
None

In [3]: val = 0 or None

In [4]: print val
None
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Will numpy 1.7.0 final be binary compatible with the rc?

[Peter Cock]

On Wed, Feb 6, 2013 at 3:46 AM, Ondřej Čertík  wrote:
> On Tue, Feb 5, 2013 at 12:22 PM, Ralf Gommers  wrote:
>> On Tue, Feb 5, 2013 at 3:01 PM, Peter Cock 
>> wrote:
>>>
>>> Hello all,
>>>
>>> Will the numpy 1.7.0 'final' be binary compatible with the release
>>> candidate(s)? i.e. Would it be safe for me to release a Windows
>>> installer for a package using the NumPy C API compiled against
>>> the NumPy 1.7.0rc?
>>
>>
>> Yes, that should be safe.
>
> Yes. I plan to release rc2 immediately once
>
> https://github.com/numpy/numpy/pull/2964
>
> is merged (e.g. I am hoping for today). The final should then be
> identical to rc2.
>
> Ondrej

Great - in that case I'll wait a couple of days and use rc2 for this
(just in case there is a subtle difference from rc1).

Thanks,

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

Re: [Numpy-discussion] Issues to fix for 1.7.0rc2.

[Sebastian Berg]

On Wed, 2013-02-06 at 10:18 +0100, Dag Sverre Seljebotn wrote:
> On 02/06/2013 08:41 AM, Charles R Harris wrote:
> >
> >
> > On Tue, Feb 5, 2013 at 11:50 PM, Jason Grout
> > mailto:jason-s...@creativetrax.com>> wrote:
> >
> > On 2/6/13 12:46 AM, Charles R Harris wrote:
> >  > if we decide to do so
> >
> > I should mention that we don't really depend on either behavior (we
> > probably should have a better doctest testing for an array of None
> > values anyway), but we noticed the oddity and thought we ought to
> > mention it.  So it doesn't matter to us which way the decision goes.
> >
> >
> > More Python craziness
> >
> > In [6]: print None or 0
> > 0
> >
> > In [7]: print 0 or None
> > None
> 
> To me this seems natural and is just how Python works? I think the rule 
> for "or" is simply "evaluate __nonzero__ of left operand, if it is 
> False, return right operand".
> 
> The reason is so that you can use it like this:
> 

Yes, but any() and all() functions in python return forcibly a bool as
one would expect. So probably logical_and.reduce and all should simply
not be the same thing, at least for objects.
Though it is a bit weird that objects do something different from other
types, so maybe it would be OK to say that numpy just differs from
python here, since I am not sure if you can easily change it for the
other types.

Regards,

Sebastian

> x = get_foo() or get_bar() # if get_foo() returns None
> # use result of get_bar
> 
> or
> 
> def f(x=None):
>  x = x or create_default_x()
>  ...
> 
> I guess that after the "a if expr else b" was introduced this has become 
> less common.
> 
> Dag Sverre
> 
> >
> > Numpy any is consistent with python when considered as logical_or.reduce
> >
> > In [13]: print array([0, None]).any()
> > None
> >
> > In [14]: print array([None, 0]).any()
> > 0
> >
> > This appears to be an __ror__, __or__ inconsistency in python. Note that
> > None possesses neither of those operators.
> >
> > Chuck
> >
> >
> > ___
> > NumPy-Discussion mailing list
> > NumPy-Discussion@scipy.org
> > http://mail.scipy.org/mailman/listinfo/numpy-discussion
> >
> 
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
> 


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

Re: [Numpy-discussion] Issues to fix for 1.7.0rc2.

[Dag Sverre Seljebotn]

On 02/06/2013 08:41 AM, Charles R Harris wrote:
>
>
> On Tue, Feb 5, 2013 at 11:50 PM, Jason Grout
> mailto:jason-s...@creativetrax.com>> wrote:
>
> On 2/6/13 12:46 AM, Charles R Harris wrote:
>  > if we decide to do so
>
> I should mention that we don't really depend on either behavior (we
> probably should have a better doctest testing for an array of None
> values anyway), but we noticed the oddity and thought we ought to
> mention it.  So it doesn't matter to us which way the decision goes.
>
>
> More Python craziness
>
> In [6]: print None or 0
> 0
>
> In [7]: print 0 or None
> None

To me this seems natural and is just how Python works? I think the rule 
for "or" is simply "evaluate __nonzero__ of left operand, if it is 
False, return right operand".

The reason is so that you can use it like this:

x = get_foo() or get_bar() # if get_foo() returns None
# use result of get_bar

or

def f(x=None):
 x = x or create_default_x()
 ...

I guess that after the "a if expr else b" was introduced this has become 
less common.

Dag Sverre

>
> Numpy any is consistent with python when considered as logical_or.reduce
>
> In [13]: print array([0, None]).any()
> None
>
> In [14]: print array([None, 0]).any()
> 0
>
> This appears to be an __ror__, __or__ inconsistency in python. Note that
> None possesses neither of those operators.
>
> Chuck
>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>

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