-
-
Notifications
You must be signed in to change notification settings - Fork 10.8k
ENH: Symbolic solver for dimension specifications. #19805
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
LGTM give 6 new alerts for this PR. Are they accurate?
|
The LGTM alerts were partially accurate but were certainly useful to pinpoint one real bug. Fixed the bug and warnings in the latest commit. |
+1 for LGTM |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks fantastic! I will recheck the issues to see if this fixes more than the one referenced here; but this is a huge step forward.
scipy builds and all its tests pass with this PR. |
@pearu Could you add a release note for this in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very tiny typos otherwise this looks great, thanks @pearu !
|
||
|
||
class TestDimSpec(util.F2PyTest): | ||
"""This test site tests various expressions that are used as dimension |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"""This test site tests various expressions that are used as dimension | |
"""This test suite tests various expressions that are used as dimension |
`lower` and `upper` are arbitrary expressions of input parameters. | ||
The evaluation is performed in C, so f2py has to translate Fortran | ||
expressions to valid C expressions (an alternative approach is | ||
that a developer specifies the corresponing C expressions in a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that a developer specifies the corresponing C expressions in a | |
that a developer specifies the corresponding C expressions in a |
- Spelling fixes - Release note fragment for numpygh-19805.
MAINT: Minor cleanups after merging gh-19805
- Spelling fixes - Release note fragment for numpygh-19805.
Hmm. Ever since commit 88f988a introduced here, in NixOS, the scikit-learn 1.0.2 kernel PCA unit tests cause crashes for us which appear to be related to a corrupted heap. This is with joblib 1.1.0, scipy 1.8.0, threadpoolctl 3.0.0, gfortran 9.3.0, gcc 10.3. Still investigating. Edit: also tried with numpy 1.22.2 including fix #20724 |
@pearu thoughts? |
@risicle Can you provide a minimal reproducer of the reported crashes? The reproducer should include the f2py wrapping step as the messages there may give a hint of what goes wrong. |
I'll try - it's all inside scipy's Currently trying to convince our lapack to build with debugging symbols.. |
A lot of fighting with debug symbols and a crash course in fortran later, it looks like what is happening is I'll try to get scipy's |
https://gist.github.com/risicle/d7450ec92bd89bff138ead438c28ce1c @@ -49783,33 +49783,33 @@
capi_iwork_tmp = array_from_pyobj(NPY_INT,iwork_Dims,iwork_Rank,capi_iwork_intent,Py_None);
if (capi_iwork_tmp == NULL) {
PyObject *exc, *val, *tb;
PyErr_Fetch(&exc, &val, &tb);
PyErr_SetString(exc ? exc : _flapack_error,"failed in converting hidden `iwork' of _flapack.dsyevr to C/Fortran array" );
npy_PyErr_ChainExceptionsCause(exc, val, tb);
} else {
iwork = (int *)(PyArray_DATA(capi_iwork_tmp));
/* Processing variable z */
- z_Dims[0]=(compute_v?MAX(0,n):0),z_Dims[1]=(compute_v?(*range=='I'?iu-il+1:MAX(1,n)):0);
+ z_Dims[0]=(compute_v ? MAX(0, n) : 0),z_Dims[1]=(compute_v ? (*range == 'I' ? 1 - il + iu : MAX(1, n)) : 0);
capi_z_intent |= F2PY_INTENT_OUT|F2PY_INTENT_HIDE;
capi_z_tmp = array_from_pyobj(NPY_DOUBLE,z_Dims,z_Rank,capi_z_intent,Py_None);
if (capi_z_tmp == NULL) {
PyObject *exc, *val, *tb;
PyErr_Fetch(&exc, &val, &tb);
PyErr_SetString(exc ? exc : _flapack_error,"failed in converting hidden `z' of _flapack.dsyevr to C/Fortran array" );
npy_PyErr_ChainExceptionsCause(exc, val, tb);
} else {
z = (double *)(PyArray_DATA(capi_z_tmp));
/* Processing variable isuppz */
- isuppz_Dims[0]=(compute_v?(2*(*range=='A'||(*range=='I' && iu-il+1==n)?n:0)):0);
+ isuppz_Dims[0]=(compute_v ? 2 * (*range == 'A'||(*range == 1 + 'I' && iu - il == n) ? n : 0) : 0);
capi_isuppz_intent |= F2PY_INTENT_OUT|F2PY_INTENT_HIDE;
capi_isuppz_tmp = array_from_pyobj(NPY_INT,isuppz_Dims,isuppz_Rank,capi_isuppz_intent,Py_None);
if (capi_isuppz_tmp == NULL) {
PyObject *exc, *val, *tb;
PyErr_Fetch(&exc, &val, &tb);
PyErr_SetString(exc ? exc : _flapack_error,"failed in converting hidden `isuppz' of _flapack.dsyevr to C/Fortran array" );
npy_PyErr_ChainExceptionsCause(exc, val, tb);
} else {
isuppz = (int *)(PyArray_DATA(capi_isuppz_tmp)); |
Resolves #8062
Possibly conflicting with #19388 that replaces
shape
withf2py_shape
. Whichever PR lands last, should update the usage ofshape
in crackfortran.py.