What's preventing float(exponent) instead?

So what I think is going on: When creating the pow_0 operator for Tensor self, Scalar exponent, symbolic_script replaces Scalar by float. The float(exponent) cast gets eliminated because the JIT "knows" it is a float. What then happens is that unpacking Scalar IValues that the JIT thinks must be float but that are, in fact, int fails.

In a way it comes down to

    // 2. to make sure the input of any graph node does not contain scalar type
    //    in its argument, all scalar arg should already be passed with float
    //    value since scalar/int aren't differentiable either way.

not being the complete picture because (as here) the scalar might not be the thing we want to differentiate for, but a parameter (in the mathematical sense as opposed to the variable) of the function we want to differentiate.

So I'm changing the patch to do the following:
If Scalar -> float conversion happened, I change back the input type of the graph to Scalar, and insert a conversion (prim::Float) as the first thing.
It'll be troublesome for use when we get operations that actually rely on the difference between float and int in Scalar ops, but currently we don't as far as I know.

I think this is a clean-up of the Scalar->float conversion as it ensures that the graph inputs actually match the schema. @ailzhang does that seem reasonable?

So it turns out that re-Scalarizing breaks something (the double backward?). 😓

cc: @wanchaol added the scalar to float conversion.

Also, the scalar to float conversion only happens on the second pass, when allow_conversions is true, if there is an op defined for Scalar than that will be matched and there won't be a conversion.

@t-vi Actually as @eellison pointed out offline, we actually can get rid of the scalar -> float conversion entirely.
For example this works for me.

        def pow_0(self,
                  exponent: number):

Note that we don't expose number in torchscript but we CAN compile it! :D With this we can easily get rid of current symbolic_variable.h and c10::ReplaceAll(schema_str, "Scalar", "float");.
Huge thanks to @eellison who pointed this out!
Let us know if this fixes your problem :D

Ha. That works (I think)! And I've been poking around much too long. Awesome.
Thanks so much @ailzhang and @eellison !

So my understanding is that with this, one would only have definitions that match the operator schemas. Could we actually check that? For now I left a fallback in but converted those replacements that were hit by a test_jit.py run.

Yea this if should be dropped before merging.

So I removed it after double checking by means of calling sig(schema_string) and seeing whether it throws here: