[Numpy-discussion] Re: Moving busday functionality to numpy-financial

2023-06-28 Thread Ralf Gommers 
On Mon, Jun 26, 2023 at 6:57 AM Kai Striega  wrote:

> Hi Stefan,
>
> I'm interested in going that direction, or rather, getting the functions
> out of NumPy. I'm not sure if it's feasible to rip these functions out of
> NumPy itself – or how much work it would require. Last week I spent some
> time looking through the C source code (datetime_busday.{c,h} and
> datetime_busdaycal.{c,h}). I think it would require some effort to get it
> out as it depends on other functions which I'm not sure are part of the
> NumPy C-API.
>

I think these functions never really fit well into NumPy, and I'd like to
see them go. I don't think the large amount of work to turn numpy-financial
into a package containing C code and exposing the functionality there is
justified. I think Pandas is a much better place for this, and it already
has what looks like a superset of functionality:
https://pandas.pydata.org/docs/user_guide/timeseries.html?highlight=business#custom-business-days
.

>From a quick glance, Pandas only relies on `numpy.busdaycalendar` and
nothing else. So it'd be useful to investigate what it would take to move
that function to Pandas, and then deprecate everything related to business
days in NumPy.

Cheers,
Ralf



>
> Having someone familiar with the C-API as a guide would make me feel much
> better about working on it.
>
> Kind regards
>
> Kai
>
> On Mon, 26 Jun 2023 at 04:33, Stefan van der Walt 
> wrote:
>
>> Hi Kai,
>>
>> I agree with that the change has maintenance implications for
>> numpy-financial. It's not *hard* building binary wheels, per se, but it's
>> certainly a bigger job than maintaining and testing pure Python.
>>
>> As the maintainer of that library, you should decide whether that's
>> something you wish to take on. Myself and others here can help getting the
>> build set up, if you wish to go that direction.
>>
>> Best regards,
>> Stéfan
>>
>> On Fri, Jun 23, 2023, at 20:47, kaistri...@gmail.com wrote:
>> > TLDR: There has been some discussion regarding moving busday and
>> > related functions to numpy--financial. The sentiment for this has
>> > generally been positive, this thread is to assess the amount of work
>> > required to move these functions.
>> >
>> > Dear NumPy Maintainers,
>> >
>> > There has been some discussion about moving np.busday* to
>> > numpy-financial first on GitHub [1] and more recently on Slack. The
>> > sentiment has largely been positive, however one concern is that the
>> > amount of work required is not justified as few people currently use
>> > these functions and the move could be messy.  I have recently been
>> > contributing to NumPy and am currently the sole maintainer of
>> > numpy-financial, so it feels like I am the right person to do this. In
>> > my opinion, these functions conceptually fit the scope of
>> > numpy-financial.
>> >
>> > However, I have some hesitations about this work. Namely, I am
>> > struggling to estimate the scope of this work and I have only some
>> > experience with C, and the NumPy C API. I am having trouble estimating
>> > the amount of work this would require, but suspect that it will not be
>> > easy. The functions use some of the internal C-API (I think, how do I
>> > find out the differences between the internal/external API?) and
>> > depends on `np.datetime`. Further, the busday* functions are
>> > implemented in C. I only have some experience with C and the C aspects
>> > of NumPy—I am happy to learn, but this seems like a pretty steep
>> > learning curve. Finally, numpy-financial is currently a pure Python
>> > module and does not build C, again I will either need help with this or
>> > to learn how to do this.
>> >
>> > To finish, I have a few questions / requests for advice:
>> >
>> > * Is this change supported by the NumPy community?
>> > * Does anyone have advice on how to estimate the amount of work
>> > required?
>> > * If I start working on this, would anyone be willing to help me learn
>> > the C components?
>> >
>> > Kind regards
>> >
>> > Kai Striega (@Kai-Striega)
>> >
>> > [1]_ https://github.com/numpy/numpy/pull/23229#issuecomment-1467084886
>> > ___
>> > 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: stef...@berkeley.edu
>> ___
>> 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: kaistri...@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: ralf.gomm...@

[Numpy-discussion] Example gufuncs

2023-06-28 Thread Stefan van der Walt 
Hi all,

To teach gufuncs, we used to rely on the example implementations in 
`numpy.core.umath_tests`. That module has since been deprecated. Is there 
another, more suitable location for such examples?

I know it's been on SciPy's roadmap to convert some of `sp.linalg` to gufuncs, 
but that hasn't yet happened.

Stéfan
___
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] ANN: SciPy 1.11.1

2023-06-28 Thread Tyler Reddy 
Hi all,

On behalf of the SciPy development team, I'm pleased to announce the
release of SciPy 1.11.1, which
addresses a few bugs and in particular a licensing issue discovered shortly
after the release of 1.11.0,
which has now been yanked from PyPI.

Sources and binary wheels can be found at:
https://pypi.org/project/scipy/
and at: https://github.com/scipy/scipy/releases/tag/v1.11.1

One of a few ways to install this release with pip:

pip install scipy==1.11.1

==
SciPy 1.11.1 Release Notes
==

SciPy 1.11.1 is a bug-fix release with no new features
compared to 1.11.0. In particular, a licensing issue
discovered after the release of 1.11.0 has been addressed.

Authors
===

* Name (commits)
* h-vetinari (1)
* Robert Kern (1)
* Ilhan Polat (4)
* Tyler Reddy (8)

A total of 4 people contributed to this release.
People with a "+" by their names contributed a patch for the first time.
This list of names is automatically generated, and may not be fully
complete.

Issues closed for 1.11.1


* `#18739 `__: BUG: run method
of scipy.odr.ODR class fails when delta0 parameter...
* `#18751 `__: BUG: segfault
in \`scipy.linalg.lu\` on x86_64 windows and macos...
* `#18753 `__: BUG: factorial
return type inconsistent for 0-dim arrays
* `#18759 `__: determinant of
a 1x1 matrix returns an array, not a scalar
* `#18765 `__: Licensing
concern


Pull requests for 1.11.1


* `#18741 `__: BUG: Fix work
array construction for various weight shapes.
* `#18747 `__: REL, MAINT: prep
for 1.11.1
* `#18754 `__: BUG: fix handling
for \`factorial(..., exact=False)\` for 0-dim...
* `#18762 `__: FIX:linalg.lu:Guard
against permute_l out of bound behavior
* `#18763 `__:
MAINT:linalg.det:Return scalars for singleton inputs
* `#18778 `__: MAINT: fix unuran
licensing

Checksums
=

MD5
~~~

0d8ef8d4b3a484a1edb5b1027c635175  Changelog
9c279f2e8c4bfc18c08dee388f0e3937  README.txt
aca7e7047ecb15a0a8fbdc6704ba88ab
 scipy-1.11.1-cp310-cp310-macosx_10_9_x86_64.whl
9619336484eb1f39799a771456882cb0
 scipy-1.11.1-cp310-cp310-macosx_12_0_arm64.whl
e3943627bc04c4b2cd5bbc8c46928199
 scipy-1.11.1-cp310-cp310-manylinux_2_17_aarch64.manylinux2014_aarch64.whl
e48d61b72e9af960387b5249a7c3fd37
 scipy-1.11.1-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl
508a6c71a1d8c040646fdc91d7b2067f
 scipy-1.11.1-cp310-cp310-musllinux_1_1_x86_64.whl
8fb76fe2d1b7e45ec16f39a3d50748bb  scipy-1.11.1-cp310-cp310-win_amd64.whl
e82b0d4dd2f7f71f0a4ed6360c77954e
 scipy-1.11.1-cp311-cp311-macosx_10_9_x86_64.whl
044ce4958fe3640a9415f0203b1cc0be
 scipy-1.11.1-cp311-cp311-macosx_12_0_arm64.whl
a8d56936cd49c8e903c798133f5e065f
 scipy-1.11.1-cp311-cp311-manylinux_2_17_aarch64.manylinux2014_aarch64.whl
4cc3bd0a1be2457471d017eeed54c7aa
 scipy-1.11.1-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl
9cc5e6100de5f3d5cef21ccbba6693e1
 scipy-1.11.1-cp311-cp311-musllinux_1_1_x86_64.whl
b73a6e1a5cf1bc2ad5aa8a2dc99ad194  scipy-1.11.1-cp311-cp311-win_amd64.whl
db9b049b05206fb30b10ec247d959d94
 scipy-1.11.1-cp39-cp39-macosx_10_9_x86_64.whl
fcc109d0a300aaf982854b13208381fe
 scipy-1.11.1-cp39-cp39-macosx_12_0_arm64.whl
7eff7b1508f1ebbcc9f99aba48531677
 scipy-1.11.1-cp39-cp39-manylinux_2_17_aarch64.manylinux2014_aarch64.whl
9c90f85da178c4d9dc6d795f1ebd1151
 scipy-1.11.1-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl
1b652ed5b032737fcb56ef58f2158f6b
 scipy-1.11.1-cp39-cp39-musllinux_1_1_x86_64.whl
7e0c3c4d0b37a346b28cfd9f66e22b9f  scipy-1.11.1-cp39-cp39-win_amd64.whl

SHA256
~~

7835dab6f69b7551fb7b76534ecc8ee559bcdfc4d255a1a28dc7b1bcdda5050c  Changelog
c6cb0f39b1bb2eb6347f12d21027e11546cbfa7a9c2e1f8d3e823a2ecf918bb6  README.txt
aec8c62fbe52914f9cf28d846cf0401dd80ab80788bbab909434eb336ed07c04
 scipy-1.11.1-cp310-cp310-macosx_10_9_x86_64.whl
3b9963798df1d8a52db41a6fc0e6fa65b1c60e85d73da27ae8bb754de4792481
 scipy-1.11.1-cp310-cp310-macosx_12_0_arm64.whl
3e8eb42db36526b130dfbc417609498a6192381abc1975b91e3eb238e0b41c1a
 scipy-1.11.1-cp310-cp310-manylinux_2_17_aarch64.manylinux2014_aarch64.whl
366a6a937110d80dca4f63b3f5b00cc89d36f678b2d124a01067b154e692bab1
 scipy-1.11.1-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl
08d957ca82d3535b3b9ba6c8ff355d78fe975271874e2af267cb5add5bd78625
 scipy-1.11.1-cp310-cp310-musllinux_1_1_x86_64.whl
e866514bc2d660608447b6ba95c8900d591f2865c07cca0aa4f7ff3c4ca70f30
 scipy-1.11.1-cp310-cp310-win_amd64.whl
ba94eeef3c9caa4cea7b402a35bb02a5714ee1ee7