Conversation
Signed-off-by: Ben Howe <bhowe@nvidia.com>
| sum_op<spin_handler> x(std::size_t target); | ||
| sum_op<spin_handler> y(std::size_t target); | ||
| sum_op<spin_handler> z(std::size_t target); | ||
| product_op<spin_handler> i(std::size_t target); |
There was a problem hiding this comment.
These changes allow you to create spin_op_term's from i,x,y,z.
There was a problem hiding this comment.
This is what I had originally, but if you want backward compatibility, it's a sum here. The product version that should be used is spin_op::x
There was a problem hiding this comment.
A product_op is implicitly convertible to a sum_op, but not the other way around, so this change allows for the most flexibility in my opinion. (You are correct that what you had is the most backwards compatible by forcing it to return spin_op, but during the course of the 2704 PR, I had converted some things to spin_op_term (i.e. product_op), and my suggested change here allows seamless usage in both cases, I believe.)
Maybe I should've said: this allows for a good mix of backward compatibility and forward compatibility.
| * the terms of the Apache License 2.0 which accompanies this distribution. * | ||
| ******************************************************************************/ | ||
|
|
||
| #pragma once |
There was a problem hiding this comment.
Adding this file just means people don't have to change their #include's. After all, they are still dealing with the spin_op data type.
2 participants
I think this small set of changes makes a tremendous difference in the backwards compatibility of the PR.
From a build perspective, this cuts the number of lines of codes that CUDA-QX would need to change probably by >90%.
I am not convinced in the correctness of the default constructor, though, so please let me know if something looks glaringly wrong (especially regarding the default constructor).