`log1p` fails on `MtlArray{Float32}` about metal.jl HOT 10 CLOSED

any ideas for mitigating this?

No easy ones, sorry. You could try to find a different implementation of this operation that doesn't require wider temporaries.

from metal.jl.

Thanks, @maleadt. Do you think that this will fail on CUDA/AMDGPU? I am asking because it is used by some operations in Flux, so this might be a relevant issue for them too.

from metal.jl.

CUDA has more log intrinsics: https://github.com/JuliaGPU/CUDA.jl/blob/38fb7071d893fad8591361d0da96149f45f7653f/src/device/intrinsics/math.jl#L102-L123

from metal.jl.

Do you think a patch similar to this would be appropriate?

from metal.jl.

Yes, it would.

cc @oscardssmith (I mentioned this being a problem at JuliaCon)

from metal.jl.

how much accuracy are you willing to lose? I can probably cook you up a FLoat32 only one that performs pretty well at the cost of slightly lower accuracy (probably in the 2-4 ULP area).

from metal.jl.

If the only problem is the implementation of log_proc2, there is a single precision implementation in the original paper (p.385-386). But I think there is another Float64 cast in log_proc1 too

from metal.jl.

oh, I think it's possible that the double precision casts may not be necessary at all. The biggest difference between our algorithm and Tang's is that we add an extra multiply at the end to account for the different base logs and that multiply may have a bunch of error without the extended precision. Would be good to try the version that doesn't upcast though...

from metal.jl.

I made an attempt to re-write the functions without using double precision floats #236

I tried in a REPL and the functions seem to work, however using them in Metal with MtlArray does not.

from metal.jl.

#239

from metal.jl.