You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the internal valid_ifthens function, there are 2 points where there exist hard-coded feature names in the code, and these parts of the code fail without them. Specifically:
here, there is a reference to an age column of X, which is also assumed to be of pd.Interval dtype. As such, if this column does not exist or is not of Interval dtype, this part of the code throws an error.
The last command fails with AttributeError: 'numpy.float64' object has no attribute 'left'
At this point, the recIsValid function is used. This, in turn, here also references hard-coded feature names. Here there exist checks of whether they exist or not, so the code does not fail if they do not exist. But there are cases where if a feature exists, it is assumed either to be of a certain type or to possess certain semantics.
I do not currently have a reproducible example for this one, because whether it will appear or not depends on the exact test data. I believe, however, that it is clear this is also a bug, and if we want to enforce some constraints, such as this part of the code is trying to do, it should be done in some other, more robust way.
The text was updated successfully, but these errors were encountered:
In the internal
valid_ifthens
function, there are 2 points where there exist hard-coded feature names in the code, and these parts of the code fail without them. Specifically:age
column ofX
, which is also assumed to be ofpd.Interval
dtype. As such, if this column does not exist or is not of Interval dtype, this part of the code throws an error.Example to reproduce:
The last command fails with
AttributeError: 'numpy.float64' object has no attribute 'left'
recIsValid
function is used. This, in turn, here also references hard-coded feature names. Here there exist checks of whether they exist or not, so the code does not fail if they do not exist. But there are cases where if a feature exists, it is assumed either to be of a certain type or to possess certain semantics.I do not currently have a reproducible example for this one, because whether it will appear or not depends on the exact test data. I believe, however, that it is clear this is also a bug, and if we want to enforce some constraints, such as this part of the code is trying to do, it should be done in some other, more robust way.
The text was updated successfully, but these errors were encountered: