Re: [Numpy-discussion] Fwd: [numfocus] Grants up to $3k available to NumFOCUS projects (sponsored & affiliated)

On Mon, Mar 27, 2017 at 3:33 AM, Julian Taylor < jtaylor.deb...@googlemail.com> wrote: > - add ascii/latin1 dtype to support a compact python3 string array, > deprecate 's' dtype which has different meaning in python2 and 3 > This one is probably too big for 3k though. > probably -- but not THAT

Re: [Numpy-discussion] Fwd: [numfocus] Grants up to $3k available to NumFOCUS projects, (sponsored & affiliated)

On Mon, Mar 27, 2017 at 12:14 PM, Pauli Virtanen wrote: > > The bigger challenge is deciding what to do -- the bikeshedding -- and > > the backward incompatibility issues. IIRC, when this came up on the > > list, there was nothing like consensus on exactly what to do and how > > to do it. > > TBH

Re: [Numpy-discussion] proposal: smaller representation of string arrays

Thanks so much for reviving this conversation -- we really do need to address this. My thoughts: What people apparently want is a string type for Python3 which uses less > memory for the common science use case which rarely needs more than > latin1 encoding. > Yes -- I think there is a real dema

Re: [Numpy-discussion] proposal: smaller representation of string arrays

On Thu, Apr 20, 2017 at 9:47 AM, Anne Archibald wrote: > Is there any reason not to support all Unicode encodings that python does, > with the same names and semantics? This would surely be the simplest to > understand. > I think it should support all fixed-length encodings, but not the non-fixe

Re: [Numpy-discussion] proposal: smaller representation of string arrays

On Thu, Apr 20, 2017 at 10:26 AM, Stephan Hoyer wrote: > I agree with Anne here. Variable-length encoding would be great to have, > but even fixed length UTF-8 (in terms of memory usage, not characters) > would solve NumPy's Python 3 string problem. NumPy's memory model needs a > fixed size per a

Re: [Numpy-discussion] proposal: smaller representation of string arrays

On Thu, Apr 20, 2017 at 10:36 AM, Neal Becker wrote: > I'm no unicode expert, but can't we truncate unicode strings so that only > valid characters are included? > sure -- it's just a bit fiddly -- and you need to make sure that everything gets passed through the proper mechanism. numpy is all a

Re: [Numpy-discussion] proposal: smaller representation of string arrays

I just re-read the "Utf-8" manifesto, and it helped me clarify my thoughts: 1) most of it is focused on utf-8 vs utf-16. And that is a strong argument -- utf-16 is the worst of both worlds. 2) it isn't really addressing how to deal with fixed-size string storage as needed by numpy. It does bring

Re: [Numpy-discussion] proposal: smaller representation of string arrays

On Fri, Apr 21, 2017 at 2:34 PM, Stephan Hoyer wrote: > In this case, we want something compatible with Python's string (i.e. full >> Unicode supporting) and I think should be as transparent as possible. >> Python's string has made the decision to present a character oriented API >> to users (de

Re: [Numpy-discussion] proposal: smaller representation of string arrays

On Mon, Apr 24, 2017 at 10:51 AM, Stephan Hoyer wrote: > - round-tripping of binary data (at least with Python's encoding/decoding) >> -- ANY string of bytes can be decodes as latin-1 and re-encoded to get the >> same bytes back. You may get garbage, but you won't get an EncodingError. >> > > For

Re: [Numpy-discussion] proposal: smaller representation of string arrays

On Mon, Apr 24, 2017 at 10:51 AM, Aldcroft, Thomas < aldcr...@head.cfa.harvard.edu> wrote: > BTW -- maybe we should keep the pathological use-case in mind: really >> short strings. I think we are all thinking in terms of longer strings, >> maybe a name field, where you might assign 32 bytes or so

Re: [Numpy-discussion] proposal: smaller representation of string arrays

On Mon, Apr 24, 2017 at 11:36 AM, Robert Kern wrote: > > I agree -- it is a VERY common case for scientific data sets. But a > one-byte-per-char encoding would handle it nicely, or UCS-4 if you want > Unicode. The wasted space is not that big a deal with short strings... > > Unless if you have hu

Re: [Numpy-discussion] proposal: smaller representation of string arrays

On Mon, Apr 24, 2017 at 4:08 PM, Robert Kern wrote: > Chris, you've mashed all of my emails together, some of them are in reply > to you, some in reply to others. Unfortunately, this dropped a lot of the > context from each of them, and appears to be creating some > misunderstandings about what e

Re: [Numpy-discussion] proposal: smaller representation of string arrays

This is essentially my rant about use-case (2): A compact dtype for mostly-ascii text: On Mon, Apr 24, 2017 at 4:09 PM, Stephan Hoyer wrote: > On Mon, Apr 24, 2017 at 11:13 AM, Chris Barker > wrote: > >> On the other hand, if this is the use-case, perhaps we really want an >

Re: [Numpy-discussion] proposal: smaller representation of string arrays

On Mon, Apr 24, 2017 at 4:23 PM, Robert Kern wrote: > > My question: What are those non-ASCII characters? How often are they > truly latin-1/9 vs. some other text encoding vs. non-string binary data? > > I don't know that we can reasonably make that accounting relevant. Number > of such character

Re: [Numpy-discussion] proposal: smaller representation of string arrays

OK -- onto proposals: 1) The default behaviour for numpy arrays of strings is compatible with > Python3's string model: i.e. fully unicode supporting, and with a character > oriented interface. i.e. if you do:: > > arr = np.array(("this", "that",)) > > you get an array that can store ANY unicode

Re: [Numpy-discussion] proposal: smaller representation of string arrays

On Tue, Apr 25, 2017 at 9:57 AM, Ambrose LI wrote: > 2017-04-25 12:34 GMT-04:00 Chris Barker : > > I am totally euro-centric, > > But Shift-JIS is not one-byte; it's two-byte (unless you allow only > half-width characters and nothing else). :-) bad example then -- a

Re: [Numpy-discussion] proposal: smaller representation of string arrays

Now my proposal for the other use cases: 2) There be some way to store mostly ascii-compatible strings in a single > byte-per-character array -- so not to be wasting space for "typical > european-language-oriented data". Note: this should ALSO be compatible with > Python's character-oriented strin

Re: [Numpy-discussion] proposal: smaller representation of string arrays

On Wed, Apr 26, 2017 at 11:31 AM, Nathaniel Smith wrote: > UTF-8 does not match the character-oriented Python text model. Plenty > of people argue that that isn't the "correct" model for Unicode text > -- maybe so, but it is the model python 3 has chosen. I wrote a much > longer rant about that e

Re: [Numpy-discussion] proposal: smaller representation of string arrays

On Wed, Apr 26, 2017 at 11:38 AM, Sebastian Berg wrote: > I remember talking with a colleague about something like that. And > basically an annoying thing there was that if you strip the zero bytes > in a zero padded string, some encodings (UTF16) may need one of the > zero bytes to work right.

Re: [Numpy-discussion] proposal: smaller representation of string arrays

On Wed, Apr 26, 2017 at 10:45 AM, Robert Kern wrote: > >>> > The maximum length of an UTF-8 character is 4 bytes, so we could use > that to size arrays by character length. The advantage over UTF-32 is that > it is easily compressible, probably by a factor of 4 in many cases. > isn't UTF-32 pret

Re: [Numpy-discussion] proposal: smaller representation of string arrays

On Wed, Apr 26, 2017 at 4:30 PM, Stephan Hoyer wrote: > > Sorry, I remain unconvinced (for the reasons that Robert, Nathaniel and > myself have already given), but we seem to be talking past each other here. > yeah -- I think it's not clear what the use cases we are talking about are. > I am s

Re: [Numpy-discussion] proposal: smaller representation of string arrays

On Wed, Apr 26, 2017 at 5:17 PM, Robert Kern wrote: > The proposal is for only latin-1 and UTF-32 to be supported at first, and > the eventual support of UTF-8 will be constrained by specification of the > width in terms of characters rather than bytes, which conflicts with the > use cases of UTF

Re: [Numpy-discussion] proposal: smaller representation of string arrays

On Thu, Apr 27, 2017 at 4:10 AM, Francesc Alted wrote: > I remember advocating for UCS-4 adoption in the HDF5 library many years > ago (2007?), but I had no success and UTF-8 was decided to be the best > candidate. So, the boat with HDF5 using UTF-8 sailed many years ago, and I > don't think the

Re: [Numpy-discussion] Array and string interoperability

Just a few notes: However, the fact that this works for bytestrings on Python 3 is, in my > humble opinion, ridiculous: > > >>> np.array(b'100', 'u1') # b'100' IS NOT TEXT > array(100, dtype=uint8) > Yes, that is a mis-feature -- I think due to bytes and string being the same object in py2 -- so

Re: [Numpy-discussion] Array and string interoperability

On Mon, Jun 5, 2017 at 1:51 PM, Thomas Jollans wrote: > > and overloading fromstring() to mean both "binary dump of data" and > > "parse the text" due to whether the sep argument is set was always a > > bad idea :-( > > > > .. and fromstring(s, sep=a_sep_char) > > As it happens, this is pretty mu

Re: [Numpy-discussion] Array and string interoperability

On Mon, Jun 5, 2017 at 3:59 PM, Mikhail V wrote: > -- classify by "forward/backward" conversion: > For this time consider only forward, i.e. I copy data from string > to numpy array > > -- classify by " bytes vs ordinals ": > > a) bytes: If I need raw bytes - in this case e.g. > > B = b

Re: [Numpy-discussion] Array and string interoperability

On Mon, Jun 5, 2017 at 4:06 PM, Mikhail V wrote: > Likely it was about some new string array type... yes, it was. > Obviously there is demand. Terror of unicode touches many aspects > of programmers life. I don't know that I'd call it Terror, but frankly, the fact that you need up to 4 byte

Re: [Numpy-discussion] Scipy 2017 NumPy sprint

On Mon, Jul 3, 2017 at 4:27 PM, Stephan Hoyer wrote: > If someone who does subclasses/array-likes or so (e.g. like Stefan >> Hoyer ;)) and is interested, and also we do some >> teleconferencing/chatting (and I have time) I might be interested >> in discussing and possibly trying to develop th

Re: [Numpy-discussion] record data previous to Numpy use

OK, you have two performance "issues" 1) memory use: IF yu need to read a file to build a numpy array, and dont know how big it is when you start, you need to accumulate the values first, and then make an array out of them. And numpy arrays are fixed size, so they can not efficiently accumulate v

Re: [Numpy-discussion] Making a 1.13.2 release

On Thu, Jul 6, 2017 at 6:10 AM, Charles R Harris wrote: > I've delayed the NumPy 1.13.2 release hoping for Python 3.6.2 to show up > fixing #29943 so we can close #9272 > , but the Python release has > been delayed

Re: [Numpy-discussion] Scipy 2017 NumPy sprint

On Wed, Jul 5, 2017 at 11:05 AM, Stephan Hoyer wrote: > That is, the boilerplate needed for multi-dimensional indexing and >> slicing, etc... >> >> That could be a nice little sprint-able project. >> > > Indeed. Let me highlight a few mixins >

Re: [Numpy-discussion] record data previous to Numpy use

On Thu, Jul 6, 2017 at 10:55 AM, wrote: > > It's is just a reflexion, but for huge files one solution might be to > split/write/build first the array in a dedicated file (2x o(n) iterations - > one to identify the blocks size - additional one to get and write), and > then to load it in memory and

Re: [Numpy-discussion] pytest and degrees of separation.

On Tue, Jul 11, 2017 at 5:04 PM, Thomas Caswell wrote: > Going with option 2 is probably the best option so that you can use pytest > fixtures and parameterization. > I agree -- those are worth a lot! -CHB > Might be worth looking at how Matplotlib re-arranged things on our master > branch t

Re: [Numpy-discussion] quantile() or percentile()

+1 on quantile() -CHB On Sun, Aug 13, 2017 at 6:28 AM, Charles R Harris wrote: > > > On Thu, Aug 10, 2017 at 3:08 PM, Eric Wieser > wrote: > >> Let’s try and keep this on topic - most replies to this message has been >> about #9211, which is an orthogonal issue. >> >> There are two main quest

Re: [Numpy-discussion] Tensor Contraction (HPTT) and Tensor Transposition (TCL)

On Thu, Aug 17, 2017 at 12:55 AM, Sebastian Berg wrote: > > How would the process look like if NumPY is distributed as a > > precompiled binary? > > > Well, numpy is BSD, and the official binaries will be BSD, someone else > could do less free binaries of course. Indeed, if you want it to be di

Re: [Numpy-discussion] Why are empty arrays False?

On Mon, Aug 21, 2017 at 7:34 AM, Benjamin Root wrote: > I've long ago stopped doing any "emptiness is false"-type tests on any > python containers when iterators and generators became common, because they > always return True. > good point. Personally, I've thought for years that Python's "Trut

Re: [Numpy-discussion] Why are empty arrays False?

On Tue, Aug 22, 2017 at 11:04 AM, Michael Lamparski < diagonaldev...@gmail.com> wrote: > I think truthiness is easily a wart in any dynamically-typed language (and > yet ironically, every language I can think of that has truthiness is > dynamically typed except for C++). And yet for some reason i

Re: [Numpy-discussion] Interface numpy arrays to Matlab?

On Tue, Aug 29, 2017 at 4:08 AM, Neal Becker wrote: > Transplant sounds interesting, I think I could use this. I don't > understand though why nobody has used a more direct approach? Matlab has > their python API https://www.mathworks.com/help/matlab/matlab-engine-for- > python.html. This will

Re: [Numpy-discussion] converting list of int16 values to bitmask and back to list of int32\float values

not sure what you are getting from: Modbus.read_input_registers() but if it is a binary stream then you can put it all in one numpy array (probably type uint8 (byte)). then you can manipulate the type with arr.astype() and arr.byteswap() astype will tell numpy to interpret the same block of dat

Re: [Numpy-discussion] is __array_ufunc__ ready for prime-time?

On Sat, Nov 4, 2017 at 6:47 AM, Marten van Kerkwijk < m.h.vankerkw...@gmail.com> wrote: > > You just summarized excellently why I'm on a quest to change `asarray` > to `asanyarray` within numpy +1 -- we should all be using asanyarray() most of the time. However a couple notes: asarray() pre-dat

Re: [Numpy-discussion] Proposal of timeline for dropping Python 2.7 support

On Sun, Nov 5, 2017 at 10:25 AM, Charles R Harris wrote: > the timeline I've been playing with is to keep Python 2.7 support through > 2018, which given our current pace, would be for NumPy 1.15 and 1.16. After > that 1.16 would become a long term support release with backports of > critical bu

Re: [Numpy-discussion] Proposal of timeline for dropping Python 2.7 support

On Mon, Nov 6, 2017 at 6:14 PM, Charles R Harris wrote: > Also -- if py2.7 continues to see the use I expect it will well past when >>> pyton.org officially drops it, I wouldn't be surprised if a Python2.7 >>> Windows build based on a newer compiler would come along -- perhaps by >>> Anaconda or

Re: [Numpy-discussion] is __array_ufunc__ ready for prime-time?

On Mon, Nov 6, 2017 at 4:28 PM, Stephan Hoyer wrote: > >> What's needed, though, is not just a single ABC. Some thought and design >> needs to go into segmenting the ndarray API to declare certain behaviors, >> just like was done for collections: >> >> https://docs.python.org/3/library/collection

Re: [Numpy-discussion] Proposal of timeline for dropping Python 2.7 support

On Wed, Nov 8, 2017 at 11:08 AM, Julian Taylor < jtaylor.deb...@googlemail.com> wrote: > > Would dropping python2 support for windows earlier than the other > platforms a reasonable approach? > no. I'm not Windows fan myself, but it is a HUGE fraction of the userbase. -CHB -- Christopher Bar

Re: [Numpy-discussion] Proposal of timeline for dropping Python 2.7 support

On Fri, Nov 10, 2017 at 2:03 PM, Robert McLeod wrote: > Pip repo names and actual module names don't have to be the same. One > potential work-around would be to make a 'numpylts' repo on PyPi which is > the 1.17 version with support for Python 2.7 and bug-fix releases as > required. This will

Re: [Numpy-discussion] Proposal of timeline for dropping Python 2.7 support

On Fri, Nov 17, 2017 at 4:35 AM, Peter Cock wrote: > Since Konrad Hinsen no longer follows the NumPy discussion list > for lack of time, he has not posted here - but he has commented > about this on Twitter and written up a good blog post: > > http://blog.khinsen.net/posts/2017/11/16/a-plea-for-

Re: [Numpy-discussion] Deprecate matrices in 1.15 and remove in 1.17?

On Thu, Nov 30, 2017 at 11:58 AM, Marten van Kerkwijk < m.h.vankerkw...@gmail.com> wrote: > Your point about not doing things in the python 2->3 move makes sense; > But this is NOT the 2->3 move -- numpy as been py3 compatible for years. At some point, it is a really good idea to deprecate some t

Re: [Numpy-discussion] NEP process update

Great idea -- thanks for pushing this forward all. In the end, you can have the NEPs in a separate repo, and still publish them closely with the main docs (intersphinx is pretty cool), or have them in the same repo and publish them separately. So I say let the folks doing the work decide what wor

[Numpy-discussion] Setting custom dtypes and 1.14

Hi all, I'm pretty sure this is the same thing as recently discussed on this list about 1.14, but to confirm: I had failures in my code with an upgrade for 1.14 -- turns out it was a single line in a single test fixture, so no big deal, but a regression just the same, with no deprecation warning.

Re: [Numpy-discussion] Setting custom dtypes and 1.14

On Fri, Jan 26, 2018 at 10:48 AM, Allan Haldane wrote: > > What do folks think about a totuple() method — even before this I’ve > > wanted that. But in this case, it seems particularly useful. > > Two thoughts: > > 1. `totuple` makes most sense for 2d arrays. But what should it do for > 1d or 3

Re: [Numpy-discussion] Setting custom dtypes and 1.14

On Fri, Jan 26, 2018 at 2:35 PM, Allan Haldane wrote: > As I remember, numpy has some fairly convoluted code for array creation > which tries to make sense of various nested lists/tuples/ndarray > combinations. It makes a difference for structured arrays and object > arrays. I don't remember the

Re: [Numpy-discussion] Setting custom dtypes and 1.14

On Sat, Jan 27, 2018 at 8:50 PM, Allan Haldane wrote: > On 01/26/2018 06:01 PM, josef.p...@gmail.com wrote: > >> I thought recarrays were pretty cool back in the day, but pandas is >> a much better option. >> >> So I pretty much only use structured arrays for data exchange with C >>

Re: [Numpy-discussion] Setting custom dtypes and 1.14

On Mon, Jan 29, 2018 at 7:44 PM, Allan Haldane wrote: > I suggest that if we want to allow either means over fields, or conversion > of a n-D structured array to an n+1-D regular ndarray, we should add a > dedicated function to do so in numpy.lib.recfunctions > which does not depend on the binary

Re: [Numpy-discussion] Extending C with Python

I'm guessing you could use Cython to make this easier. It's usually used for calling C from Python, but can do the sandwich in both directions... Just a thought -- it will help with some of that boilerplate code... -CHB On Tue, Jan 30, 2018 at 10:57 PM, Jialin Liu wrote: > Amazing! It works

Re: [Numpy-discussion] improving arange()? introducing fma()?

On Wed, Feb 7, 2018 at 12:09 AM, Ralf Gommers wrote: > > It is partly a plea for some development of numerically accurate >> functions for computing lat/lon grids from a combination of inputs: bounds, >> counts, and resolutions. >> > Can you be more specific about what problems you've run into --

Re: [Numpy-discussion] improving arange()? introducing fma()?

I think it's all been said, but a few comments: On Sun, Feb 11, 2018 at 2:19 PM, Nils Becker wrote: > Generating equidistantly spaced grids is simply not always possible. > exactly -- and linspace gives pretty much teh best possible result, guaranteeing tha tthe start an end points are exact, a

Re: [Numpy-discussion] improving arange()? introducing fma()?

@Ben: Have you found a solution to your problem? Are there thinks we could do in numpy to make it better? -CHB On Mon, Feb 12, 2018 at 9:33 AM, Chris Barker wrote: > I think it's all been said, but a few comments: > > On Sun, Feb 11, 2018 at 2:19 PM, Nils Becker > wrote

Re: [Numpy-discussion] improving arange()? introducing fma()?

On Thu, Feb 22, 2018 at 11:57 AM, Sebastian Berg wrote: > > First, you are right...Decimal is not the right module for this. I > > think instead I should use the 'fractions' module for loading grid > > spec information from strings (command-line, configs, etc). The > > tricky part is getting the

Re: [Numpy-discussion] improving arange()? introducing fma()?

On Fri, Feb 9, 2018 at 1:16 PM, Matthew Harrigan wrote: > I apologize if I'm missing something basic, but why are floats being > accumulated in the first place? Can't arange and linspace operations with > floats be done internally similar to `start + np.arange(num_steps) * > step_size`? I.e. al

Re: [Numpy-discussion] new NEP: np.AbstractArray and np.asabstractarray

On Sat, Mar 10, 2018 at 1:27 PM, Matthew Rocklin wrote: > I'm very glad to see this discussion. > me too, but > I think that coming up with a single definition of array-like may be > difficult, and that we might end up wanting to embrace duck typing instead. > exactly -- I think there is

Re: [Numpy-discussion] best way of speeding up a filtering-like algorithm

sorry, not enough time to look closely, but a couple general comments: On Wed, Mar 28, 2018 at 5:56 PM, Moroney, Catherine M (398E) < catherine.m.moro...@jpl.nasa.gov> wrote: > I have the following sample code (pretty simple algorithm that uses a > rolling filter window) and am wondering what the

Re: [Numpy-discussion] best way of speeding up a filtering-like algorithm

one other note: As a rule, using numpy array operations from Cython doesn't buy you much, as you discovered. YOu need to use numpy arrays as n-d containers, and write the loops yourself. You may want to check out numba as another alternative -- it DOES optimize numpy operations. -CHB On Wed,

Re: [Numpy-discussion] A roadmap for NumPy - longer term planning

On Fri, Jun 1, 2018 at 4:43 AM, Marten van Kerkwijk < m.h.vankerkw...@gmail.com> wrote: > one thing that always slightly annoyed me is that numpy math is way > slower for scalars than python math > numpy is also quite a bit slower than raw python for math with (very) small arrays: In [31]: % t

Re: [Numpy-discussion] A roadmap for NumPy - longer term planning

On Fri, Jun 1, 2018 at 9:46 AM, Chris Barker wrote: > numpy is also quite a bit slower than raw python for math with (very) > small arrays: > doing a bit more experimentation, the advantage is with pure python for over 10 elements (I got bored...). but I noticed that the time

Re: [Numpy-discussion] Dropping Python 3.4 support for NumPy 1.16

> > I think NumPy 1.16 would be a good time to drop Python 3.4 support. >> > +1 Using python3 before 3.5 was still kinda "bleeding edge" -- so projects are more likely to be actively upgrading. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R

Re: [Numpy-discussion] Adoption of a Code of Conduct

On Thu, Aug 2, 2018 at 3:35 AM, Marten van Kerkwijk < m.h.vankerkw...@gmail.com> wrote: > If we do end up with a different version, I'd prefer a really short one, > like just stating the golden rule (treat others as one would like to be > treated oneself). > Unfortunately, the golden rule is some

Re: [Numpy-discussion] Adoption of a Code of Conduct

On Fri, Aug 3, 2018 at 8:59 AM, Hameer Abbasi wrote > > > I’ve created a PR, and I’ve kept the language “not too stern”. > https://github.com/scipy/scipy/pull/9109 > Thanks -- for ease of this thread, the sentence Hameer added is: "We expect that you will extend the same courtesy and open-minded

Re: [Numpy-discussion] Adoption of a Code of Conduct

:44 AM, Chris Barker wrote: > On Fri, Aug 3, 2018 at 8:59 AM, Hameer Abbasi > wrote >> >> >> I’ve created a PR, and I’ve kept the language “not too stern”. >> https://github.com/scipy/scipy/pull/9109 >> > > Thanks -- for ease of this thread, the sentenc

Re: [Numpy-discussion] Adoption of a Code of Conduct

On Fri, Aug 3, 2018 at 11:20 AM, Chris Barker wrote: > Given Jupyter, numpy, scipy, matplotlib?, etc, are all working on a CoC -- > maybe we could have NumFocus take a lead on this for the whole community? > or adopt an existing one, like maybe: The Contributor Covenant <http://www

Re: [Numpy-discussion] Adoption of a Code of Conduct

On Fri, Aug 3, 2018 at 11:33 AM, Nelle Varoquaux wrote: I think what matters in code of conduct is community buy-in and the > discussions around it, more than the document itself. > This is a really good point. Though I think a community could still have that discussion around whether and which

Re: [Numpy-discussion] Adoption of a Code of Conduct

On Fri, Aug 3, 2018 at 12:45 PM, Stefan van der Walt wrote: > I'll note that at least the Contributor Covenant is pretty vague about >> enforcement: >> >> """ >> All complaints will be reviewed and investigated and will result in a >> response that is deemed necessary and appropriate to the circu

Re: [Numpy-discussion] Adoption of a Code of Conduct

> On August 4, 2018 00:23:44 Matthew Harrigan > wrote: > >> One concern I have is the phrase "explicitly honour" in "we explicitly >> honour diversity in: age, culture, ...". Honour is a curious word choice. >> honour is defined as, among >> other things

Re: [Numpy-discussion] Adoption of a Code of Conduct

rom potentially marginalized or targeted groups feel welcome and my edit > addresses that more directly than the original. But in principle the > difference, to me at least, is stark. Thank you for considering my view. > > > On Mon, Aug 6, 2018 at 1:58 PM, Chris Barker > wrote: >

Re: [Numpy-discussion] pytest, fixture and parametrize

On Wed, Aug 8, 2018 at 9:38 AM, Evgeni Burovski wrote: > Stdlib unittest supports self.assertRaises context manager from python 3.1 > but that requires using unittest :-) On Wed, Aug 8, 2018, 7:30 PM Eric Wieser > wrote: > >> You forget that we already have that feature in our testing layer, >

Re: [Numpy-discussion] Taking back control of the #numpy irc channel

On Wed, Aug 8, 2018 at 9:06 AM, Sebastian Berg > If someone is unhappy with us two being the main > contact/people who have those right on freenode, On the contrary, thanks much for taking this on! -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R

Re: [Numpy-discussion] Dropping 32-bit from macOS wheels

On Tue, Aug 14, 2018 at 2:17 AM, Matthew Brett wrote: > We are planning to drop 32-bit compatibility from the numpy macOS > wheels. +1 -- it really is time. I note that python.org has finally gone 64 bit only -- at least for the default download: """ For 3.7.0, we provide two binary installer

Re: [Numpy-discussion] Add pybind11 to docs about writing binding code

On Mon, Aug 20, 2018 at 8:57 AM, Neal Becker wrote: > I'm confused, do you have a link or example showing how to use > xtensor-python without pybind11? > I think you may have it backwards: """ The Python bindings for xtensor are based on the pybind11 C++ library, which enables seemless interope

Re: [Numpy-discussion] A minor milestone

There are probably a LOT of Windows users getting numpy from conda as well. (I know my CI's and users do...) It'd be nice if there was some way to track real usage! -CHB On Sat, Sep 8, 2018 at 3:44 PM, Charles R Harris wrote: > > > On Fri, Sep 7, 2018 at 11:16 PM Andrew Nelson wrote: > >> >

Re: [Numpy-discussion] asanyarray vs. asarray

On Fri, Oct 26, 2018 at 7:12 PM, Travis Oliphant wrote: > agree that we can stop bashing subclasses in general. The problem with > numpy subclasses is that they were made without adherence to SOLID: > https://en.wikipedia.org/wiki/SOLID. In particular the Liskov > substitution principle: ht

Re: [Numpy-discussion] asanyarray vs. asarray

On Tue, Oct 30, 2018 at 2:22 PM, Stephan Hoyer wrote: > The Liskov substitution principle (LSP) suggests that the set of > reasonable ndarray subclasses are exactly those that could also in > principle correspond to a new dtype. Of np.ndarray subclasses in > wide-spread use, I think only the vari

Re: [Numpy-discussion] [SPAM]Re: introducing Numpy.net, a pure C# implementation of Numpy

On Mon, Mar 18, 2019 at 1:19 PM Paul Hobson wrote: > >> I'm a civil engineer who adopted Python early in his career and became > the "data guy" in the office pretty early on. Our company's IT department > manages lots of Windows Servers running SQL Server. In my case, running > python apps on our

Re: [Numpy-discussion] Boolean arrays with nulls?

On Thu, Apr 18, 2019 at 10:52 AM Stuart Reynolds wrote: > Is float8 a thing? > no, but np.float16 is -- so at least only twice as much memory as youo need :-) array([ nan, inf, -inf], dtype=float16) I think masked arrays are going to be just as much, as they need to carry the mask. -CHB >

Re: [Numpy-discussion] grant proposal for core scientific Python projects (rejected)

On Thu, May 2, 2019 at 11:51 PM Ralf Gommers wrote: > On Fri, May 3, 2019 at 3:49 AM Stephen Waterbury > wrote: > >> P.S. If anyone wants to continue this discussion at SciPy 2019, >> I will be there (on my own nickel! ;) ... >> > So will I (on NOAA's nickel, which I am grateful for) Maybe we

Re: [Numpy-discussion] grant proposal for core scientific Python projects (rejected)

On Fri, May 3, 2019 at 9:56 AM Stephen Waterbury wrote: > Sure, I would be interested to discuss, let's try to meet up there. > > OK< that's two of us :-) NumFocus folk: Should we take this off the list and talk about a BoF or something at SciPy? -CHB > Steve >

[Numpy-discussion] Style guide for numpy code?

Hey all, Do any of you know of a style guide for computational / numpy code? I don't mean code that will go into numpy itself, but rather, users code that uses numpy (and scipy, and...) I know about (am a proponent -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/N

[Numpy-discussion] numpy finding local tests on import?!?!

TL;DR: This issue appears to have been fixed in numpy 1.15 (at least, I didn't test 1.14) However, I also had some issues in my environment that I also fixed, so it may be that numpy's behavior hasn't changed -- I don't have the energy to test now. And it doesn't hurt to have this in the archive

Re: [Numpy-discussion] defining a NumPy API standard?

On Sun, Jun 2, 2019 at 3:45 AM Dashamir Hoxha wrote: > > Would it be useful if we could integrate the documentation system with a > discussion forum (like Discourse.org)? Each function can be linked to its > own discussion topic, where users and developers can discuss about the > function, upvote

Re: [Numpy-discussion] defining a NumPy API standard?

One little point here: > * np.ndarray.cumprod: low importance -> prefer np.multiply.accumulate >> > I think that's and example of something that *should* be part of the numpy API, but should be implemented as a mixin, based on np.multiply.accumulate. As I'm a still confused about the goal her

[Numpy-discussion] How to Capitalize numpy?

Trivial note: On the subject of naming things (spelling things??) -- should it be: numpy or Numpy or NumPy ? All three are in the draft NEP 30 ( mostly "NumPy", I noticed this when reading/copy editing the NEP) . Is there an "official" capitalization? My preference, would be to use "numpy", and

Re: [Numpy-discussion] NEP 30 - Duck Typing for NumPy Arrays - Implementation

On Mon, Aug 12, 2019 at 4:02 AM Peter Andreas Entschev wrote: > Apologies for the late reply. I've opened a new PR > https://github.com/numpy/numpy/pull/14257 with the changes requested > thanks! I've written a small PR on your PR: https://github.com/pentschev/numpy/pull/1 Essentially, other

[Numpy-discussion] Add a total_seconds() method to timedelta64?

I just noticed that there is no obvious way to convert a timedelta64 to seconds (or some other easy unit) as a number. The stdlib datetime.datetime has a .total_seconds() method for doing that. I think it's a handy thing to have. Looking at StackOverflow (and others), I see people suggesting thin

Re: [Numpy-discussion] How to Capitalize numpy?

;s one occurrence >> of "Numpy", which was definitely a typo and I had not noticed it until >> now, but I will address this on a future update, thanks for pointing >> that out. >> >> [1] https://numpy.org/neps/nep-0030-duck-array-protocol.html >> >

Re: [Numpy-discussion] How to Capitalize numpy?

onym, so that leaves the options of "Numpy" and "NumPy". > It would be great, easy to remember, consistent for others, etc., if NumPy > and SciPy were capitalized the same way and were pronounced the same (I > still occasionally hear "numpee"). So, I would favo

Re: [Numpy-discussion] NEP 30 - Duck Typing for NumPy Arrays - Implementation

On Mon, Sep 16, 2019 at 1:46 PM Peter Andreas Entschev wrote: > What would be the use case for a duck-array to implement __array__ and > return a NumPy array? some users need a genuine, actual numpy array (for passing to Cyton code, for example). if __array__ is not implemented, how can they ge

Re: [Numpy-discussion] NEP 30 - Duck Typing for NumPy Arrays - Implementation

On Mon, Sep 16, 2019 at 2:27 PM Stephan Hoyer wrote: > On Mon, Sep 16, 2019 at 1:45 PM Peter Andreas Entschev > wrote: > >> What would be the use case for a duck-array to implement __array__ and >> return a NumPy array? > > > Dask arrays are a good example. They will want to implement __duck_ar

Re: [Numpy-discussion] NEP 30 - Duck Typing for NumPy Arrays - Implementation

array-like object. So it's probably a good idea to recommend that when a class implements __dauckarray__ that it also implements __array__, which can either raise an exception or return and ndarray. -CHB On Mon, Sep 16, 2019 at 3:11 PM Chris Barker wrote: > On Mon, Sep 16, 2019 at 2:

Re: [Numpy-discussion] NEP 30 - Duck Typing for NumPy Arrays - Implementation

Here's a PR with a different dicsussion of __array__: https://github.com/numpy/numpy/pull/14529 -CHB On Mon, Sep 16, 2019 at 3:23 PM Chris Barker wrote: > OK -- I *finally* got it: > > when you pass an arbitrary object into np.asarray(), it will create an > array objec

Re: [Numpy-discussion] NEP 30 - Duck Typing for NumPy Arrays - Implementation

On Tue, Sep 17, 2019 at 6:56 AM Peter Andreas Entschev wrote: > I agree with your point and understand how the current text may be > misleading, so we shall make it clearer in the NEP (as done in > https://github.com/numpy/numpy/pull/14529) that both are valid ways: > > * Have a genuine implement

Re: [Numpy-discussion] New DTypes: Are scalars a central concept in NumPy or not?

I've always found the duality of zero-d arrays an scalars confusing, and I'm sure I'm not alone. Having both is just plain weird. But, backward compatibility aside, could we have ONLY Scalars? When we index into an array, the dimensionality is reduced by one, so indexing into a 1D array has to g

Re: [Numpy-discussion] Good use of __dunder__ methods in numpy

On Thu, Mar 5, 2020 at 2:15 PM Gregory Lee wrote: > If i can get a link to a file that shows how dunder methods help with >> having cool coding APIs that would be great! >> >> > You may want to take a look at PEP 465 as an example, then. If I recall > correctly, the __matmul__ method described in

  1   2   >