[Numpy-discussion] Re: Suggestion to show the shape in repr for summarized arrays

I like this. while ideally, eval(repr(an_object)) == object, in practice this is already violated fro large arays -- so other than doctests, this shouldn't cause too many headaches. -CHB On Mon, Sep 30, 2024 at 10:13 AM Marten van Kerkwijk wrote: > Hi All, > > When the repr of an array is sho

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?

ts are using 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 > <

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?

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

[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 :-) -CHB

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 follo

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 in

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

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

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

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

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

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

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?

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

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

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

;s best if variables that will appear in formulae 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

[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] 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 NOAA/N

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

now say you know >>> yet another person at NASA who has no idea this 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 hy

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 >

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)

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

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] adding Quansight Labs as institutional partner

Another consideration is that some organizations, the US federal government, for instance, cannot make donations. I wouldn’t be surprised if some Universities might have similar restrictions on using grant money to make a donation to a non-profit. Is there any way for NumFocus to accept funds in a

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

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

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

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

BTW: with pytest.raises(AnException): Is another nice feature. -CHB ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion

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 really

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

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

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

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 p

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

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

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

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

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] 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] 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] 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 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 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 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 message. > > Good idea. I'll s

[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] 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 https://mail.python.org/mailm

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 the dtype of the stru

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 seven months of work and con

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

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] 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, Dask.array) wanting t

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] 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 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] 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 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] 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] 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] 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 code this time (I had gotten

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] 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 wrote: > Nope. Numpy

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

  1   2   >