Milan Klöwer

Is that because for BFloat16 the actual `rand` is done in Float32? ```julia julia> f32s = extrema(sort!(rand(Float32, 10_000_000))) (0.0f0, 0.99999994f0) julia> extrema(sort!(BFloat16.(rand(Float32, 10_000_000)))) (BFloat16(0.0), BFloat16(1.0)) julia> extrema(sort!(BFloat16.(rand(Float32, 10_000_000)))) (BFloat16(1.1920929f-7), BFloat16(1.0))...

We should define it as ```julia using BFloat16s, Random import Random: AbstractRNG, Sampler function Random.rand(rng::AbstractRNG, ::Sampler{BFloat16}) u = reinterpret(UInt16, one(BFloat16)) u |= rand(rng, UInt16) >> 9 # u in [1,2)...

Also check out [Float8s.jl](https://github.com/milankl/Float8s.jl), I haven't checked what the Nvidia standard for Float8 is, but that seems to be a package that should cover it ;)

Btw, I'm also happy to move Float8s.jl over here and give people access in case there is interest to manage it closer to BFloat16s.jl due to their similar scope

I see that unifying them in a common package is appealing, but I believe people to still expect `using BFloat16s, Float8s` to just work, or do you want to change...

Hmmm maybe I shouldn't have commented out the stacktrace ```julia [2] _fftfloat(::Type{Posit16}) at /home/username/.julia/packages/AbstractFFTs/PUqOK/src/definitions.jl:22 ``` so it's about these two lines (20 & 22), which explain the above. ```julia _fftfloat(::Type{Float16})...

Is this problem related? ```julia julia> AssociatedLegendrePolynomials.λlm(600,500,1/sqrt(2)) 3.485220526612233e-21 julia> AssociatedLegendrePolynomials.λlm(600,500,Float32(1/sqrt(2))) 6.120498f9 ``` I'v realised this as for higher resolution in SpeedyWeather.jl simulations suddenly blow up when using Float32, which I...

Okay, I don't think the issue I posted is exactly the same as it's not about underflow but overflow. I can recreate @marius311 issue and similarly now created  for...

Also note that @marius311 picture from above with Float64 should look like ```julia julia> matshow(log10.(abs.(Float64.(λlm(0:3000, 0:3000, Float128(cos(θ))))))) ``` (via rounding after calculation in Float128). Meaning it just becomes 0 where...

Thanks Justin for the explanations. For the time being, we'll use Float64 for precalculating the polynomials. If you ever find ways to reduce under, overflows with Float32 please let me...