Repository navigation
Conversation
…er for functionality on parsing pauli words and str formatting. cleaned up current set of files including more descriptive names, removing unnecessary allocations, and correcting stale comments
…width prior to multiplciation
|
| { | ||
| #[inline(always)] | ||
| fn x_bit(&self, i: usize) -> bool { | ||
| debug_assert!(i < self.nqubits, "index {i} out of bounds"); |
There was a problem hiding this comment.
One inconsistency I notice here is that we have assert! in some places and debug_assert! in others. Not sure which one we want.
There was a problem hiding this comment.
IMO, we should probably keep it at as a debug_assert. This way, there's no runtime impact at release mode. If the assertion were to fail, the program would have failed anyways. The rust compiler is pretty great at giving error messages, so I think we can get away with just having debug_asserts
| debug_assert!(i < self.nqubits, "index {i} out of bounds"); | ||
| if self.xbits[i] != v { | ||
| self.xbits.set(i, v); | ||
| self.refresh_hash(); |
There was a problem hiding this comment.
There won't be a use-case with the upcoming refactor, but I still want to point this out: if we ever want to do operations on PauliWord in a hot-path, but don't need it to be indexable, hashing can be a significant overhead. I noticed this when implementing the current version of the generalized tableau, which didn't need its rows to be hashable. So I hacked around it by implementing a new word type which just has a no-op for hashing.
I don't see a place we need it right now, but this is something to be aware of. Do we want to have a convenience function to turn this off? I understand that the current implementation should guarantee that PauliWord can be used as a key in a hash map. That would break that guarantee.
| { | ||
| #[inline] | ||
| fn x(&mut self, q: usize) { | ||
| assert!(q < self.nqubits, "qubit {q} out of bounds"); |
There was a problem hiding this comment.
What's the performance impact of having assert! here? Without it, this function gets eliminated entirely, so it has to be at least a little bit.
There was a problem hiding this comment.
assertion expressions are kept in both release and debug builds for a crate. Whereas debug assertions are no-opt in release mode, so there's no runtime impact in release mode. With assertion however, because this is kept in, latency does worsen. I'll have to profile this.
…est module uses assert variants
This branch has not been deployed
2 participants
This patch introduces the ppvm-pauli-word-2 crate from #204. On top of the crate shown in that PR, this patch also includes the following: