Re: [Numpy-discussion] when did column_stack become C-contiguous?

On Sun, Oct 18, 2015 at 9:35 PM, wrote: np.column_stack((np.ones(10), np.ones(10))).flags > C_CONTIGUOUS : True > F_CONTIGUOUS : False > np.__version__ > '1.9.2rc1' > > > on my notebook which has numpy 1.6.1 it is f_contiguous > > > I was just trying to

Re: [Numpy-discussion] when did column_stack become C-contiguous?

On Mon, Oct 19, 2015 at 2:14 AM, Nathaniel Smith wrote: > On Sun, Oct 18, 2015 at 9:35 PM, wrote: > np.column_stack((np.ones(10), np.ones(10))).flags > > C_CONTIGUOUS : True > > F_CONTIGUOUS : False > > > np.__version__ > > '1.9.2rc1' > > > >

Re: [Numpy-discussion] when did column_stack become C-contiguous?

On Mon, Oct 19, 2015 at 5:16 AM, Sebastian Berg wrote: > On Mo, 2015-10-19 at 01:34 -0400, josef.p...@gmail.com wrote: > > > > > > > > > > It looks like in 1.9 it depends on the order of the 2-d arrays, which > > it didn't do in 1.6 > > > > Yes, it uses concatenate,

Re: [Numpy-discussion] numpy-1.11.0.dev0 windows wheels compiled with mingwpy available

> Is it possible to test this with py35 as well? Unfortunately not yet. > For MSVC, py35 requires a new compiler toolchain (VS2015) -- is that something mingwpy/mingw-w64 can handle? I am pretty sure that mingwpy does not support Python 3.5 yet. I don't know the status of the interop of

[Numpy-discussion] [Feature Suggestion]More comparison functions for floating point numbers

I think these would be useful and easy to implement. greater_close(a, b) = greater_equal(a, b) | isclose(a, b) less_close(a, b) = less_equal(a, b) | isclose(a, b) greater_no_close = greater(a, b) & ~isclose(a, b) less_no_close = less(a, b) & ~isclose(a, b) The results are

Re: [Numpy-discussion] when did column_stack become C-contiguous?

On Mo, 2015-10-19 at 01:34 -0400, josef.p...@gmail.com wrote: > > > It looks like in 1.9 it depends on the order of the 2-d arrays, which > it didn't do in 1.6 > Yes, it uses concatenate, and concatenate probably changed in 1.7 to use "K" (since "K" did not really exists before 1.7 IIRC).

Re: [Numpy-discussion] when did column_stack become C-contiguous?

On Mon, Oct 19, 2015 at 9:00 AM, wrote: > > > On Mon, Oct 19, 2015 at 5:16 AM, Sebastian Berg < > sebast...@sipsolutions.net> wrote: > >> On Mo, 2015-10-19 at 01:34 -0400, josef.p...@gmail.com wrote: >> > >> >> >> >> >> > >> > It looks like in 1.9 it depends on the order

[Numpy-discussion] Workshop tonight, expect GitHub activity

Hi all, As mentioned a few weeks ago, I am organizing a "Become an Open Source Contributor" workshop tonight, for the Data Science Student Society at UCSD. During this morning I will be creating a few ridiculously simple issues, e.g. "missing space, arrayobject --> array object", for

Re: [Numpy-discussion] [Feature Suggestion]More comparison functions for floating point numbers

On Mon, Oct 19, 2015 at 9:51 PM, cy18 wrote: > > It would be useful when we need to subtracting a bit before comparing by greater or less. By subtracting a bit, we only have an absolute error tolerance and with the new functions, we can have both absolute and relative error

Re: [Numpy-discussion] [Feature Suggestion]More comparison functions for floating point numbers

It would be useful when we need to subtracting a bit before comparing by greater or less. By subtracting a bit, we only have an absolute error tolerance and with the new functions, we can have both absolute and relative error tolerance. This is how isclose(a, b) better than abs(a-b)<=atol.

Re: [Numpy-discussion] [Feature Suggestion]More comparison functions for floating point numbers

On Mon, Oct 19, 2015 at 3:06 AM, cy18 wrote: > I think these would be useful and easy to implement. > > greater_close(a, b) = greater_equal(a, b) | isclose(a, b) > less_close(a, b) = less_equal(a, b) | isclose(a, b) > greater_no_close = greater(a, b) & ~isclose(a,

Re: [Numpy-discussion] Workshop tonight, expect GitHub activity

On Mon, Oct 19, 2015 at 9:11 AM, Jaime Fernández del Río < jaime.f...@gmail.com> wrote: > Hi all, > > As mentioned a few weeks ago, I am organizing a "Become an Open Source > Contributor" workshop tonight, for the Data Science Student Society at UCSD. > > During this morning I will be creating a

Re: [Numpy-discussion] Making datetime64 timezone naive

On Sun, Oct 18, 2015 at 12:20 PM, Alexander Belopolsky wrote: > > On Sat, Oct 17, 2015 at 6:59 PM, Chris Barker > wrote: > >> Off the top of my head, I think allowing a 60th second makes more sense >> -- jsut like we do leap years. > > > Yet we don't

Re: [Numpy-discussion] Making datetime64 timezone naive

> This is fine. Just be aware that *naive* datetimes will also have the PEP > 495 "fold" attribute in Python 3.6. You are free to ignore it, but you will > loose the ability to round-trip between naive stdlib datetimes and > numpy.datetime64. Sigh. I can see why it's there ( primarily to

Re: [Numpy-discussion] numpy-1.11.0.dev0 windows wheels compiled with mingwpy available

On Mon, Oct 19, 2015 at 2:26 AM, Olivier Grisel wrote: >> Is it possible to test this with py35 as well? > > Unfortunately not yet. > >> For MSVC, py35 requires a new compiler toolchain (VS2015) -- is that >> something mingwpy/mingw-w64 can handle? > > I am pretty sure

[Numpy-discussion] Behavior of numpy.copy with sub-classes

In GitHub issue #3474, a number of us have started a conversation on how NumPy's copy function should behave when passed an instance which is a sub-class of the array class. Specifically, the issue began by noting that when a MaskedArray is passed to np.copy, the sub-class is not passed

Re: [Numpy-discussion] when did column_stack become C-contiguous?

On Mon, Oct 19, 2015 at 9:15 PM, Nathaniel Smith wrote: > On Mon, Oct 19, 2015 at 5:55 AM, wrote: > > > > > > On Mon, Oct 19, 2015 at 2:14 AM, Nathaniel Smith wrote: > >> > >> On Sun, Oct 18, 2015 at 9:35 PM, wrote:

Re: [Numpy-discussion] Behavior of numpy.copy with sub-classes

On Mon, Oct 19, 2015 at 7:23 PM, Jonathan Helmus wrote: > In GitHub issue #3474, a number of us have started a conversation on how > NumPy's copy function should behave when passed an instance which is a > sub-class of the array class. Specifically, the issue began by noting

[Numpy-discussion] correct sizeof for ndarray

Hi folks, I noticed an unexpected behavior of itemsize for structures with offsets that are larger than that of a packed structure in memory. This matters when parsing in memory structures from C and some others (recently and HDF5/h5py detail got me for a bit). So what is the correct way to get

Re: [Numpy-discussion] when did column_stack become C-contiguous?

On Mon, Oct 19, 2015 at 5:55 AM, wrote: > > > On Mon, Oct 19, 2015 at 2:14 AM, Nathaniel Smith wrote: >> >> On Sun, Oct 18, 2015 at 9:35 PM, wrote: >> np.column_stack((np.ones(10), np.ones(10))).flags >> > C_CONTIGUOUS : True

Re: [Numpy-discussion] numpy 1.10.1 reduce operation on recarrays

On Fri, Oct 16, 2015 at 9:31 PM, Allan Haldane wrote: > On 10/16/2015 09:17 PM, josef.p...@gmail.com wrote: > >> >> >> On Fri, Oct 16, 2015 at 8:56 PM, Allan Haldane > > wrote: >> >> On 10/16/2015 05:31 PM,

Re: [Numpy-discussion] Behavior of numpy.copy with sub-classes

On Mon, Oct 19, 2015 at 8:28 PM, Nathan Goldbaum wrote: > > > On Mon, Oct 19, 2015 at 7:23 PM, Jonathan Helmus > wrote: > >> In GitHub issue #3474, a number of us have started a conversation on how >> NumPy's copy function should behave when passed an