ENH, MAINT: Fix behavior of int and bool in np.spacing

[kianasun]

When the dtype of the input is int or bool, the output of np.spacing function was puzzling.

[eric-wieser]

the output of np.spacing function was puzzling.

For ease of reviewing, can you show what the output was?

[kianasun]

the output of np.spacing function was puzzling.

For ease of reviewing, can you show what the output was?

Sure. Below is what the output was

>>> np.spacing(np.ones(3, dtype=np.int))
array([2.22044605e-16, 2.22044605e-16, 2.22044605e-16])
>>> np.spacing(np.ones(3, dtype=np.bool))
array([0.000977, 0.000977, 0.000977], dtype=float16)
>>> np.spacing(np.ones(3, dtype=np.float64))
array([2.22044605e-16, 2.22044605e-16, 2.22044605e-16])

[eric-wieser]

Sounds like our option is to either accept this patch, or update the docs to say that spacing is for floating point types.

How does the behavior of nextafter compare?

[kianasun]

>>> eps = np.finfo(np.float).eps
>>> np.nextafter(np.int(1), np.int(3)) == eps + 1
True
>>> np.nextafter(np.float(1), np.float(3)) == eps + 1
True
>>> np.nextafter(False, True)
6e-08

For nextafter, it seems that at least int is same asfloat. Yes, we can either change the behaviors, or update the docs and raise some errors for int and bool.

[eric-wieser]

You're seeing the same behavior for both functions.

• f(some_int64) → f(some_int64.astype(np.float64))
• f(some_bool) → f(some_bool.astype(np.float16))

This is perhaps not the best design, but it is consistent with how casting works in numpy (cc @seberg), eg for functions like np.sin.

It's worth noting that C++ takes a different approach here, producing an error if a cast is ambiguous. If we could redo casting without breaking everyone downstream, following the overload design of C++ might be the way to go.

---

An aside - never use np.float or np.int - they're just confusing names for the builtin types, as summarized in #6103.

[charris]

Needs release note.

[seberg]

@eric-wieser yeah, I agree. The default TypeResolver uses the first loop which can cast all inputs safely. That kind of works, but really is more trouble than worth it it seems to me.

For when we redo this, I think most of these fallbacks should be deprecated, it is OK if the ufunc has to resolve specifically integer inputs -> use float64 (I think it actually might be a point that a true hierarchy could be convenient). We could go with an error, for np.sin, etc. the nicest thing would likely be to go for float64? That might be easiest with a "hard" behaviour change maybe.

Seems a bit orthogonal to this issue. For this specific thing, we have to decide if we want to rather go with a Deprecation rather than defining a spacing. Does anyone know a real use-case for defining spacing on int (where the intention is not to cast them to floats)? Without a use case, I am in favor of going the deprecation route here I think.

[kianasun]

@eric-wieser @seberg I am not sure if there is a real use-case for this specific function. In that case, will it be better to simply change the document? If we change the document, do we need to raise errors/warnings for int, bool? If we need to raise errors, we are still changing the behaviors (might need to give int a higher priority for TypeResolver to deal with, before safely casting them to float). And at least for bool, casting them to float seems incorrect I think.

[seberg]

@kianasun, my comments about TypeResolving were more philosophical for a future change API change. We can deprecate using this functions on integers (it involves creating a new TypeResolver right now).

[charris]

close/reopen to retrigger shippable.