[Numpy-discussion] Re: Seeking feedback: design doc for `namedarray`, a lightweight array data structure with named dimensions
Some historical discussions on a namedarray on the scikit-learn side: https://github.com/scikit-learn/enhancement_proposals/pull/25 Might be useful to y'all. On Fri, Oct 20, 2023 at 8:49 AM Dom Grigonis wrote: > I would make use of it if it was also supporting pure-numpy indices too. > Pure-numpy n-dim array with indices is what I was after for a while now. > The reason is exactly that - to shed heavy dependencies as pandas and have > performance of pure numpy. > > Regards, > DG > > > On 20 Oct 2023, at 00:51, Anderson Banihirwe > wrote: > > > > :wave:t5: folks, [there has been growing interest in a lightweight array > structure](https://github.com/pydata/xarray/issues/3981) that's in the > same vein as [xarray's Variable]( > https://docs.xarray.dev/en/stable/generated/xarray.Variable.html). we've > put together a design doc for `namedarray`, and we could use your > feedback/input. > > > > ## what is `namedarray`? > > > > in essence, `namedarray` aims to be a lighter version of xarray's > Variable—shedding some of the heavier dependencies (e.g. Pandas) but still > retaining the goodness of named dimensions. > > > > ## what makes it special? > > > > * **Array Protocol Compatibility**: we are planning to make it > compatible with existing array protocols and the new [Python array API > standard](https://data-apis.org/array-api/latest/). > > * **Duck-Array Objects**: designed to wrap around multiple duck-array > objects, like NumPy, Dask, Sparse, Pint, CuPy, and PyTorch. > > > > ## why are we doing this? > > > > the goal is to bridge the gap between power and simplicity, providing a > lightweight alternative for scientific computing tasks that don't require > the full firepower of Xarray (`DataArray` and `Dataset`). > > > > ## share your thoughts > > > > We've put together a design doc that goes into the nitty-gritty of > `namedarray`. your insights could be invaluable in making this initiative a > success. please give it a read and share your thoughts [here]( > https://github.com/pydata/xarray/discussions/8080) > > > > * **Design Doc**: [namedarray Design Document]( > https://github.com/pydata/xarray/blob/main/design_notes/named_array_design_doc.md > ) > > > > cross posting from [Scientifc Python Discourse]( > https://discuss.scientific-python.org/t/seeking-feedback-design-doc-for-namedarray-a-lightweight-array-data-structure-with-named-dimensions/841 > ) > > ___ > > NumPy-Discussion mailing list -- numpy-discussion@python.org > > To unsubscribe send an email to numpy-discussion-le...@python.org > > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ > > Member address: dom.grigo...@gmail.com > > ___ > NumPy-Discussion mailing list -- numpy-discussion@python.org > To unsubscribe send an email to numpy-discussion-le...@python.org > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ > Member address: adrin.jal...@gmail.com > ___ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com
[Numpy-discussion] Re: Policy on AI-generated code
FWIW, as Loïc already mentioned, we had the same discussions on the scikit-learn side. We noticed every now and then a few issues / PRs would come which were clearly AI generated, and in almost all those cases, the account posting them didn't look like a human / didn't have a history on GH. At the end, practically speaking, we know people use AI generated code (a bunch of us use copilot ourselves). So the issue wasn't that we didn't want any AI generated code, people use AI and there's no way around it. However, we wanted to be able to tell people that completely AI generated code / issues are not acceptable, and came up with this text: Please refrain from submitting issues or pull requests generated by > fully-automated tools. Maintainers reserve the right, at their sole > discretion, > to close such submissions and to block any account responsible for them. > > Ideally, contributions should follow from a human-to-human discussion in > the > form of an issue. Another point not included here, but we like, is to say that "if you use AI, you should only submit code which you really understand". Cheers, Adrin On Thu, Jul 4, 2024 at 9:40 PM Ralf Gommers wrote: > > > On Thu, Jul 4, 2024 at 8:42 PM Matthew Brett > wrote: > >> Hi, >> >> On Thu, Jul 4, 2024 at 6:44 PM Ralf Gommers >> wrote: >> > >> > >> > >> > On Thu, Jul 4, 2024 at 5:08 PM Matthew Brett >> wrote: >> >> >> >> Hi, >> >> >> >> On Thu, Jul 4, 2024 at 3:41 PM Ralf Gommers >> wrote: >> >> > >> >> > >> >> > >> >> > On Thu, Jul 4, 2024 at 1:34 PM Matthew Brett < >> matthew.br...@gmail.com> wrote: >> >> >> >> >> >> Hi, >> >> >> >> >> >> On Thu, Jul 4, 2024 at 12:20 PM Ralf Gommers < >> ralf.gomm...@gmail.com> wrote: >> >> >> > >> >> >> > >> >> >> > >> >> >> > On Thu, Jul 4, 2024 at 12:55 PM Matthew Brett < >> matthew.br...@gmail.com> wrote: >> >> >> >> >> >> >> >> Sorry - reposting from my subscribed address: >> >> >> >> >> >> >> >> Hi, >> >> >> >> >> >> >> >> Sorry to top-post! But - I wanted to bring the discussion back >> to >> >> >> >> licensing. I have great sympathy for the ecological and >> code-quality >> >> >> >> concerns, but licensing is a separate question, and, it seems to >> me, >> >> >> >> an urgent question. >> >> >> >> >> >> >> >> Imagine I asked some AI to give me code to replicate a >> particular algorithm A. >> >> >> >> >> >> >> >> It is perfectly possible that the AI will largely or completely >> >> >> >> reproduce some existing GPL code for A, from its training data. >> There >> >> >> >> is no way that I could know that the AI has done that without >> some >> >> >> >> substantial research. Surely, this is a license violation of >> the GPL >> >> >> >> code? Let's say we accept that code. Others pick up the code >> and >> >> >> >> modify it for other algorithms. The code-base gets infected >> with GPL >> >> >> >> code, in a way that will make it very difficult to disentangle. >> >> >> > >> >> >> > >> >> >> > This is a question that's topical for all of open source, and >> usages of CoPilot & co. We're not going to come to any insightful answer >> here that is specific to NumPy. There's a ton of discussion in a lot of >> places; someone needs to research/summarize that to move this forward. >> Debating it from scratch here is unlikely to yield new arguments imho. >> >> >> >> >> >> Right - I wasn't expecting a detailed discussion on the merits - >> only >> >> >> some thoughts on policy for now. >> >> >> >> >> >> > I agree with Rohit's: "it is probably hopeless to enforce a ban >> on AI generated content". There are good ways to use AI code assistant >> tools and bad ones; we in general cannot know whether AI tools were used at >> all by a contributor (just like we can't know whether something was copied >> from Stack Overflow
Re: [Numpy-discussion] [Feature Request] Add alias of np.concatenate as np.concat
This somehow also reminds me of the `__array_module__` (NEP37) protocol. I'm not sure if TF would ever implement it, but it would be really nice if the NEP37 proposal would move forward and libraries would implement it. On Mon, Jun 1, 2020 at 8:22 PM Iordanis Fostiropoulos < danny.fostiropou...@gmail.com> wrote: > In regard to Feature Request: https://github.com/numpy/numpy/issues/16469 > > It was suggested to sent to the mailing list. I think I can make a strong > point as to why the support for this naming convention would make sense. > Such as it would follow other frameworks that often work alongside numpy > such as tensorflow. For backward compatibility, it can simply be an alias > to np.concatenate > > I often convert portions of code from tf to np, it is as simple as > changing the base module from tf to np. e.g. np.expand_dims -> > tf.expand_dims. This is done either in debugging (e.g. converting tf to np > without eager execution to debug portion of the code), or during > prototyping, e.g. develop in numpy and convert in tf. > > I find myself more than at one occasion to getting syntax errors because > of this particular function np.concatenate. It is unnecessarily long. I > imagine there are more people that also run into the same problems. Pandas > uses concat (torch on the other extreme uses simply cat, which I don't > think is as descriptive). > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] NEP Procedure Discussion
Somewhat relevant, this is the discussion around the same topic we've been having in scikit-learn: https://github.com/scikit-learn/enhancement_proposals/pull/30 On Fri, Aug 14, 2020 at 2:36 PM Ilhan Polat wrote: > 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, >> >> During the discussion about NEP-35, there have been lots of >> discussions around the NEP process itself. In the interest of allowing >> people who are mostly interested in this discussion and to avoid >> drifting so much off-topic in that thread, I'm starting this new >> thread to discuss the NEP procedure. >> >> A few questions that have been raised so far: >> >> - Is the NEP Template [1] a guideline to be strictly followed or a >> suggestion for authors? >> - Who should decide when a NEP is sufficiently clear? >> - Should a NEP PR be merged at all until it's sufficiently clear or >> should it only be merged even in Draft state only after it's >> sufficiently clear? >> - What parts of the NEP are necessary to be clear for everyone? Just >> Abstract? Motivation and Scope? Everything, including the real >> technical details of implementation? >> - Would it be possible to have proof-readers -- preferably people who >> are not at all involved in the NEP's topic? >> >> Please feel free to comment on that and add any major points I might >> have missed. >> >> Best, >> Peter >> >> [1] https://github.com/numpy/numpy/blob/master/doc/neps/nep-template.rst >> ___ >> NumPy-Discussion mailing list >> NumPy-Discussion@python.org >> https://mail.python.org/mailman/listinfo/numpy-discussion >> > ___ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Re: Code formatters
This discussion and the linked gist may be of some help: https://github.com/scikit-learn/scikit-learn/issues/11336 On Mon, Nov 22, 2021 at 12:02 PM Andrew Nelson wrote: > Is there a way to figure out which files are not touched by any open PR? > That way numpy might be able to do a lot more than an incremental code > alignment. > ___ > NumPy-Discussion mailing list -- numpy-discussion@python.org > To unsubscribe send an email to numpy-discussion-le...@python.org > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ > Member address: adrin.jal...@gmail.com > ___ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com
[Numpy-discussion] Maintainers Track at EuroScipy 2022
Hi Folks, We're organizing the maintainers' track at EuroScipy 2022, happening in Basel at the end of August this year: https://www.euroscipy.org/2022/. This track is a venue for maintainers to meet one another and meet maintainers of other projects, interact, and exchange ideas. With the works going into the scientific python community and SPECs( https://scientific-python.org/), we think it would be nice for folks who are going to be around at EuroScipy to meet and discuss issues. You can see the previous track at the last EuroScipy here: https://www.euroscipy.org/2019/maintainers.html We would really appreciate it if you could come, be there, and contribute in sessions if you wish. We're also looking for ideas/proposals for sessions. We have two concrete questions: - Are there any maintainers from your project who are attending the conference? - Do you have a proposal for a session for the track? Best, On Behalf of The EuroScipy Committee, Adrin ___ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com
