Nice. I didn’t think about that interpretation. It was just the rounding to an abstract type seems strange. Which is the function that returns other type of number of the same “size”, given one type? Meaning
f(::Float32) = Int32
f(::Float64) = Int64
f(::Int32) = Float32
etc.
In this case this “mapping” seems implemented for trunc, floor, ceil, round as @edit tells me. By the way, round(Integer, Float32(1.1)) gives Int64, not Int32 (same for Float16). I don’t really know if this is intended, but as I just asked for an integer type, it seems reasonable that julia gives me the machine integer type if it can fit x.
It’s a bit tricky because of inexact mapping from floats to integers. For example, Float32 can represent 2^31 perfectly, whereas Int32 cannot:
julia> Integer(Float32(2^31))
2147483648
julia> round(Int32,Float32(2^31))
ERROR: InexactError: trunc(Int32, 2.1474836e9)
It should also be possible to create similar errors when rounding certain Float64 to Int64. It’s unclear what the intention should be with such edge cases, and it’s probably unreasonable to play it safe by returning BigInt for round(Integer, Float32(x)). Some might say it’s not great to default to round(Int, Float32(x)) because the result can then differ between 32- and 64-bit CPUs. I guess Python will use bigger integers when needed, but with a big trade-off in performance.
Only the coder knows their use case, and they are probably better off being concrete, round(Int32, Float32(x)) when they know it will work.
A somewhat more basic suggestion:
here you are pre-allocating omega twice it seems?