Repository navigation
Deprecated squeeze with emulation path is missing its own section #551
Description
Activity
Now the informative
squeezeemulation note is plugged into thelstmsection which is wrong. We should keep this note in its ownsqueezesection.Is that correct? I see gru and lstm both include a very abbreviated
function squeezedefinition in their "generically emulated" section, but it's in reshape itself that gives a more comprehensive example for how reshape can be used to emulate squeeze.Regarding structure, perhaps a non-normative section in the appendix giving emulations/decompositions of popular ops that don't make the cut?
(Actually removing ops from the TR/final version of the spec seems unlikely given how hard deprecations on the web are... we've been working on deprecating WebSQL for over a decade.)
Regarding structure, perhaps a non-normative section in the appendix giving emulations/decompositions of popular ops that don't make the cut?
+1
A refined proposal: move all those "The behavior of this operation can be generically emulated" boxes to an appendix section. All of them, not just those that didn't make it to the API proper. Currently there's 20 of these boxes. (And check they're valid, preferably with tests.)
It is OK to have alternative emulations for a single op, each with their own tradeoffs.
I feel it might improve readability and make it easier for editors to evolve the spec if we section these out.
Thoughts?
FWIW, I prefer having the emulations/decompositions for ops supported in the API right in the definitions. It helps me mentally partition the ops into "low level" and "high level" (which I've also heard referred to as "core" and "composite", or "RISC" and "CISC"), and goes slightly towards addressing #462
But that could also be done by organizing the ops differently (different order or different sections?) or just calling out the ops that can be decomposed by some standard text in their introduction.
Re calling out, a good idea. I envision a standard note banner for those decomposable linking to the appendix where the emulation code sits:
”The behavior of this operation can be generically emulated, see link-to-appendix.”
I think our intent has been to try include emulation code for all decomposable.
We have sectioned out element-wise, pooling, reduction ops due to their similarity while the rest are in the ”global namespace”. More structure could be added with those ”this is decomposable” banners. Would that help you @inexorabletash?
I’d let the editors choose an approach that feels the most productive way forward for them. Maybe in small steps first, check the current emulation code is in its logical place before making huge changes.
More structure could be added with those ”this is decomposable” banners.
SGTM, but defer to the editors.
- added a commit that references this issue
on Jun 13, 2024
Since the previous CR we removed
squeeze(in PR #532) that can be generically emulated and expressed in terms of other low-level operations. Now the informativesqueezeemulation note is plugged into thelstmsection which is wrong. We should keep this note in its ownsqueezesection.Considering deprecations may be expected in the future too, we should agree on how to best structure the spec for this:
Thoughts? Is the first option better?