This line is necessary when X.dtype is int32 or int64.
Should we keep the number of bits short, i.e. perfom casting from int32 to float32, or int32 to float 64 ?

ping @glemaitre

you should already have called check_X_y and/or as_float_array above. Then you can just use X.dtype to specify the dtype of arrays you allocate

Indeed, and the check_X_y of line 430 probably needs to be changed to "dtype=[np.float32, np.float64]"

pep8 violations. please check

This line is necessary to get coefficients of type float32 output when X is of type int32. Removing this line gives coefficients of type float64.

This is strange becasue the next check_X_y will convert to float anyway. It seems unecessary, isn't it?

Oh I see why. So X will be converted to float64 and you expect it to be converted to float 32 because X is of type int32. I would say that there is no real reason for that. int32 can default to float64. I am fine with that.

@massich what is the mechanism in the other estimators that you modified?

There was no mechanism set. I've the vague idea that we talked about it long ago, but I can't recall that we agreed on anything. To me it makes sense that if someone willing creates the data in 32, wants to keep it in 32 bits. But if such individual is there she/he will scream at us, or would had done it already. So I've no objection on defaulting to float64.

An int32 is a "very big" int. Hence, it make sense to convert it to a float64. People who want to save memory with ints use int16. Indeed, an int has a larger span than a float for the same memory cost.

This is strange becasue the next check_X_y will convert to float anyway. It seems unecessary, isn't it?

Convention for int32 is casting to float64.

I find this one more readable:

@pytest.mark.parametrize("data_type, expected_type", [
  (np.float32, np.float32),
  (np.float64, np.float64),
  (np.int32, np.float64),
  (np.int64, np.float64)
])

do not use astype assert_allclose should be able to handle it.

        assert_allclose(clf_32.coef_, clf_64.coef_, rtol=rtol)

Going from int32 to float64 is not what was done by isotonic regression isofused branch this morning. We should be consistent here.

I am +1 for int32 -> float64. It was the semantic for check_array.
@ogrisel was also for this conversion. I would think that we should correct the isotonic regression then.

+1. Merging. This is a net improvement. We'll nitpick later :D