Constants as matrix operations. Shape inference bug?

[derekchiang]

This works:

  let hey = range_of_shape ~batch_dims:[ 1 ] ~input_dims:[ 2 ] ~output_dims:[ 3 ] () in
  let%op hoo = (1 + 1) * hey in

This errors:

  let hey = range_of_shape ~batch_dims:[ 1 ] ~input_dims:[ 2 ] ~output_dims:[ 3 ] () in
  let%op hoo = 2 * hey in

The error is:

Fatal error: exception (lib/shape.ml.Shape_error
  "Too many axes in a subtensor; maybe using * instead of *.?"
  ((Row_mismatch
     ((dims ()) (bcast Broadcastable) (id ((sh_id 1) (kind Input))))
     ((dims ((Dim ((d 3) (label ()) (proj_id ()))))) (bcast Broadcastable)
       (id ((sh_id 0) (kind Output)))))))

Is that expected?

[lukstafi]

Yes, it's expected although maybe not desirable. 2 gets parsed as Tensor.number which makes a 1D tensor. 1 + 1 gets inferred to be a matrix with input dimension 3 so that it can take hey as an argument. The solution is to use *. i.e. pointwise multiplication instead of tensor (matrix) multiplication.

[lukstafi]

If you intended to broadcast 2 in the input dimension, then actually writing it as 1 + 1 is a workaround. At some point I'll get around to writing a formal paper about the shape inference algorithm and that will be a good opportunity to dig into what's ideal to happen in these two cases.

[lukstafi]

There is a confusing aspect to this issue: even though 2 is 1D, why doesn't it get broadcasted? OTOH, it's also desirable that it doesn't get broadcasted maybe as it's more likely that someone's intention was to write *.

Edit: keeping it in discussions rather than issues, but unresolved until I clarify for myself the inference process again and if any other design decisions are needed.