To be honest, I am not too convinced right now. Another thing, you mentioned .astype(np.inexact), that is not well defined in a sense. It just ends up being .astype(np.float64) (also copy=True) is already the default. My main squirm is that np.farray is a very uncommon function, and I am not sure that adding these things improves the situation much with respect to the original question.

@seberg. The use-case I have in my actual project (which does use asfarray pretty extensively) is asfarray(x, dtype=None, copy=True). I need to be able to pass through any inexact point type from any array-like, and only convert the integers. Right now, asfarray only operates on a fixed type, and so requires you to determine the type manually.

I don't see this being an uncommon function being a problem. If the the limited interface is the issue, then this will make more common. If not, then this change does not affect that many people.

I am just not sure I like the whole dance of first creating an array. The main issue though is that I have never used this function, and the whole way it works (replacing the input dtype if it is not floating, but ignoring the arrays dtype) is strange. So I guess my main concern is that I do not like this funciton/approach to begin with...

@seberg. I don't like that particular dance either. If there was a reasonable way to assess the dtype without creating an array, I'd be happy to use that instead.

I've used this function quite a bit in certain situations where I need to do operations on floating point numbers. astype is nice, but it only works if you already have an array. And creating a copy is also a very nice feature to have.

in certain situations where I need to do operations on floating point numbers.

Can you give an example of when you care about the numbers being floating point?

The specific example I have is a small scikit I'm working on. I do a whole bunch of in-place floating-point math on the inputs (division, fractional exponents, etc.), so it's very convenient to be able to create a copy as I convert the input to float.

I would personally (at this time at least) probably opt for a pattern such as:

float_dtype = np.result_type(arr.dtype, 0.)
arr = arr.astype(float_dtype, copy=False)

Not sure if that is what you are looking for.

@seberg That doesn't allow passing in arbitrary array-like objects that may not have a dtype or astype. That's the main allure of this function to begin with, and why I want it to have a complete set of options.

I am sorry, but I think I will close this for now (for now, happy to reopen). I am still not convinced and it has been a while. This just does not feel like a neat API where extending it actually helps the general user. I am sure it can be useful to have a helper for it for libraries, but I doubt this is it to be honest. I am more likely to accept deprecating it with a message: This is how you might spell a better function...