[Numpy-discussion] Re: numpy 2.0.x has been branched.

Maybe someone composes another preemptive blog post about this? I think this needs some banging on the pans to soften its landing since NumPy 2.0 is a big deal. The community will take care of its circulation in typical places. We always get the grilling no matter the outcome :) But I think it is

[Numpy-discussion] Re: New matvec and vecmat functions

For dot product I can convince myself this is a math definition thing and accept the conjugation. But for "vecmat" why the complex conjugate of the vector? Are we assuming that 1D things are always columns. I am also a bit lost on the difference of dot, vdot and vecdot. Also if __matmul__ and

[Numpy-discussion] Re: Function that searches arrays for the first element that satisfies a condition

It's typically called short-circuiting or quick exit when the target condition is met. if you have an array a = np.array([-1, 2, 3, 4, , 1]) and you are looking for a true/false result whether anything is negative or not (a < 0).any() will generate a bool array equal to and then check all

[Numpy-discussion] Re: welcome Andrew Nelson to the NumPy maintainers team

Congratulations Andrew! On Tue, Aug 22, 2023 at 9:44 PM Daniela Cialfi wrote: > > Welcome on board > > Daniela > > > On Tue, 22 Aug 2023 at 16:06, Charles R Harris > wrote: > >> >> >> On Mon, Aug 21, 2023 at 10:09 PM Andrew Nelson >> wrote: >> >>> On Mon, 21 Aug 2023 at 18:39, Ralf Gommers

[Numpy-discussion] Re: Add to NumPy a function to compute cumulative sums from 0.

agree with this strategy being better. I'm not against it, clearly there is a demand, but probably inconvenience should not be the reason for keyword arguments elsewhere. On Fri, Aug 18, 2023 at 9:13 AM Ronald van Elburg < r.a.j.van.elb...@hetnet.nl> wrote: > Ilhan Polat wrote: >

[Numpy-discussion] Re: Add to NumPy a function to compute cumulative sums from 0.

On Tue, Aug 15, 2023 at 2:44 PM wrote: > > From my point of view, such function is a bit of a corner-case to be > added to numpy. And it doesn’t justify it’s naming anymore. It is not one > operation anymore. It is a cumsum and prepending 0. And it is very > difficult to argue why prepending 0

[Numpy-discussion] Linking F2PY to Openblas on Windows

Dear all, I'd like to submit to our f2py crew here for a seemingly trivial problem that has been bugging me for a while. I am trying to compile a Fortran library (SLICOT [1] ) on windows with MinGW UCRT 64 interface. But let me simplify the issue. Let say I have a fortran file, MB01OE.f. It is a

[Numpy-discussion] Re: non normalised eigenvectors

Could you elaborate a bit more about what you mean with original eigenvectors? They denote the direction hence you can scale them to any size anyways. On Sat, Feb 25, 2023 at 5:38 PM wrote: > Dear all, > > I am not an expert in NumPy but my undergraduate student is having some > issues with the

[Numpy-discussion] Re: Addition of useful new functions from the array API specification

Apologies for the rant. On Thu, Dec 8, 2022 at 11:54 PM Aaron Meurer wrote: > On Wed, Dec 7, 2022 at 3:49 PM Ilhan Polat wrote: > > > > > > On matrix_transpose() : > > Every time this discussion brought up, there was a huge resistance to > add more methods to ar

[Numpy-discussion] Re: Addition of useful new functions from the array API specification

On matrix_transpose() : Every time this discussion brought up, there was a huge resistance to add more methods to array object or new functions (I have been involved in some of them on the pro .H side, links you have given and more in the mailing list) and now we are adding .mT and not .H? That is

[Numpy-discussion] Re: status of long double support and what to do about it

Thanks Ralf, this indeed strikes a chord also from SciPy point of view. In my limited opinion, it's not just the dtype but also everything else that this dtype is going to be used in defines its proper implementation. Upstream (lapack, fft, so on) and downstream (practically everything else) does

[Numpy-discussion] Re: How will Google DeepMind's AlphaTensor effect numpy

Moreover, not to mention the result is mostly valid for mod2 aritmetic; something the authors chose to mention it in the fine print causing this, a bit overblown in my opinion, excitement. So for now it seems like we don't need to take action for regular matmul. On Wed, Oct 26, 2022, 16:03

[Numpy-discussion] Re: Feature request: dot product along arbitrary axes

It might be just me, that @ product is way more readable than chaining different operators below that I don't find readable at all but anyways that's taste I guess. Also if you are going to do this, for a better performance code, you shouldn't bend the ops but you should wrangle the array to the

[Numpy-discussion] Re: Feature request: dot product along arbitrary axes

I don't understand. Both theretically and coding wise Matmul is the most readable thing that you can have within those options. That is in fact what the definition is. Can you give an example? On Mon, Jul 4, 2022, 04:49 wrote: > Currently there are lots of ways to compute dot products (dot,

[Numpy-discussion] Re: Dropping the pdf documentation.

bash on the HTML, of course we > could add more breakpoints, and special casing until it looks / behaves > better. > > Until we do so, the removal of the PDFs seem awkward. > > As for CI load and metrics, we don't have hard numbers for a lot of these > things and it feels strang

[Numpy-discussion] Re: Dropping the pdf documentation.

On Mon, May 23, 2022 at 2:00 PM Rohit Goswami wrote: > The contents are nonresponsive. No tool can fix a native responsiveness > issues. I am familiar with those tools. The questions is why work so hard > when you have the HTML already? > > I'm afraid I don't understand this argument. It is

[Numpy-discussion] Re: Dropping the pdf documentation.

On Mon, May 23, 2022 at 11:12 AM Rohit Goswami wrote: > I am unaware of the state of the SciPy documentation at the time it was > dropped. However, many of these arguments do not seem to apply to the NumPy > documentation hosted at https://numpy.org/doc/. > They were almost identical, same

[Numpy-discussion] Re: Dropping the pdf documentation.

As the person initiated the PDF drop in SciPy, I'd give my reasoning for why it bugged me in the first place - The typography is \subsubpar (as a TeX person should say) and just an eyesore, this actually matters a lot more than you would assume and unreadable in mobile without constant zooming

[Numpy-discussion] Re: [Job] NumPy Open Source Developer at NVIDIA

Found the original in the spam folder. Hi all, I'm excited to share that I'm hiring a remote NumPy developer at NVIDIA! The majority of their time will be focused on open source contributions to the NumPy project, so I wanted to share the opportunity on this list. We are continuing to

[Numpy-discussion] Re: Conversion from C-layout to Fortran-layout in Cython

For the desperate souls reading this in the future; I feel your pain :) On Thu, Nov 11, 2021 at 3:36 AM Ilhan Polat wrote: > Ah I see. Thank you Sebastian, I was hoping to avoid all that blocking > (since HW dependency leaves some performance at many tables) or recursive &g

[Numpy-discussion] Re: Conversion from C-layout to Fortran-layout in Cython

On Thu, Nov 11, 2021 at 2:40 AM Sebastian Berg wrote: > On Thu, 2021-11-11 at 01:04 +0100, Ilhan Polat wrote: > > Hmm not sure I understand the question but this is what I mean by naive > > looping, suppose I allocate a scratch register work3, then > > > > for i in

[Numpy-discussion] Re: Conversion from C-layout to Fortran-layout in Cython

Ilhan Polat wrote: > Hmm not sure I understand the question but this is what I mean by naive > looping, suppose I allocate a scratch register work3, then > > for i in range(n): for j in range(n): work3[j*n+i] = work2[i*n+j] > > > > This basically doing the row to column based i

[Numpy-discussion] Re: Conversion from C-layout to Fortran-layout in Cython

level in a performant way. That's what I would like to understand or clear out my misunderstanding. On Thu, Nov 11, 2021 at 12:56 AM Andras Deak wrote: > On Thursday, November 11, 2021, Ilhan Polat wrote: > >> I've asked this in Cython mailing list but probably I should also get >

[Numpy-discussion] Re: Conversion from C-layout to Fortran-layout in Cython

uot;C", "C", , , , , matrices.IW->data(), > , > inputs.data(), , , intermediate.data(), ); > > (in this case, I was using boost multiarrays, but the basic idea is the > same). IIRC, a bunch of other lapack functions had similar features. > > I hope this is helpf

[Numpy-discussion] Conversion from C-layout to Fortran-layout in Cython

I've asked this in Cython mailing list but probably I should also get some feedback here too. I have the following function defined in Cython and using flat memory pointers to hold n by n array data. cdef some_C_layout_func(double[:, :, ::1] Am) nogil: # ... cdef double * work1 =

[Numpy-discussion] Re: What happened to the numpy.random documentation?

As a cosmic coincidence this happened to me yesterday. My goal: generate n-long arrays of 1s and -1s picked from a uniform distribution to mimic BLAS function ?LARNV. Full disclosure: I know a bit about the subject, but I'm not an expert and too lazy to gather my thoughts about it at the moment

[Numpy-discussion] Re: spam on the mailing lists

Judging by the support of it, I'll check whether I missed the whole point of Discourse when I was trying to use it, in the meantime. On Fri, Oct 1, 2021 at 7:57 PM Stephan Hoyer wrote: > On Fri, Oct 1, 2021 at 10:21 AM Ilhan Polat wrote: > >> > GitHub Discussions is more of a Q

[Numpy-discussion] Re: spam on the mailing lists

place and stick to it! > > >> >> Cheers, >> >> Matthew >> >> On Fri, Oct 1, 2021 at 4:39 PM Rohit Goswami >> wrote: >> > >> > I’m firmly against GH discussions because of the upvoting mechanism. We >> don’t need to be Redd

[Numpy-discussion] Re: spam on the mailing lists

The reason why I mentioned GH discussions is that literally everybody who is engaged with the code, is familiar with the format, included in the codebase product and has replies in built unlike the Discourse (opinion is mine) useless flat discussion design where replies are all over the place just

[Numpy-discussion] Re: spam on the mailing lists

I'd like to reheat the proposition that we enable discussion feature on GitHub for the repos. Not only this makes things a bit more streamlined (transfer nonbug reports to discussions to handle noise there) but also makes it easier to control the discussions. Moreover since it is GitHub there are

Re: [Numpy-discussion] is_triangular, is_diagonal, is_symmetric et al. in NumPy or SciPy linalg

3]] > > In [23]: M[[0, 2, 1, 3], [0, 2, 1, 3]] # outer indexing for permutation > Out[23]: > ⎡1 2 0 0⎤ > ⎢3 4 0 0⎥ > ⎢9 1 3 2⎥ > ⎣5 6 8 7⎦ > > In [24]: M.det() > Out[24]: -10 > > In [25]: M[[0,2],[0,2]].det() * M[[1, 3], [1, 3]].det() > Out[25]

Re: [Numpy-discussion] is_triangular, is_diagonal, is_symmetric et al. in NumPy or SciPy linalg

ng other > things. > (I'd be interested in contributing FWIW) > > Cheers, > > Evgeni > > > On Wed, Jun 30, 2021 at 1:22 AM Ilhan Polat wrote: > > > > Dear all, > > > > I'm writing some helper Cythpm functions for scipy.linalg which is kinda > performant an

[Numpy-discussion] is_triangular, is_diagonal, is_symmetric et al. in NumPy or SciPy linalg

Dear all, I'm writing some helper Cythpm functions for scipy.linalg which is kinda performant and usable. And there is still quite some wiggle room for more. In many linalg routines there is a lot of performance benefit if the structure can be discovered in a cheap and reliable way at the

Re: [Numpy-discussion] EHN: Discusions about 'add numpy.topk'

after a coffee, I don't see the point of calling it still "k" so "max_n" is my vote for what its worth. On Sun, May 30, 2021 at 8:38 AM Ilhan Polat wrote: > Since this going into the top namespace, I'd also vote against the > matlab-y "topk" name. And even

Re: [Numpy-discussion] EHN: Discusions about 'add numpy.topk'

Since this going into the top namespace, I'd also vote against the matlab-y "topk" name. And even matlab didn't do what I would expect and went with maxk https://nl.mathworks.com/help/matlab/ref/maxk.html I think "max_k" is a good generalization of the regular "max". Even when auto-completing,

Re: [Numpy-discussion] Guidelines for floating point comparison

Matrix powers are annoyingly tricky to keep under control due to the fact that things to explode or implode rather quickly. In fact the famous quote from Moler, Van Loan "Unfortunately, the roundoff errors in the mth power of a matrix, say B^m ,are usually small relative to ||B||^m rather than

Re: [Numpy-discussion] Pearu Peterson has joined the NumPy developers team.

This is very comforting news :) Welcome back On Sun, Feb 7, 2021 at 9:10 PM Stefan van der Walt wrote: > On Sun, Feb 7, 2021, at 10:12, Charles R Harris wrote: > > Pearu Peterson has joined the NumPy developers team. Pearu was responsible > for contributing f2py and much of distutils in the

Re: [Numpy-discussion] updated backwards compatibility and deprecation policy NEP

Hi Ralf, This reads really nice. Thanks to everyone who contributed. Before nitpicking here and there, and sticking my head for others, is this is a finished discussion and only stylistic feedback is expected? Also is it preferred here or in the PR? GitHub is really not designed for extended

Re: [Numpy-discussion] problem with numpy 1.19.4 install via pip on Win 10

Yes this is known and we are waiting MS to roll out a solution for this. Here are more details https://developercommunity2.visualstudio.com/t/fmod-after-an-update-to-windows-2004-is-causing-a/1207405 On Thu, Dec 3, 2020 at 12:57 AM Alan G. Isaac wrote: > numpy 1.19.3 installs fine. > numpy

Re: [Numpy-discussion] Comment published in Nature Astronomy about The ecological impact of computing with Python

Measuring running time of a program in arbitrary programming language is not an objective metric. Otherwise force everyone code in Assembler and we would be done as quick as possible. Hire 5 people to come to the workplace for 6 months to optimize it and we will be done with their transportation.

Re: [Numpy-discussion] Comment published in Nature Astronomy about The ecological impact of computing with Python

Do we have to take it seriously to start with? Because, with absolutely no offense meant, I am having significant difficulty doing so. On Tue, Nov 24, 2020 at 4:58 PM PIERRE AUGIER < pierre.aug...@univ-grenoble-alpes.fr> wrote: > Hi, > > I recently took a bit of time to study the comment "The

Re: [Numpy-discussion] How did Numpy get its latest version of the documentation to appear at the top of Google search results?

Have a look at here for "some" background https://github.com/scipy/docs.scipy.org/issues/39 On Fri, Nov 13, 2020 at 5:37 PM efremdan1 wrote: > I'm working with Bokeh (https://docs.bokeh.org/en/latest/), another > open-source Python package. The developers would like to have the latest > version

Re: [Numpy-discussion] start of an array (tensor) and dataframe API standardization initiative

This is great work. Thanks to everyone who contributed. Very clean user-interface too. One question: Can we propose feature requests already or is that discussion closed? On Tue, Nov 10, 2020 at 7:21 PM Ralf Gommers wrote: > Hi all, > > I'd like to share an update on this topic. The draft

[Numpy-discussion] Cythonize and add backslash logic to "scipy.linalg.solve"

Dear all, I've finally managed to draft a PR [1] for the functionality given in the title (see also "Algorithms" section of [2]). It is almost halfway done but the gist is already in place. I'm posting this to both NumPy and SciPy lists since I think it is important enough to get feedback from

Re: [Numpy-discussion] NEP Procedure Discussion

Also, not to be a complete slacker, I'd like to add to this list; - How can I help as an external lib maintainer? - Do you even want us to get involved before the final draft? Or wait until internal discussion finishes? On Fri, Aug 14, 2020 at 1:23 PM Peter Andreas Entschev wrote: > Hi all,

Re: [Numpy-discussion] Experimental `like=` attribute for array creation functions

Naming has definitely been very much on the > table since the NEP was written, but the consensus was more that > "like=" is reasonably similar enough in both application and the name > itself to "empty_like" and derived functions, that's why we just stuck > to it

Re: [Numpy-discussion] Experimental `like=` attribute for array creation functions

;> make that distinction, though. Users writing their own analysis code could >> very well be interested in writing code using numpy functions that will >> transparently work when the input is a CuPy array or whatever. >> > >> > I also share Ilhan’s concern (and I men

Re: [Numpy-discussion] Experimental `like=` attribute for array creation functions

For what is worth, as a potential consumer in SciPy, it really doesn't say anything (both in NEP and the PR) about how the regular users of NumPy will benefit from this. If only and only 3rd parties are going to benefit from it, I am not sure adding a new keyword to an already confusing function

Re: [Numpy-discussion] Type declaration to include all valid numerical NumPy types for Cython

ed. > > You need to either provide your own or use a casting table and the copy / > conversion routines from somewhere. Cython, to my knowledge, doesn't > provide these things, but Numpy does. > > Eric > > On Sun, Aug 9, 2020 at 6:16 PM Ilhan Polat wrote: > >> Hi

[Numpy-discussion] Type declaration to include all valid numerical NumPy types for Cython

Hi all, As you might have seen my recent mails in Cython list, I'm trying to cook up an input validator for the linalg.solve() function. The machinery of SciPy linalg is as follows: Some input comes in passes through np.asarray() then depending on the resulting dtype of the numpy array we choose

Re: [Numpy-discussion] Proposal to add clause to license prohibiting use by oil and gas extraction companies

Ralf basically wrote the email that I was about the send in a much more structured way so thanks for that. I'd like to mention also that oil industry practically cannot be cornered by these restrictions. So even the cause is very noble and I wholeheartedly agree, forcing this type of exclusions

Re: [Numpy-discussion] NumPy team update

This is great. Can we have a SciPy version too Ralf? On Fri, Jun 19, 2020 at 6:31 PM Devulapalli, Raghuveer < raghuveer.devulapa...@intel.com> wrote: > Hi Ralf, > > > > Thank you for the acknowledgement. I am happy to contribute and hope to > continue to do so in the future. > > > > Raghuveer >

Re: [Numpy-discussion] log of negative real numbers -> RuntimeWarning: invalid value encountered in log

I wasted a good 2 weeks because of that behavior of Matlab back in the day and I think that is one of the cardinal sins that matlab commits. If need be there are alternatives as mentioned before but I definitely do not prefer this coercion at all. On Mon, May 25, 2020 at 5:18 PM Sebastian Berg

Re: [Numpy-discussion] Feelings about type aliases in NumPy

or the time being we just inlined a definition like > Union[float, np.floating], but conceivably we would want to unify > those definitions somewhere instead of redefining them in every > project. (Note that existing types like SupportsInt etc. were not what > we wanted.) This perhaps suggests t

Re: [Numpy-discussion] Feelings about type aliases in NumPy

I agree that parking all these in a secondary namespace sounds a better option, can't say that I feel for the word "typing" though. There are already too many type, dtype, ctypeslib etc. Maybe we can go for a bit more distant name like "numpy.annotations" or whatever. On Sat, Apr 25, 2020 at 8:51

Re: [Numpy-discussion] Output type of round is inconsistent with python built-in

ple used np.round(), not the builtin round(). np.round() is not > changing. If you want the dtype of the output to be the dtype of the input, > you can certainly keep using np.round() (or its canonical spelling, > np.around()). > > On Thu, Feb 27, 2020, 12:05 AM Ilhan Polat wrote: &

Re: [Numpy-discussion] Output type of round is inconsistent with python built-in

It's not about what I want but this changes the output of round. In my example I didn't use any arrays but a scalar type which looks like will upcasted. On Wed, Feb 26, 2020, 23:04 Robert Kern wrote: > On Wed, Feb 26, 2020 at 5:41 PM wrote: > >> >> >> On Wed, Feb 2

Re: [Numpy-discussion] Output type of round is inconsistent with python built-in

Does this mean that np.round(np.float32(5)) return a 64 bit upcasted int? That would be really awkward for many reasons pandas frame size being bloated just by rounding for an example. Or numpy array size growing for no apparent reason I am not really sure if I understand why LSP should hold in

Re: [Numpy-discussion] Disallow Accelerate as a LAPACK backend for NumPy

We have a wiki page with all the details on scipy repo for the rationale of why we wanted to drop it. There is no need to discuss further about the situation of Accelerate. On Fri, Nov 15, 2019, 15:41 Ralf Gommers wrote: > > > On Fri, Nov 15, 2019 at 5:27 AM Matti Picus wrote: > >> On Tue,

Re: [Numpy-discussion] NEP 32: Remove the financial functions from NumPy

+1 on removing them from NumPy. I think there are plenty of alternatives already so many that we might even consider deprecating them just like SciPy misc module by pointing to alternatives. On Tue, Sep 3, 2019 at 6:38 PM Sebastian Berg wrote: > On Tue, 2019-09-03 at 08:56 -0400, Warren

Re: [Numpy-discussion] Fwd: Re: Calling BLAS functions from Python

The inplace overwriting is done if f2py can forward the original array down to the low level. When it is not contiguous then it has to somehow marshall the view into a compatible array and that is when the inbetween array is formed. And also that array can also be overwritten but that would not

Re: [Numpy-discussion] [SciPy-Dev] Season of Docs - welcome Anne, Maja, Brandon

Great news, welcome all! On Wed, Aug 7, 2019 at 1:47 AM Ralf Gommers wrote: > Hi all, > > Google has announced the Season of Docs participants for this year [1]. We > had a lot of excellent candidates and had to make some hard choices. We > applied for extra slots, but unfortunately didn't win

Re: [Numpy-discussion] Syntax Improvement for Array Transpose

I've finally gone through the old discussion and finally got the counter-argument in one of the Dag Sverre's replies http://numpy-discussion.10968.n7.nabble.com/add-H-attribute-tp34474p34668.html TL; DR I disagree with [...adding the .H attribute...] being forward looking, as > it explicitly

Re: [Numpy-discussion] Syntax Improvement for Array Transpose

Maybe a bit of a grouping would help, because I am also losing track here. Let's see if I could manage to get something sensible because, just like Marten mentioned, I am confusing myself even when I am thinking about this 1- Transpose operation on 1D arrays: This is a well-known confusion

Re: [Numpy-discussion] Syntax Improvement for Array Transpose

is a > second transpose operation they need to look out for. So it would hurt a > lot of people without helping anyone. > > On Tue, Jun 25, 2019, 07:03 Ilhan Polat wrote: > >> I have to disagree, I hardly ever saw such bugs and moreover is >> not compatible if you do

Re: [Numpy-discussion] Syntax Improvement for Array Transpose

1D > arrays if .H did not. I commonly write things like u.conj().T@v even if I > know both u and v are 1D just so it looks more like an inner product. > > > > -Cameron > > > > On Mon, Jun 24, 2019 at 6:43 PM Ilhan Polat > wrote: > >> > >> I t

Re: [Numpy-discussion] Syntax Improvement for Array Transpose

Please don't introduce more errors for 1D arrays. They are already very counter-intuitive for transposition and for other details not relevant to this issue. Emitting errors for such a basic operation is very bad for user experience. This already is the case with wildly changing slicing syntax. It

Re: [Numpy-discussion] how much does binary size matter?

here is a baseline https://en.wikipedia.org/wiki/List_of_countries_by_Internet_connection_speeds . Probably a good idea to throttle values at 60% of the bandwidth and you get a crude average delay it would cause per 1MB worldwide. On Fri, Apr 26, 2019 at 11:49 AM Éric Depagne wrote: > Le

Re: [Numpy-discussion] Possible Deprecation of np.ediff1d

In the meantime I'll make a PR to get rid of it from SciPy. We can also signal other libraries to do so. Anything frees up the already-very-crowded namespace of NumPy dot is worth it in my opinion. On Tue, Aug 28, 2018 at 7:40 PM Stephan Hoyer wrote: > > > On Tue, Aug 28, 2018 at 9:03 AM Ralf

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

I agree with Ralf. That thread is more towards a US based separation. Actually we briefly touched upon these on the SciPy side but indeed there was no real discussion. Political beliefs (especially communism in US for a practical example) can offend some people and that's OK because being

Re: [Numpy-discussion] Polynomial evaluation inconsistencies

I think restricting polynomials to time series is not a generic way and quite specific. Apart from the series and certain filter design actual usage of polynomials are always presented with decreasing order (control and signal processing included because they use powers of s and inverse powers of

Re: [Numpy-discussion] matmul as a ufunc

Apart from the math-validity discussion, in my experience errors are used a bit too generously in the not-allowed ops. No ops are fine once you learn more about them such as transpose on 1D arrays (good or bad is another discussion). But raising errors bloat the computational code too much. "Is it

Re: [Numpy-discussion] Splitting MaskedArray into a separate package

As far as I understand from the discussion above, I think the opposite would be a better strategy for the sanity of our scarce but brave maintainers. I would argue that if there is a maintenance burden, then the ballasts seem to be the linalg and random indeed. Similar pain points exist in SciPy

Re: [Numpy-discussion] [SciPy-Dev] RFC: comments to BLAS committee from numpy/scipy devs

I couldn't find an item to place this but I think ilaenv and also calling the function twice (one with lwork=-1 and reading the optimal block size and the call the function again properly with lwork=) in LAPACK needs to be gotten rid of. That's a major annoyance during the wrapping of LAPACK

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

I was about to send the same thing. I think this matter became a vim/emacs issue and Py2 supporters won't take any arguments anymore. But if Instagram can do it, it means that legacy code argument is a matter of will but not a technicality.

Re: [Numpy-discussion] Sustainability

I have two points that I know, from first hand, people (including myself) wonder: 1. Clear distinction between NumPy/SciPy development and respective roadmaps. In addition to Johann's summary; I am an occasional contributor to SciPy (mostly linalg) and again occasionally I wonder whether certain

Re: [Numpy-discussion] ANN: SciPy 1.0 beta release

Well also thank you Ralf, for going through all those issues one by one from all kinds of topics. Must be really painstakingly tedious. On Sun, Sep 17, 2017 at 12:48 PM, Ralf Gommers wrote: > Hi all, > > I'm excited to be able to announce the availability of the first

Re: [Numpy-discussion] Dropping support for Accelerate

ccelerate for years, because of > how it breaks multiprocessing – that doesn't seem to be on your list > yet. > > On Sat, Jul 22, 2017 at 3:50 AM, Ilhan Polat <ilhanpo...@gmail.com> wrote: > > A few months ago, I had the innocent intention to wrap LDLt decomposition > > rout

[Numpy-discussion] Dropping support for Accelerate

A few months ago, I had the innocent intention to wrap LDLt decomposition routines of LAPACK into SciPy but then I am made aware that the minimum required version of LAPACK/BLAS was due to Accelerate framework. Since then I've been following the core SciPy team and others' discussion on this

Re: [Numpy-discussion] Controlling NumPy __mul__ method or forcing it to use __rmul__ of the "other"

fferent choices people have used: >> >> https://github.com/search?l=Python=__array_priority__ >> =Code=%E2%9C%93 >> >> On Mon, Jun 19, 2017 at 11:07 AM, Ilhan Polat <ilhanpo...@gmail.com> >> wrote: >> >>> Thank you. I didn't know that it

Re: [Numpy-discussion] Controlling NumPy __mul__ method or forcing it to use __rmul__ of the "other"

answered your question on StackOverflow: > https://stackoverflow.com/questions/40694380/forcing- > multiplication-to-use-rmul-instead-of-numpy-array-mul-or- > byp/44634634#44634634 > > In brief, you need to set __array_priority__ or __array_ufunc__ on your > object. > > On Mo

[Numpy-discussion] Controlling NumPy __mul__ method or forcing it to use __rmul__ of the "other"

I will assume some simple linear systems knowledge but the question can be generalized to any operator that implements __mul__ and __rmul__ methods. Motivation: I am trying to implement a gain matrix, say 3x3 identity matrix, for time being with a single input single output (SISO) system that I