[BUG] math/numeric functions weird behavior with float16 types about mojo HOT 6 CLOSED

Internally, @abduld mentioned "we do not support fp16 one it". He likely meant to post that comment in the spot on Linear so the comment would get synced externally/be visible here.

from mojo.

@abduld Why closing this?

from mojo.

This bug is only triggered if two (or more) floating point types other than float64 are used.

The nextafter function is implemented roughly as follows:

fn nextafter(arg0: SIMD[type], arg1: SIMD[type]) -> SIMD[type]:
    fn _float32_dispatch[...](...) -> ...: ...
    fn _float64_dispatch[...](...) -> ...: ...

    constrained[type.is_floating_point(), "input type must be floating point"]()
    @parameter
    if type is DType.float64:
        return _simd_apply[_float64_dispatch](arg0, arg1)
    else:
        return _simd_apply[_float32_dispatch](arg0, arg1)

Types other than float32 fall into the else branch. This design pattern is prevalent in the standard library (e.g., math.mojo), and we should fix it everywhere.

We could either cast other float types to f32 or f64 as a fallback or forbid them altogether using the constrained function. I'm not sure which approach is preferred. CC: @abduld

from mojo.

Using test_nextafterDType.float16 alone seems to work fine. So neither falling back to float32 nor adding constrains sounds like the right solution to me.

from mojo.

I don't mean to ban them literally, rather we need to make clear in the implementation which one of the dispatches actually exists. If it does work, I suspect it works accidentally. For instance, atan2[float16] produces the wrong result.

Again, it's hardly nextafter's problem.

from mojo.

Good to know that. Any reasons for only two dispatches exist for now?

from mojo.