Bug#1070201: Small reproducing example

[Gard Spreemann]

The following code based on the failing test reproduces the issue on an
i386 porterbox:

***
from sklearn.tree import (
    DecisionTreeClassifier,
    export_graphviz,
)
import pdb

X = [[-2, -1], [-1, -1], [-1, -2], [1, 1], [1, 2], [2, 1]]
y2 = [[-1, 1], [-1, 1], [-1, 1], [1, 2], [1, 2], [1, 3]]
w = [1, 1, 1, 0.5, 0.5, 0.5]

def main():
    clf = DecisionTreeClassifier(
        max_depth=2, min_samples_split=2, criterion="gini", random_state=2
    )
    clf = clf.fit(X, y2, sample_weight=w)
    pdb.set_trace()

    contents1 = export_graphviz(clf, filled=True, impurity=False, out_file=None)

if __name__ == "__main__":
    main()
***

On an amd64 system, we see the following normal behavior when inspecting
`clf.tree_` and its negation at the given breakpoint:

> (Pdb) clf.tree_.impurity
> array([0.4691358 , 0.        , 0.22222222, 0.        , 0.        ])
> (Pdb) -clf.tree_.impurity
> array([-0.4691358 , -0.        , -0.22222222, -0.        , -0.        ])

However, on an i386 porterbox, we get this funny behavior with the
negation:

> (Pdb) clf.tree_.impurity
> array([0.4691358 , 0.        , 0.22222222, 0.        , 0.        ])
> (Pdb) -clf.tree_.impurity
> array([-4.69135802e-001, -1.59149684e-314, -1.50000000e+000,      -2.12199579e-314,              nan])

This smells of some alignment issue on an FFI boundary, perhaps. It
certainly explains the failing test (as the tested code does `np.min`
and `np.max` of `-clf.tree_.impurity`).


 Best,
 Gard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 857 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/debian-science-maintainers/attachments/20240607/f0dd4440/attachment.sig>