Re: [Numpy-discussion] Changes to np.digitize since NumPy 1.9?

[Jaime Fernández del Río]

On Wed, Aug 12, 2015 at 2:03 PM, Nathan Goldbaum 
wrote:

> Hi all,
>
> I've been testing the package I spend most of my time on, yt, under numpy
> 1.10b1 since the announcement went out.
>
> I think I've narrowed down and fixed all of the test failures that cropped
> up except for one last issue. It seems that the behavior of np.digitize
> with respect to ndarray subclasses has changed since the NumPy 1.9 series.
> Consider the following test script:
>
> ```python
> import numpy as np
>
>
> class MyArray(np.ndarray):
> def __new__(cls, *args, **kwargs):
> return np.ndarray.__new__(cls, *args, **kwargs)
>
> data = np.arange(100)
>
> bins = np.arange(100) + 0.5
>
> data = data.view(MyArray)
>
> bins = bins.view(MyArray)
>
> digits = np.digitize(data, bins)
>
> print type(digits)
> ```
>
> Under NumPy 1.9.2, this prints "", but under the
> 1.10 beta, it prints ""
>
> I'm curious why this change was made. Since digitize outputs index arrays,
> it doesn't make sense to me why it should return anything but a plain
> ndarray. I see in the release notes that digitize now uses searchsorted
> under the hood. Is this related?
>

It is indeed searchsorted's fault, as it returns an object of the same type
as the needle (the items to search for):

>>> import numpy as np
>>> class A(np.ndarray): pass
>>> class B(np.ndarray): pass
>>> np.arange(10).view(A).searchsorted(np.arange(5).view(B))
B([0, 1, 2, 3, 4])

I am all for making index-returning functions always return a base ndarray,
and will be more than happy to send a PR fixing this if there is some
agreement.

Jaime

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

Re: [Numpy-discussion] Changes to np.digitize since NumPy 1.9?

[Nathaniel Smith]

On Aug 12, 2015 2:06 PM, "Nathan Goldbaum"  wrote:
>
> Hi all,
>
> I've been testing the package I spend most of my time on, yt, under numpy 
> 1.10b1 since the announcement went out.
>
> I think I've narrowed down and fixed all of the test failures that cropped up 
> except for one last issue.

This doesn't respond to your main question -- sorry! -- but is there a
list of the changes you had to make somewhere? We generally do want to
know when we break things -- that's why we do pre-releases! -- but
it's often hard to know :-).

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

Re: [Numpy-discussion] f2py and callbacks with variables

[Casey Deen]

Hi Pearu-

   Thanks so much!  This works!  Can you point me to a reference for the
format of the .pyf files?  My ~day of searching found a few pages on the
scipy website, but nothing which went into this amount of detail.

I also asked Stackoverflow, and unless you object, I'd like to add your
explanation and mark it as SOLVED for future poor souls wrestling with
this problem.  I'll also update the github repository with before and
after versions of the .pyf file.

Cheers,
Casey

On 08/12/2015 09:34 PM, Pearu Peterson wrote:
> Hi Casey,
> 
> What you observe, is not a f2py bug. When f2py sees a code like
> 
> subroutine foo
>   call bar
> end subroutine foo
> 
> then it will not make an attempt to analyze bar because of implicit
> assumption that all statements that has no references to foo arguments
> are irrelevant for wrapper function generation.
> For your example, f2py needs some help. Try the following signature in
> .pyf file:
> 
> subroutine barney ! in :flintstone:nocallback.f
> use test__user__routines, fred=>fred, bambam=>bambam
> intent(callback, hide) fred
> external fred
> intent(callback,hide) bambam
> external bambam
> end subroutine barney
> 
> Btw, instead of
> 
>   f2py -c -m flintstone flintstone.pyf callback.f nocallback.f
> 
> use
> 
>   f2py -c flintstone.pyf callback.f nocallback.f
> 
> because module name comes from the .pyf file.
> 
> HTH,
> Pearu
> 
> On Wed, Aug 12, 2015 at 7:12 PM, Casey Deen  > wrote:
> 
> Hi all-
> 
>I've run into what I think might be a bug in f2py and callbacks to
> python.  Or, maybe I'm not using things correctly.  I have created a
> very minimal example which illustrates my problem at:
> 
> https://github.com/soylentdeen/fluffy-kumquat
> 
> The issue seems to affect call backs with variables, but only when they
> are called indirectly (i.e. from other fortran routines).  For example,
> if I have a python function
> 
> def show_number(n):
> print("%d" % n)
> 
> and I setup a callback in a fortran routine:
> 
>   subroutine cb
> cf2py intent(callback, hide) blah
>   external blah
>   call blah(5)
>   end
> 
> and connect it to the python routine
> fortranObject.blah = show_number
> 
> I can successfully call the cb routine from python:
> 
> >fortranObject.cb
> 5
> 
> However, if I call the cb routine from within another fortran routine,
> it seems to lose its marbles
> 
>   subroutine no_cb
>   call cb
>   end
> 
> capi_return is NULL
> Call-back cb_blah_in_cb__user__routines failed.
> 
> For more information, please have a look at the github repository.  I've
> reproduced the behavior on both linux and mac.  I'm not sure if this is
> an error in the way I'm using the code, or if it is an actual bug.  Any
> and all help would be very much appreciated.
> 
> Cheers,
> Casey
> 
> 
> --
> Dr. Casey Deen
> Post-doctoral Researcher
> d...@mpia.de  
>  +49-6221-528-375 
> Max Planck Institut für Astronomie (MPIA)
> Königstuhl 17  D-69117 Heidelberg, Germany
> ___
> 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
> 

-- 
Dr. Casey Deen
Post-doctoral Researcher
d...@mpia.de   +49-6221-528-375
Max Planck Institut für Astronomie (MPIA)
Königstuhl 17  D-69117 Heidelberg, Germany
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Problems using add_npy_pkg_config

[Eric Firing]

I used to use scons, but I've been pretty happy with switching to waf.
(Very limited use in both cases: two relatively simple packages.)  One
of the nicest things is how light it is--no external dependencies,
everything can be included in the package itself.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Changes to np.digitize since NumPy 1.9?

[Nathan Goldbaum]

Hi all,

I've been testing the package I spend most of my time on, yt, under numpy
1.10b1 since the announcement went out.

I think I've narrowed down and fixed all of the test failures that cropped
up except for one last issue. It seems that the behavior of np.digitize
with respect to ndarray subclasses has changed since the NumPy 1.9 series.
Consider the following test script:

```python
import numpy as np


class MyArray(np.ndarray):
def __new__(cls, *args, **kwargs):
return np.ndarray.__new__(cls, *args, **kwargs)

data = np.arange(100)

bins = np.arange(100) + 0.5

data = data.view(MyArray)

bins = bins.view(MyArray)

digits = np.digitize(data, bins)

print type(digits)
```

Under NumPy 1.9.2, this prints "", but under the 1.10
beta, it prints ""

I'm curious why this change was made. Since digitize outputs index arrays,
it doesn't make sense to me why it should return anything but a plain
ndarray. I see in the release notes that digitize now uses searchsorted
under the hood. Is this related?

We can "fix" this in our codebase by wrapping digitize or by adding numpy
version checks in places where the output type matters. Is it also possible
for me to customize the return type here by exploiting the ufunc machinery
and the __array_wrap__ and __array_finalize__ functions?

Thanks for any help or advice you might have,

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

Re: [Numpy-discussion] Problems using add_npy_pkg_config

[Edison Gustavo Muenz]

Why don't you use CMake ? It's pretty standard for C/C++.

On Wed, Aug 12, 2015 at 2:35 PM, Ralf Gommers 
wrote:

>
>
> On Wed, Aug 12, 2015 at 7:23 PM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>>
>>
>> On Wed, Aug 12, 2015 at 10:50 AM, Ralf Gommers 
>> wrote:
>>
>>>
>>>
>>> On Wed, Aug 12, 2015 at 6:23 PM, Christian Engwer <
>>> christian.eng...@uni-muenster.de> wrote:
>>>
 Dear all,

 I'm trying to use the numpy distutils to install native C
 libraries. These are part of a larger roject and should be usable
 standalone. I managed to install headers and libs, but now I
 experience problems writing the corresponding pkg file. I first tried
 to do the trick without numpy, but getting all the pathes right in all
 different setups is really a mess.

>>>
>>> This doesn't answer your question but: why? If you're not distributing a
>>> Python project, there is no reason to use distutils instead of a sane build
>>> system.
>>>
>>
>> Believe it or not, distutils *is* one of the saner build systems when you
>> want something cross platform. Sad, isn't it...
>>
>
> Come on. We don't take it seriously, and neither do the Python core devs.
> It's also pretty much completely unsupported. Numpy.distutils is a bit
> better in that respect than Python distutils, which doesn't even get sane
> patches merged.
>
> Try Scons, Tup, Gradle, Shake, Waf or anything else that's at least
> somewhat modern and supported. Do not use numpy.distutils unless there's no
> other mature choice (i.e. you're developing a Python project).
>
> Ralf
>
>
>
> ___
> 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] f2py and callbacks with variables

[Pearu Peterson]

Hi Casey,

What you observe, is not a f2py bug. When f2py sees a code like

subroutine foo
  call bar
end subroutine foo

then it will not make an attempt to analyze bar because of implicit
assumption that all statements that has no references to foo arguments are
irrelevant for wrapper function generation.
For your example, f2py needs some help. Try the following signature in .pyf
file:

subroutine barney ! in :flintstone:nocallback.f
use test__user__routines, fred=>fred, bambam=>bambam
intent(callback, hide) fred
external fred
intent(callback,hide) bambam
external bambam
end subroutine barney

Btw, instead of

  f2py -c -m flintstone flintstone.pyf callback.f nocallback.f

use

  f2py -c flintstone.pyf callback.f nocallback.f

because module name comes from the .pyf file.

HTH,
Pearu

On Wed, Aug 12, 2015 at 7:12 PM, Casey Deen  wrote:

> Hi all-
>
>I've run into what I think might be a bug in f2py and callbacks to
> python.  Or, maybe I'm not using things correctly.  I have created a
> very minimal example which illustrates my problem at:
>
> https://github.com/soylentdeen/fluffy-kumquat
>
> The issue seems to affect call backs with variables, but only when they
> are called indirectly (i.e. from other fortran routines).  For example,
> if I have a python function
>
> def show_number(n):
> print("%d" % n)
>
> and I setup a callback in a fortran routine:
>
>   subroutine cb
> cf2py intent(callback, hide) blah
>   external blah
>   call blah(5)
>   end
>
> and connect it to the python routine
> fortranObject.blah = show_number
>
> I can successfully call the cb routine from python:
>
> >fortranObject.cb
> 5
>
> However, if I call the cb routine from within another fortran routine,
> it seems to lose its marbles
>
>   subroutine no_cb
>   call cb
>   end
>
> capi_return is NULL
> Call-back cb_blah_in_cb__user__routines failed.
>
> For more information, please have a look at the github repository.  I've
> reproduced the behavior on both linux and mac.  I'm not sure if this is
> an error in the way I'm using the code, or if it is an actual bug.  Any
> and all help would be very much appreciated.
>
> Cheers,
> Casey
>
>
> --
> Dr. Casey Deen
> Post-doctoral Researcher
> d...@mpia.de   +49-6221-528-375
> Max Planck Institut für Astronomie (MPIA)
> Königstuhl 17  D-69117 Heidelberg, Germany
> ___
> 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] Problems using add_npy_pkg_config

[Ralf Gommers]

On Wed, Aug 12, 2015 at 7:23 PM, Charles R Harris  wrote:

>
>
> On Wed, Aug 12, 2015 at 10:50 AM, Ralf Gommers 
> wrote:
>
>>
>>
>> On Wed, Aug 12, 2015 at 6:23 PM, Christian Engwer <
>> christian.eng...@uni-muenster.de> wrote:
>>
>>> Dear all,
>>>
>>> I'm trying to use the numpy distutils to install native C
>>> libraries. These are part of a larger roject and should be usable
>>> standalone. I managed to install headers and libs, but now I
>>> experience problems writing the corresponding pkg file. I first tried
>>> to do the trick without numpy, but getting all the pathes right in all
>>> different setups is really a mess.
>>>
>>
>> This doesn't answer your question but: why? If you're not distributing a
>> Python project, there is no reason to use distutils instead of a sane build
>> system.
>>
>
> Believe it or not, distutils *is* one of the saner build systems when you
> want something cross platform. Sad, isn't it...
>

Come on. We don't take it seriously, and neither do the Python core devs.
It's also pretty much completely unsupported. Numpy.distutils is a bit
better in that respect than Python distutils, which doesn't even get sane
patches merged.

Try Scons, Tup, Gradle, Shake, Waf or anything else that's at least
somewhat modern and supported. Do not use numpy.distutils unless there's no
other mature choice (i.e. you're developing a Python project).

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

Re: [Numpy-discussion] Problems using add_npy_pkg_config

[Charles R Harris]

On Wed, Aug 12, 2015 at 10:50 AM, Ralf Gommers 
wrote:

>
>
> On Wed, Aug 12, 2015 at 6:23 PM, Christian Engwer <
> christian.eng...@uni-muenster.de> wrote:
>
>> Dear all,
>>
>> I'm trying to use the numpy distutils to install native C
>> libraries. These are part of a larger roject and should be usable
>> standalone. I managed to install headers and libs, but now I
>> experience problems writing the corresponding pkg file. I first tried
>> to do the trick without numpy, but getting all the pathes right in all
>> different setups is really a mess.
>>
>
> This doesn't answer your question but: why? If you're not distributing a
> Python project, there is no reason to use distutils instead of a sane build
> system.
>

Believe it or not, distutils *is* one of the saner build systems when you
want something cross platform. Sad, isn't it...

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

Re: [Numpy-discussion] Problems using add_npy_pkg_config

[Ralf Gommers]

On Wed, Aug 12, 2015 at 6:23 PM, Christian Engwer <
christian.eng...@uni-muenster.de> wrote:

> Dear all,
>
> I'm trying to use the numpy distutils to install native C
> libraries. These are part of a larger roject and should be usable
> standalone. I managed to install headers and libs, but now I
> experience problems writing the corresponding pkg file. I first tried
> to do the trick without numpy, but getting all the pathes right in all
> different setups is really a mess.
>

This doesn't answer your question but: why? If you're not distributing a
Python project, there is no reason to use distutils instead of a sane build
system.

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

[Numpy-discussion] Problems using add_npy_pkg_config

[Christian Engwer]

Dear all,

I'm trying to use the numpy distutils to install native C
libraries. These are part of a larger roject and should be usable
standalone. I managed to install headers and libs, but now I
experience problems writing the corresponding pkg file. I first tried
to do the trick without numpy, but getting all the pathes right in all
different setups is really a mess.

Please a find a m.w.e. attached to this mail. It consists of foo.c
foo.ini.in and setup.py.

I'm sure I missed some important part, but somehow the distribution
variable in build_src seems to be uniinitalized. Calling
> python setup.py install --prefix=/tmp/foo.inst
fils with ...
  File "/usr/lib/python2.7/dist-packages/numpy/distutils/command/build_src.py", 
line 257, in build_npy_pkg_config
  pkg_path = self.distribution.package_dir[pkg]
  TypeError: 'NoneType' object has no attribute '__getitem__'

I also tried to adopt parts of the numpy setup, but these use
sub-modules, which I don't need... might this the the cause of my
problems?

Any help is highly appreciated ;-)

Cheers
Christian
int foo() { return 10; }
[meta]
Name=@foo@
Version=1.0
Description=dummy description

[default]
Cflags=-I@prefix@/include
Libs=
def configuration(parent_package='', top_path=None):
from numpy.distutils.misc_util import Configuration
config = Configuration('foo',parent_package,top_path)
config.set_options(ignore_setup_xxx_py=True, assume_default_configuration=True)
config.add_installed_library('foo', sources=['foo.c'], install_dir='lib')
config.add_npy_pkg_config('foo.ini.in', 'lib', {'foo': 'bar'})
return config

if __name__ == '__main__':
from numpy.distutils.core import setup
setup (configuration=configuration)
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] f2py and callbacks with variables

[Casey Deen]

Hi all-

   I've run into what I think might be a bug in f2py and callbacks to
python.  Or, maybe I'm not using things correctly.  I have created a
very minimal example which illustrates my problem at:

https://github.com/soylentdeen/fluffy-kumquat

The issue seems to affect call backs with variables, but only when they
are called indirectly (i.e. from other fortran routines).  For example,
if I have a python function

def show_number(n):
print("%d" % n)

and I setup a callback in a fortran routine:

  subroutine cb
cf2py intent(callback, hide) blah
  external blah
  call blah(5)
  end

and connect it to the python routine
fortranObject.blah = show_number

I can successfully call the cb routine from python:

>fortranObject.cb
5

However, if I call the cb routine from within another fortran routine,
it seems to lose its marbles

  subroutine no_cb
  call cb
  end

capi_return is NULL
Call-back cb_blah_in_cb__user__routines failed.

For more information, please have a look at the github repository.  I've
reproduced the behavior on both linux and mac.  I'm not sure if this is
an error in the way I'm using the code, or if it is an actual bug.  Any
and all help would be very much appreciated.

Cheers,
Casey


-- 
Dr. Casey Deen
Post-doctoral Researcher
d...@mpia.de   +49-6221-528-375
Max Planck Institut für Astronomie (MPIA)
Königstuhl 17  D-69117 Heidelberg, Germany
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] [SciPy-Dev] ANN: Numpy 1.10.0b1 release

[Sebastian Berg]

On Mi, 2015-08-12 at 01:07 -0700, Nathaniel Smith wrote:
> On Wed, Aug 12, 2015 at 12:51 AM, Sebastian Berg
>  wrote:
> > On Mi, 2015-08-12 at 09:41 +0200, Jens Jørgen Mortensen wrote:
> >> On 08/11/2015 11:23 PM, Charles R Harris wrote:
> >> > Hi All,
> >> >
> >> > give this release a whirl and report any problems either on the
> >> > numpy-discussion list or by opening an issue on github.
> >> >
> >> > I'm pleased to announce the first beta release of Numpy 1.10.0.
> >> > There is over a year's worth of enhancements and bug fixes in the
> >> > 1.10.0 release, so please give this release a whirl and report any
> >> > problems either on the numpy-discussion list or by opening an issue
> >> > on github. Tarballs, installers, and release notes may be found in
> >> > the usual place at Sourceforge.
> >> >
> >>
> >> This looks a bit strange:
> >>
> >> Python 2.7.9 (default, Apr  2 2015, 15:33:21)
> >> [GCC 4.9.2] on linux2
> >> Type "help", "copyright", "credits" or "license" for more information.
> >> >>> import numpy as np
> >> >>> np.zeros(1).strides
> >> (9223372036854775807,)
> >> >>> np.zeros(42).strides
> >> (8,)
> >> >>> np.__version__
> >> '1.10.0b1'
> >
> > It is intentional, it will not be the case in the final release.
> 
> Given how quickly this surprised someone, it looks like it would be
> helpful to have some single link we could give people to explain
> what's going on here. Do we have such a thing? In a few minutes of
> searching all I was able to find was
> 
> http://docs.scipy.org/doc/numpy/release.html#npy-relaxed-strides-checking
> https://github.com/numpy/numpy/blob/master/doc/release/1.10.0-notes.rst#relaxed-stride-checking
> 
> which together kinda sorta hint at what's going on if you squint, but
> not really? Maybe we should add a paragraph to the 1.10 release notes?
> 

True, frankly, after I hit send I thought I should have explained more
in any case. 
I think relaxed strides is explained (though 1.10 could possible
link/include more). The issue is that I/we forgot to mention the "funny"
stride messing up to expose bugs/help debugging

So in case someone wonders. When relaxed strides is active, we
intentionally give this funny stride that Jens saw (we will not do this
in a final release) because failure to work correctly with it hints to
general bugs and tests are likely to miss without this "help". Of course
some software that is totally fine might still stumble on these strides,
though I expect making it work fine with them should not be hard and
make it more robust in any case.

- Sebastian

> > And thanks Chuck for all the release work!
> 
> Indeed!
> 
> -n
> 



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

Re: [Numpy-discussion] [SciPy-Dev] ANN: Numpy 1.10.0b1 release

[Nathaniel Smith]

On Wed, Aug 12, 2015 at 12:51 AM, Sebastian Berg
 wrote:
> On Mi, 2015-08-12 at 09:41 +0200, Jens Jørgen Mortensen wrote:
>> On 08/11/2015 11:23 PM, Charles R Harris wrote:
>> > Hi All,
>> >
>> > give this release a whirl and report any problems either on the
>> > numpy-discussion list or by opening an issue on github.
>> >
>> > I'm pleased to announce the first beta release of Numpy 1.10.0.
>> > There is over a year's worth of enhancements and bug fixes in the
>> > 1.10.0 release, so please give this release a whirl and report any
>> > problems either on the numpy-discussion list or by opening an issue
>> > on github. Tarballs, installers, and release notes may be found in
>> > the usual place at Sourceforge.
>> >
>>
>> This looks a bit strange:
>>
>> Python 2.7.9 (default, Apr  2 2015, 15:33:21)
>> [GCC 4.9.2] on linux2
>> Type "help", "copyright", "credits" or "license" for more information.
>> >>> import numpy as np
>> >>> np.zeros(1).strides
>> (9223372036854775807,)
>> >>> np.zeros(42).strides
>> (8,)
>> >>> np.__version__
>> '1.10.0b1'
>
> It is intentional, it will not be the case in the final release.

Given how quickly this surprised someone, it looks like it would be
helpful to have some single link we could give people to explain
what's going on here. Do we have such a thing? In a few minutes of
searching all I was able to find was

http://docs.scipy.org/doc/numpy/release.html#npy-relaxed-strides-checking
https://github.com/numpy/numpy/blob/master/doc/release/1.10.0-notes.rst#relaxed-stride-checking

which together kinda sorta hint at what's going on if you squint, but
not really? Maybe we should add a paragraph to the 1.10 release notes?

> And thanks Chuck for all the release work!

Indeed!

-n

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

Re: [Numpy-discussion] [SciPy-Dev] ANN: Numpy 1.10.0b1 release

[Sebastian Berg]

On Mi, 2015-08-12 at 09:41 +0200, Jens Jørgen Mortensen wrote:
> On 08/11/2015 11:23 PM, Charles R Harris wrote:
> > Hi All,
> > 
> > give this release a whirl and report any problems either on the
> > numpy-discussion list or by opening an issue on github.
> > 
> > I'm pleased to announce the first beta release of Numpy 1.10.0.
> > There is over a year's worth of enhancements and bug fixes in the
> > 1.10.0 release, so please give this release a whirl and report any
> > problems either on the numpy-discussion list or by opening an issue
> > on github. Tarballs, installers, and release notes may be found in
> > the usual place at Sourceforge.
> > 
> 
> This looks a bit strange:
> 

It is intentional, it will not be the case in the final release.

And thanks Chuck for all the release work!

- Sebastian


> Python 2.7.9 (default, Apr  2 2015, 15:33:21) 
> [GCC 4.9.2] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import numpy as np
> >>> np.zeros(1).strides
> (9223372036854775807,)
> >>> np.zeros(42).strides
> (8,)
> >>> np.__version__
> '1.10.0b1'
> 
> This is on Ubuntu 15.04.
> 
> Jens Jørgen
> 
> > 
> > 
> > Chuck
> > 
> > 
> >  
> > 
> > 
> > 
> > ___
> > SciPy-Dev mailing list
> > scipy-...@scipy.org
> > http://mail.scipy.org/mailman/listinfo/scipy-dev
> 
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion



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

Re: [Numpy-discussion] [SciPy-Dev] ANN: Numpy 1.10.0b1 release

[Jens Jørgen Mortensen]

On 08/11/2015 11:23 PM, Charles R Harris wrote:

Hi All,

give this release a whirl and report any problems either on the 
numpy-discussion list or by opening an issue on github.
I'm pleased to announce the first beta release of Numpy 1.10.0. There 
is over a year's worth of enhancements and bug fixes in the 1.10.0 
release, so please give this release a whirl and report any problems 
either on the numpy-discussion list or by opening an issue on github. 
Tarballs, installers, and release notes may be found in the usual 
place at Sourceforge 
.


This looks a bit strange:

Python 2.7.9 (default, Apr  2 2015, 15:33:21)
[GCC 4.9.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy as np
>>> np.zeros(1).strides
(9223372036854775807,)
>>> np.zeros(42).strides
(8,)
>>> np.__version__
'1.10.0b1'

This is on Ubuntu 15.04.

Jens Jørgen



Chuck




___
SciPy-Dev mailing list
scipy-...@scipy.org
http://mail.scipy.org/mailman/listinfo/scipy-dev


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