Transforms as operators

[cliffburdick]

This PR marks a major breaking change in MatX syntax. Previously we had a clear distinction of operators vs transforms such that they could not be combined. To do an FFT convolution, the user would write:

  // Perform the FFT in-place on both signal and filter
  fft(sig_freq, sig_time);
  fft(filt_freq, filt_time);

  // Perform the pointwise multiply. Overwrite signal buffer with result
  (sig_freq = sig_freq * filt_freq).run();

  // IFFT in-place
  ifft(sig_freq, sig_freq);

This code is taken directly from the FFT convolution sample. While the code is readable, anyone who has done an FFT convolution in another language like Python would usually write it as a single line. This was not possible in MatX due to transforms having the requirement of being on their own line. The other thing to notice is that transforms have a different syntax than regular operator expressions; in one case the output is a parameter to a function, while in the other case the output is done using the assignment operator. Having the output as a function parameter has a couple of benefits, such as deducing what to do based on the output, but it has far more downsides.

This PR introduces "transforms as operators". The general idea is that if the user wants to, they can use transforms inside of any operator expression. The FFT convolution above changes to:

(sig_freq = ifft(fft(sig_time) * fft(filt_time))).run(stream);

Someone familiar with signal processing will immediately recognize the convolution. Besides readability, this syntax has many benefits:

• Fewer temporary variables need to be instantiated for interim steps
• Better operator fusion is possible since more about the entire expression is known at compile-time
• The syntax matches higher-level languages (Python & MATLAB)
• The executor is decoupled from the transform
• The API documentation for each function is cleaner
• Improved NVTX nsys timelines

Under the hood, the feature works by detecting whether a transform is being used as part of a larger expression, and, if so, a temporary async-allocation is made scoped to the lifetime of the operator. In our testing we've found the overhead from these allocations are small (~1%), depending on the size of the problem. Users not wanting the extra overhead can continue to use the old multi-line method, but converted to the new assignment syntax:

  (sig_freq = fft(sig_time)).run();
  (filt_freq = fft(filt_time)).run();

  // Perform the pointwise multiply. Overwrite signal buffer with result
  (sig_freq = sig_freq * filt_freq).run();

  // IFFT in-place
  (sig_freq = ifft(sig_freq)).run();

In this case MatX detects that these are "simple" transforms, and reverts to the fast-path without any asynchronous allocations, but maintaining the newer syntax.

Transforms that return multiple types are required to be standalone, as they are in Python:

(mtie(Evv, Wov) = eig(Bv)).run();

mtie is used to "tie" multiple values together similar to std::tie(). mtie is needed to overload the assignment operator.

Feedback is always welcome!

Closes #450

[cliffburdick]

/blossom-ci

[cliffburdick]

/blossom-ci

[cliffburdick]

/blossom-ci

[cliffburdick]

/blossom-ci