@ndrean thanks for the report. I've edited the issue to explain the problem and a suggested solution. Pull requests are welcome!

"hack" is easy: Nx.as_type(:f32)

I suggest Nx.Type.to_floating instead, as that will avoid upcasts from f16/f8

Humm, I tested Axon.conv, it works with the conversion.
This is ok because the coefficients are learnt (the iteration will fill them up).
Now if you give the coefficients and do a convolution, you need to reverse the second input, which you can't do with floats.

Nx.reverse calls:

no function clause matching in Nx.Type.sort/2    
    
    The following arguments were given to Nx.Type.sort/2:
    
        # 1
        #Nx.Tensor<
          s32[3]
          
          Nx.Defn.Expr
          a = stack [1, 1, 1], 0   s32[3]
        >
    
        # 2
        {:f, 32}

What I mean is that you should probably need to provide the "real" implementation in NxSignal.conv instead if Nx.conv is "reserved" for Axon. I don't if I am clear.

This is probably not a relevant conversation for this issue. I'm also not sure why the type would affect the ability to reverse an input.

Ah, right. This is most likely just a bug in EMLX.Backend.reverse.

Also, there is ongoing work on NxSignal.Convolutions :)

Ok. It was because I wrongly used Nx.Type.to_floating. This is ok.

defmodule NxPoly do
  import Nx.Defn
  
  defn tprod(t1, t2) do
    t1 = Nx.stack(t1) |> Nx.as_type(:f32)
    t1 = Nx.reshape(t1, {1,1, Nx.size(t1)})
    t2 = Nx.stack(t2) |> Nx.as_type(:f32)
    t2 = Nx.reshape(t2, {1,1, Nx.size(t2)})
    
    Nx.conv(t1, Nx.reverse(t2), padding: [{2,2}])
  end
end