Re: [Numpy-discussion] Numpy Documentation: How-to content
This sounds fantastic. Great! In what context would the students be creating the notebooks -- as part of one of your existing ME courses, as a for-credit project, as a supervised but non-credit project? These would be supervised projects either for work-study or credit. What were your thoughts on submission workflow? You review initially, then the student directly submits a PR? My plan was to mentor the initial idea and creation and help the students submit PRs. For most, this will be their first interaction with Github. Suppose several students want to create a notebook on the same topic. Would you steer them to another topic, allow them to work independently and both submit (and we merge best of both), urge them to collaborate? My hope would be students that are passionate about the same topic could collaborate. I've had students collaborate on topic ideas for small projects that worked very well. Were you planning to keep the mechanical engineering context for these problems, or present abstractly? I would plan to keep the How-to as an engineering application. It shouldn't detract from the underlying numerical work.___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] [Feature Request] Add alias of np.concatenate as np.concat
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
Re: [Numpy-discussion] (no subject)
hey! On Sun, May 31, 2020 at 7:52 PM Charles R Harris wrote: > Downstream developers should use Cython >= 0.29.16 for Python 3.8 support and > OpenBLAS >= 3.7 to avoid wrong results on the Skylake architecture. The NumPy > Wheels for this release can be downloaded from PyPI, source archives and > release notes are available from Github. just so that i can re-configure (if necessary) our automation in Debian, is this going to be the future setting for releasing numpy? wheels via PyPI and source via github? I stumbled upon this since there's no source release available on PyPI for 1.19.0rc2 Thanks, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
