Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Let AggregateExpFragments take callables as well as exp fragments #425

Merged
merged 2 commits into from
Dec 21, 2024

Conversation

hartytp
Copy link
Contributor

@hartytp hartytp commented Dec 9, 2024

Closes #416

See #416 for discussion

I haven't added a kernel test for this but would be happy to do so if requested. Not sure the best way of doing this - perhaps making all of AddOneFragment's methods protable and then having AddOneAggregate take a build-time boolean flag to determine whether it runs on the kernel or host? Suggestions welcome!

@hartytp hartytp requested a review from dnadlinger December 9, 2024 09:51
self.setattr_result("sum", FloatChannel)

def push_sum():
self.sum.push(self.a.value.get() + 1 + self.b.value.get() + 1)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would love this to be self.sum.push(self.a.result.get_last() + self.b.result.get_last()) but:

  • currently the get_last is deliberately kernel only
  • we could add a sink-based interface that works by absorbing results...but then that's host-only so we can't run the test in a portable fashion
  • I also considered having AddOneFragment store a last_value attribute and store the result there as well, but that also seems like a pretty miserable hack. We're essentially saying to users "getting the last value pushed to a result is a legitimate thing to do, but we won't support it so you have to manually duplicate result channels and handle all the accompanying synchronization issues yourself"

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're essentially saying to users "getting the last value pushed to a result is a legitimate thing to do, but we won't support it so you have to manually duplicate result channels and handle all the accompanying synchronization issues yourself"

This is still preferrable to adding a half-baked implementation with unclear semantics to ndscan. "Magic" solutions that work only most of the time with unclear semantics (i.e. leaky abstractions) are much worse than just requiring users to write some straightforward Python code.

@dnadlinger dnadlinger enabled auto-merge December 21, 2024 22:14
@dnadlinger dnadlinger added this pull request to the merge queue Dec 21, 2024
Merged via the queue into master with commit 1001e38 Dec 21, 2024
5 checks passed
@dnadlinger dnadlinger deleted the tph/aggregate branch December 21, 2024 22:17
@dnadlinger
Copy link
Member

dnadlinger commented Dec 21, 2024

Thanks, merged with a bug in the docstring (override_param() return value order) fixed.

As for a test case, I'd say the dozen lines it takes to just add a separate @kernel copy of the fragment is probably worth it over the added complexity of some kind of parameterised solution.

Could you follow this up with such a straightforward smoke test, perhaps echoing the example from the docstring?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[RFC] AggregateExpFragment accepting callables as well
2 participants