Adding IntegrationFunction class. This represents an under-constructi… #167
Conversation
…on merged function and includes bookkeeping to track which original-function nodes map to which integration-function nodes. Currently for an IntegrationFunction, inputs are tuples where each tuple corresponds to the inputs of one of the source functions.
…on merged function and includes bookkeeping to track which original-function nodes map to which integration-function nodes. Currently for an IntegrationFunction, inputs are tuples where each tuple corresponds to the inputs of one of the source functions.
| std::move(IntegrationFunction::MakeIntegrationFunctionWithParamTuples( | ||
| p.get(), {func_a, func_b}))); | ||
|
|
||
| auto GetTupleIndexWithNumBits = [&](long int num_bits) { |
There was a problem hiding this comment.
JFYI, our linter complains that long int is ideally written as int64 so changed on merge.
There was a problem hiding this comment.
Sounds good.
|
Can one of the folks with merge-button-pressing authority please press the merge button? |
copybara-service
bot
deleted the
jbaileyhandle_integration_function_class
branch
|
JFYI @jbaileyhandle re: process we generally can't use the merge button because we're using downstream source control as the "source of truth", so the Copybara bot tries to automerge it downstream (behind a manual step or two) and if there are any issues (like downstream linter or what have you) they get manually resolved by the "build czar" for the week (on a rotation). Once it's committed downstream it pushes back out and closes the PR as merged. |
|
@cdleary Interesting, thanks for letting me know. |
…on merged function and includes bookkeeping to track which original-function nodes map to which integration-function nodes. Currently for an IntegrationFunction, inputs are tuples where each tuple corresponds to the inputs of one of the source functions.