There's been multiple occasions when we run into constructor issues when using float32 types in GLM objects because despite the response being a numpy array with float32, the dtype argument to GLM functions (which defaults to float64) casts it. The reason for having this argument is for cases like binomial or poisson where we need to explicitly specify it.
Proposed change: whenever possible, we should infer dtype from the given y. Even in binomial or poisson, the user may provide it with float types rather than integer types. Default to dtype is None. If we cannot infer, we raise an error telling the user to explicitly provide dtype to be np.float32 or np.float64.
There's been multiple occasions when we run into constructor issues when using float32 types in GLM objects because despite the response being a numpy array with float32, the
dtypeargument to GLM functions (which defaults to float64) casts it. The reason for having this argument is for cases like binomial or poisson where we need to explicitly specify it.Proposed change: whenever possible, we should infer dtype from the given
y. Even in binomial or poisson, the user may provide it with float types rather than integer types. Default todtypeisNone. If we cannot infer, we raise an error telling the user to explicitly providedtypeto benp.float32ornp.float64.