[BUG] Unnecessary complex API

[bpserlet]

Bug description

Take math.inf. It's defined as:

inf[type: DType]() -> SIMD[type, 1]

why not just:

inf[type: DType]() -> type

?

Steps to reproduce

• Include relevant code snippet or link to code that did not work as expected.
• If applicable, add screenshots to help explain the problem.
• If using the Playground, name the pre-existing notebook that failed and the steps that led to failure.
• Include anything else that might help us debug the issue.

System information

Latest mojo

[bgreni]

DType isn't a numeric type, but rather a struct representing a particular size of integer, float or otherwise. So when you write inf[Dtype.int32]() it returns a Scalar holding the maximum value an int32 can represent. Simply returning a DType doesn't make any sense since it doesn't hold a numeric value.

[StandinKP]

I agree with @bgreni

[bpserlet]

OK, but then what I'd like the signature to be, somehow, is: inftype: DType.any -> type In other words, force the type parameterization to be as descriptive as needed, but then have the inf value return that type.

[arthurevans]

To expand on what @bgreni said.

This is a frequent source of confusion, but a DType is not a type, it's a value that describes a data type. You can think of values like DType.float32 as being used sort of like enums. The DType struct also defines some utility methods for working with different data types.

SIMD is the fundamental numeric type in Mojo, which handles both integral and floating-point numbers. With the exception of Int (which is primarily used for programmatic offsets, loop counters, and so on), all of Mojo's numeric scalar types are just type aliases for different kinds of SIMD values. So SIMD[DType.float32, 1] == Scalar[DType.float32] == Float32, and:

var f: Float32 = inf[DType.float32]()

You could argue that it would be simpler if this was spelled:

var f: Float32 = inf[Float32]()

Although the API doc for that method would look something like:

inf[type: SIMD[dtype: DType, 1]]() -> SIMD[dtype, 1]

This is because our API doc generation currently expands all aliases. For example, the source code for inf() uses the alias Scalar[type], but the API doc shows SIMD[type, 1] instead. An API that uses Float64, say, would always expand to SIMD[DType.float64, 1]. (We're hoping to fix this in the API docs.)

Hope that helps.

[bpserlet]

The terminology is very confusing: "DType is not a type" => maybe rename it? "SIMD is the fundamental numeric type in Mojo" => this is very bizarre. I think SIMD stands for Single Instruction Multiple Data. Maybe "Numeric" instead?

Ultimately, I would like the prototype for inf to be something like: inf[type: AnyFloat]() -> type where you can replace AnyFloat with whatever makes sense for mojo...

[lattner]

Yes, I agree bertrand that is a direction we want to go. Right now Mojo doesn't have a proper set of numeric traits, and we don't have "conditional conformances" that would allow putting extensions on SIMD "but only when T conforms to a trait". We should definitely build into this over time though!