fix(ONNX): avoids resizing unsupported dimensions

[bjacobgordon]

No description provided.

[zjgarvey]

I think the main structural question is about the need for adding the BaseTensorType method. If it were useful elsewhere (I have some doubts, since we would need to know too much about the two tensor shapes prior to using it- namely that they are present, and they have the same rank), I would consider keeping it; however, the code is simplified here by not using it, and I suspect that the same would be true in other circumstances where it might be used.

[zjgarvey]

Sorry for the misdirect earlier, we need to perform the runtime asserts on the scales or sizes values instead of sizes, since we will not have access to the correct output sizes ahead of time.

[zjgarvey]

This is a personal preference, but I would certainly prefer:

Suggested change

	int64_t const batchDimension = 0;
	int64_t const channelDimension = 1;
	int64_t nonScalableDimensions[] = {
	batchDimension,
	channelDimension,
	};
	auto errorMessageForScaling = [](int64_t givenDimension) {
	switch (givenDimension) {
	case batchDimension:
	return "Unexpected intent to scale the batch dimension";
	case channelDimension:
	return "Unexpected intent to scale the channel dimension";
	default:
	return "Scalable dimension treated as non-scalable";
	}
	};
	auto unknownSize = Torch::kUnknownSize;
	// Compile-time check for dimensions of static size
	for (auto eachDimension : nonScalableDimensions) {
	// Compile-time check for dimensions of static size
	for (int64_t i = 0; i<2; i++) {

This is for two reasons:

1. Although the torch op might have these specific dimension specifications, the ONNX op does not. We should say something a bit more generic like "unsupported: non-trivial scaling in the first two dimensions.".
2. We might want to implement support for this path instead of writing a match failure in the future. With all of the variables and structures introduced here, I think this would cause more work for the future developer.

[bjacobgordon]

And personal preferences are worth sharing! They're heuristics for our engineering experiences, and they're worth putting out there because:

• they could help someone solve a problem that they've encountered in their own experience
• it's an opportunity to evaluate a preference, put them to words, recalibrate them, or maybe even drop them altogether when presented with new information.

1. Gotcha, so we want the error message to not reveal the rational. In that case, I'll have the message report the dimension index instead. Also gives us a chance to differentiate the messages between compile-time and run-time check.
2. I agree that it's work! In the case of adding support, work is unavoidable:
   • the work of deleting 3 variable declarations that contain cognitive load
     OR
   • the work of gathering the required cognitive load by
     • talking to other engineers
     • researching within the codebase
     • reading external docs
     • etc.
       OR
   • some other unforeseen work!

Predicted questions by future devs (especially if they're also cross-discipline):

We do 2 loops, so what's significant about the first two dimensions?

• pings engineer again

Okay, so they shouldn't be scaled, but why? What do they represent?

• pings engineer yet again

Okay, they're the batch and channels dims, but how's that different from the other dims?

• pings engineer one more time

Oh, their elements have nothing to do spatial dimensions, got it!

With the dims explicitly declared and the implementation based on them, another engineer might be able to avoid having to recollect the CL we had already collected once before.

[zjgarvey]

please use loc. This is actually the original op's location (and not the binder), and loc is a fairly canonical variable name for the location of the op being rewritten.

[IanWood1]

I think the renaming of loc -> opLocation should probably be split into a different PR so it can be reviewed separately, it adds ~600 lines of changes that aren't directly related to the functional changes. It would help to keep this PR focused and easier to review.

[bjacobgordon]

Okay, @zjgarvey, I think we're in business! Got green on the CI a few hours ago. Just wrapped up self-review.

I'm guessing now we'll:

• discuss how the diffs might need to change
• finalize those changes
• discuss which chunks of commits need to be in the PR stack
  Something like that?

I kept the commits atomic and ordered such that it's easier to propagate changes to the head of the branch in case an earlier commit needs to be inserted/tweaked/excised.

Let me know what you think!

[zjgarvey]

Okay, @zjgarvey, I think we're in business! Got green on the CI a few hours ago. Just wrapped up self-review.

I'm guessing now we'll:

* discuss how the diffs might need to change

* finalize those changes

* discuss which chunks of commits need to be in the PR stack
  Something like that?

I kept the commits atomic and ordered such that it's easier to propagate changes to the head of the branch in case an earlier commit needs to be inserted/tweaked/excised.

Let me know what you think!

Nice!

At least for now, please exclude any commits which involve style changes not directly related to the fix content. E.g. widespread enforcement of naming preferences like the loc -> opLocation should be factored out into a separate PR as @IanWood1 suggested.