8000 [RFC] who should drive the dtype of the computations X or y ? · Issue #8976 · scikit-learn/scikit-learn · GitHub
[go: up one dir, main page]

Skip to content

[RFC] who should drive the dtype of the computations X or y ? #8976

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

Closed
massich opened this issue Jun 2, 2017 · 6 comments
Closed

[RFC] who should drive the dtype of the computations X or y ? #8976

massich opened this issue Jun 2, 2017 · 6 comments

Comments

@massich
Copy link
Contributor
massich commented Jun 2, 2017

Description

This question arises after the PR #8835 addressing IS #8769.
Roughly if X.dtype is np.float32 and y.dtype is np.float64, (or the other way arround) should we:

a) convert both to np.float32
b) convert both to np.float64
c) convert them to X.dtype
d) convert them to y.dtype

@GaelVaroquaux
Copy link
Member
GaelVaroquaux commented Jun 2, 2017 via email

@jnothman
Copy link
Member
jnothman commented Jun 3, 2017 via email

@raghavrv
Copy link
Member
raghavrv commented Jun 8, 2017

For tree based regressors the X and y dtypes are independent. So we should consider it on a case-by-case basis I think.

@vene
Copy link
Member
vene commented Jun 9, 2017

still, for trees, every node stores a comparison with the dtype of X, but just the leaves store outputs, right?

I don't think there can be any problems with using X.dtype consistently.

@massich
Copy link
Contributor Author
massich commented Jun 10, 2017

we could add check_consistacy_type(X,y) in utils/validation and @GaelVaroquaux suggested to call it insde check_X_y(consistent_type=True, ...)

@massich
Copy link
Contributor Author
massich commented Sep 17, 2019

@glemaitre. Thx

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants
0