Re: [Numpy-discussion] reducing effort spent on wheel builds?

Just a note on: > For the record, I am +1 on removing sdists from PyPI until pip changes its default to --only-binary :all: [1] I agree that the defaults for pip are unfortunate (and indeed the legacy of pip doing, well, a lot, (i.e. building and installing and package managing and dependencies,

Re: [Numpy-discussion] Best fit linear piecewise function?

ng this and seem to like it: > > > > https://jekel.me/piecewise_linear_fit_py/about.html > > <https://jekel.me/piecewise_linear_fit_py/about.html> > > > > > > Date: Tue, 1 Jun 2021 17:22:52 -0700 > > From: Chris Barker > <mailto:ch

Re: [Numpy-discussion] Best fit linear piecewise function?

On Thu, Jun 3, 2021 at 4:13 AM Mark Bakker wrote: > My students are using this and seem to like it: > > https://jekel.me/piecewise_linear_fit_py/about.html > thanks -- that looks perfect! -CHB > > >> Date: Tue, 1 Jun 2021 17:22:52 -0700 >> From: Chris Barker

Re: [Numpy-discussion] Best fit linear piecewise function?

it seems to be a fit, rather than exactly matching a subset of points. but as I think about it, for my use case, it might actually work well. I'll give it a try -- thanks! -CHB > > On 6/2/21 2:22 AM, Chris Barker wrote: > > Do any of you know of code for finding an optimum linear pie

[Numpy-discussion] Best fit linear piecewise function?

Do any of you know of code for finding an optimum linear piecewise fit to a set of points? Somethin like what is described in this article: https://www.hindawi.com/journals/mpe/2015/876862/ At a glance, that looked just hard enough to code up that I'm hoping someone has already done it :-)

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

On Wed, Apr 8, 2020 at 1:17 PM Sebastian Berg wrote: > > > > But, backward compatibility aside, could we have ONLY Scalars? > > > Well, it is hard to write functions that work on N-Dimensions > > > (where N > > > can be 0), if the 0-D array does not exist. > > So as a (silly) example, the

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

sorry to have fallen off the numpy grid for a bit, but: On Mon, Mar 23, 2020 at 1:37 PM Sebastian Berg wrote: > On Mon, 2020-03-23 at 11:45 -0700, Chris Barker wrote: > > But, backward compatibility aside, could we have ONLY Scalars? > > Well, it is hard to write functions

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

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

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

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 o

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

-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:27 PM Step

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

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

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

t;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 favor "NumPy" to go al

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

urrence >> 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 >> >> On M

[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

[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",

Re: [Numpy-discussion] converting a C bytes array to two dimensional numpy array

You can also directly build a numpy array from a pointer with the numpy API. And I recommend Cython as an interface to make these things easy. This does mean you’d need to have the numpy lib at build time, .which may be a downside. -CHB Christopher Barker, Ph.D. Oceanographer Emergency

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

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,

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

> Exactly. This is great, thanks Marten. I agree with pretty much everything in > this list. For my part, a few things immediately popped out at my that I disagree with. ;-) Which does not mean it isn’t a useful exercise, but it does mean we should expect a fair bit of debate. But I do think

Re: [Numpy-discussion] GSoD - Technical Writter

> a responsive web page may not be an absolute requirement, but still it may be nice to be able to read the docs from a tablet or smartphone. Unfortunately I am not familiar yet with Sphinx, but I hope that it can be integrated with Jekyll or Hugo, and then one of their templates can be used.

Re: [Numpy-discussion] Style guide for numpy code?

are short, so more > terms can fit in one 80 character line. > > Overall, having and following a style makes code easier to read. And, as > an added bonus, if you take care to be consistent, you will write slower, > view your code more times, and catch more bugs as you write them.

[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

Re: [Numpy-discussion] Style guide for numpy code?

Oops, Somehow that got sent before I was done. (Like my use of the passive voice there?) Here is a complete message: 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...)

[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

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

his even exists ... :) >>> Not only do I not know of that, but I know of NASA policies that make >>> it very difficult for NASA civil servants to contribute to open source >>> projects -- quite hypocritical, given the amount of open source >>> code that NASA (li

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

On May 4, 2019, at 9:00 AM, Ralf Gommers Okay never mind, this is apparently happening already: https://hackmd.io/YbxTpC1ZT_aEapTqydmHCA. Please jump in there instead:) Slightly different focus than I had in mind, but yes, it makes sense to join that effort. -CHB Ralf > Cheers, > Ralf >

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 > > On 5

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

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

Sounds like this is a NASA specific thing, in which case, I guess someone at NASA would need to step up. I’m afraid I know no pythonistas at NASA. But I’ll poke around NOAA to see if there’s anything similar. -CHB On Apr 25, 2019, at 1:04 PM, Ralf Gommers wrote: On Sat, Apr 20, 2019 at

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

Re: [Numpy-discussion] Numpy-discussion

> On Jan 29, 2019, at 12:15 AM, Matti Picus wrote: >> Perhaps you could suggest they add this explanation (or if it is in our >> documentation point out where you think would be appropriate) since it seems >> many people have problems with dtypes and overflow. arange() is particularly

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

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:

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] 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

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

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

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

> On Aug 8, 2018, at 5:40 PM, Matti Picus wrote: > We have these guidelines http://www.numpy.org/devdocs/reference/testing.html, Thanks Matti — that’s clearly the place to document best practices. > It was updated for pytest in the 1.15 release, but could use some more > editing and

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] pytest, fixture and parametrize

> as to whether we are should use pytest fixtures and parametrized classes and > functions. Absolutely! > the disadvantage is being dependent on pytest as unittest does not support that functionality. Which is the whole point of using pytest, yes? I’m very opinionated about this, but I

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

zed 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: > >> >> On Augu

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

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

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

: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 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

Re: [Numpy-discussion] Roadmap proposal, v3

> Obviously the string dtype proposal in the roadmap is only a sketch at this > point :). > > I do think that options listed currently (encoded strings with fixed-width > storage and variable length strings) cover the breadth of proposals from last > time. We may not want to implement all of

Re: [Numpy-discussion] Roadmap proposal, v3

Great work, thanks! I see this: “- Fixed width encoded strings (utf8, latin1, ...)” And a bit of discussion in the PR. But I think there are key questions to be addressed in handling strings in numpy. I know we’ve had a lot of discussion about it on this list over the years — but is there a

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

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] 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]: %

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

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

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 +

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 >

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 <chris.bar...@noaa.gov> wrote: > I think it's all been said, but a few comments: > > On Sun, Feb 11, 2018 at 2:19

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

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

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: >

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

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 >

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

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

> On Jan 25, 2018, at 4:06 PM, Allan Haldane wrote: >> 1) This is a known change with good reason? > . The > change occurred because the old assignment behavior was dangerous, and > was not doing what you thought. OK, that’s a good reason! >> A) improve the error

[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

Re: [Numpy-discussion] Using np.frombuffer and cffi.buffer on array of C structs (problem with struct member padding)

The numpy dtype constructor takes an “align” keyword that will pad it for you. https://docs.scipy.org/doc/numpy-1.13.0/reference/generated/numpy.dtype.html -CHB ___ NumPy-Discussion mailing list NumPy-Discussion@python.org

Re: [Numpy-discussion] Using np.frombuffer and cffi.buffer on array of C structs (problem with struct member padding)

Sent from my iPhone > On Jan 25, 2018, at 6:51 AM, Joe wrote: > > Hello, > > how I could dynamically handle the dtype of a structured array when reading > an array of C structs with np.frombuffer (regarding the member padding in the > struct). > > So far I manually adjusted

Re: [Numpy-discussion] NumPy 1.14.0rc1 release

Thanks Chuck! And a huge thanks to that awesome list of contributors!!! -Chris Sent from my iPhone On Dec 13, 2017, at 2:55 PM, Charles R Harris wrote: Hi All, On behalf of the NumPy team, I am pleased to announce NumPy 1.14.0rc1. Numpy 1.14.0rc1 is the result of

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

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

Re: [Numpy-discussion] Type annotations for NumPy

(a) it would be good if NumPy type annotations could include an “array_like” type that allows lists, tuples, etc. I think that would be a sequence — already supported by the Typing system. (b) I’ve always thought (since PEP561) that it would be cool for type annotations to replace compiler type

Re: [Numpy-discussion] Type annotations for NumPy

On Nov 25, 2017, at 3:35 PM, Matthew Rocklin wrote: Thoughts on basing this on a more generic Array type rather than the np.ndarray? This would actually be more consistent with the current python typing approach. I can imagine other nd-array libraries (XArray, Tensorflow,

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: > >

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

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

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: >> >>

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

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

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()

Re: [Numpy-discussion] List comprehension and loops performances with NumPy arrays

Andrea, One note: transposing is almost free — it just rearranges the strides — I.e. changed how the array is interpreted. It doesn’t actually move the data around. -CHB Sent from my iPhone On Oct 7, 2017, at 2:58 AM, Andrea Gavana wrote: Apologies, correct timeit

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

Re: [Numpy-discussion] Only integer scalar arrays can be converted to a scalar index

No thoughts on optimizing memory, but that indexing error probably comes from np.mean producing float results. An astype call shoulder that work. -CHB Sent from my iPhone On Sep 15, 2017, at 5:51 PM, Robert McLeod wrote: On Fri, Sep 15, 2017 at 2:37 PM, Elliot Hallmark

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,

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

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

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

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

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

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

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,

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] UC Berkeley hiring developers to work on NumPy

Awesome! This is really great news. Does this mean is several person-years of funding secured? -CHB > On May 13, 2017, at 10:47 PM, Nathaniel Smith wrote: > > Hi all, > > As some of you know, I've been working for... quite some time now to > try to secure funding for NumPy. So

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

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

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

> > I DO recommend Latin-1 As a default encoding ONLY for "mostly ascii, with > > a few extra characters" data. With all the sloppiness over the years, there > > are way to many files like that. > > That sloppiness that you mention is precisely the "unknown encoding" problem. Exactly -- but

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

> On Apr 25, 2017, at 12:38 PM, Nathaniel Smith wrote: > Eh... First, on Windows and MacOS, filenames are natively Unicode. Yeah, though once they are stored I. A text file -- who the heck knows? That may be simply unsolvable. > s. And then from in Python, if you want to

  1   2   >