ENH: float.from_number implementation
#29077
Conversation
jorenham
left a comment
There was a problem hiding this comment.
Since there's also a complex.from_number in Python π, maybe it would make sense to also include complexfloating, e.g. by adding np.inexact.from_number?
seberg
left a comment
There was a problem hiding this comment.
Thanks, sorry we never pushed this. I think it really just needs some minor tweaks. (I wonder a bit if the tests can be more concise, but probably not!)
| static PyObject * | ||
| @name@_from_number(PyObject *cls, PyObject *arg) | ||
| { | ||
| npy_double val = PyFloat_AsDouble(arg); |
There was a problem hiding this comment.
Sorry that I never looked at this. I think this is actually very nice to add and we should totally do that.
In a sense, this is not quite correct, because we should support np.longdouble.from_number(np.longdouble(2).sqrt()) to round-trip. That said, we don't actually care too much about long-double and it is the only one with this problem.
So maybe we can just special case that one even if we might not care much?
(Or if we dislike things a lot, we just omit it for longdouble.)
| def test_from_number_exceptions(self, code): | ||
| cls = np.dtype(code).type | ||
| with pytest.raises(TypeError): | ||
| cls.from_number("numpy") |
There was a problem hiding this comment.
I think the test should use a valid float "2.3" and maybe we should also test NumPy strings/string arrays.
Can we also check for only __index__ to match Python?
|
My notifications got missed! I will address the comments, thanks a lot for the review!! |
Changes
Add
float.from_numberfor floating typesTesting
Related
part of #13375
Todo
Float:
Complex