[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] 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 instance which is a >> sub-class of the arra

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 that > when a Masked

[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 throug

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, josef.p...@gmail.com >>

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 that mingwpy does not suppor

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: > >> np.column_stack((np.ones(10), np.ones(10))).flags > >> > C_CONTI

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 >> > F_CONTIGUOUS : False >> > >> np.__version__ >> >

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 supp

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 tolerance. This is how

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. 2015-1

Re: [Numpy-discussion] Making datetime64 timezone naive

On Mon, Oct 19, 2015 at 4:12 PM, Stephan Hoyer wrote: > On Mon, Oct 19, 2015 at 12:34 PM, Chris Barker > wrote: > >> Also -- I think we are at phase one of a (at least) two step process: >> >> 1) clean up datetime64 just enough that it is useful, and less >> error-prone -- i.e. have it not prete

Re: [Numpy-discussion] Making datetime64 timezone naive

On Mon, Oct 19, 2015 at 4:12 PM, Stephan Hoyer wrote: > Alexander -- by "mst" I think Chris meant "most". Good because in context it could be "Moscow Standard Time" or "Mean Solar Time". :-) ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org

Re: [Numpy-discussion] Making datetime64 timezone naive

On Mon, Oct 19, 2015 at 12:34 PM, Chris Barker wrote: > Also -- I think we are at phase one of a (at least) two step process: > > 1) clean up datetime64 just enough that it is useful, and less error-prone > -- i.e. have it not pretend to support anything other than naive datetimes. > > 2) Do it r

Re: [Numpy-discussion] Making datetime64 timezone naive

On Mon, Oct 19, 2015 at 3:34 PM, Chris Barker wrote: > > > In Python 3.6, datetime.now() will return different values in the first > and the second repeated hour in the "fall-back fold." > If you allow > datetime.datetime to numpy.datetime64 conversion, you should decide what > you do with that d

Re: [Numpy-discussion] Making datetime64 timezone naive

On Mon, Oct 19, 2015 at 3:34 PM, Chris Barker wrote: > DST is a civil construct -- and mst (all?) implementations use the > convention of having repeated times. What is "mst"? ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.s

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, b) > less_no_clo

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 implement DST by allowing the 24th hour. Eve

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 f

[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 participants

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 of the 2-d arrays, which

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, and concatenate probably chan

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' > > > > > > on my notebook which has numpy 1.6

[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 element-

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 mingw-w

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). N