Is your feature request related to a problem? Please describe.
The current approach to evaluating the break matrix is very slow. I want to use scipy.optimize.approx_fprime to get the Jacobian of the estimating equations going forward. This is much faster than my approach of getting the bread. This becomes important when the estimating equations have lots of parameters (minor differences for <20 params). Regardless, not making the switch makes the code much slower than need be.
However, this new feature in scipy needs v1.9.0+. This means future versions will drop support for Python version <3.8 and dependencies will be scipy>=1.9.0 and numpy>=1.18.5
Roadmap is to drop support for earlier version of scipy/numpy and python for v1.0 release.
Describe the solution you'd like
I would like to keep versions and have faster bread matrix calculations (but don't want to solve this issue on my own).
Describe alternatives you've considered
We can either be slow (and cover more versions in the future) or be fast for more 'modern' versions. Latter seems to be preferred.
Is your feature request related to a problem? Please describe. The current approach to evaluating the break matrix is very slow. I want to use
scipy.optimize.approx_fprimeto get the Jacobian of the estimating equations going forward. This is much faster than my approach of getting the bread. This becomes important when the estimating equations have lots of parameters (minor differences for <20 params). Regardless, not making the switch makes the code much slower than need be.However, this new feature in
scipyneeds v1.9.0+. This means future versions will drop support for Python version <3.8 and dependencies will be scipy>=1.9.0 and numpy>=1.18.5Roadmap is to drop support for earlier version of scipy/numpy and python for v1.0 release.
Describe the solution you'd like I would like to keep versions and have faster bread matrix calculations (but don't want to solve this issue on my own).
Describe alternatives you've considered We can either be slow (and cover more versions in the future) or be fast for more 'modern' versions. Latter seems to be preferred.
Additional context None