[data types] Enforce type checking

[fdmalone]

1. Adds a check in _process_soquests that the register dtypes are "consistent".
2. Adds a add_register_from_dtype method.
3. Adds an QAnyInt and QAnyUInt bundle of types.

The type checking raised a bug in the THC bloq with register mismatch which is a good sign. I fixed that too (although, still not entirely satisfied with our grouping for Select and Prepare #549)

The check in process soquets checks both the type and the register size. The register size was not being checked before so this sort of deprecates the assert_connections_compatible check (I deleted that unit test).

The current type consistency is a bit sketchy:

1. type_a == type_b (fine)
2. type_a or type_b QAny (fine)
3. Single bit registers are ok (fine)
4. Integer types of same bitsize are ok (this is probably ok, but maybe we should force people to cast)
5. Unsigned integers types are ok with wholly fractional or wholly integer QFxp. (this is a bit sketchy)

Maybe 5 and 6 should go away and we should add casts (#725)? This runs the risk of making the code more verbose.

[fdmalone]

The test failure seems unrelated.

[mpharrigan]

Maybe 5 and 6 should go away

can you clarify this? your numbered list only goes up to 5

---

I think I'm most worried about

Single bit registers are ok (fine)

mainly based around the discussion about whether you can have one-bit number types (like a 1 bit unsigned integer vs a 1 bit twos-compliment signed integer). I forget: do we allow these? Even if we don't: there were some convincing arguments made in their favor. In this world: a one-bit unsigned integer is basically the same as QBit() but a one-bit twos-compliment signed integer represents the values 0 and -1 rather than 0, 1 so it's not the same

[mpharrigan]

The check in process soquets checks both the type and the register size. The register size was not being checked before so this sort of deprecates the assert_connections_compatible check

I'm confused about this. My technical confusion is that you deleted the unit test but you didn't delete the testing function. Did you mean to delete both?

Philosophically: the qualtran.testing.assert_xxx generally are redundant with the bloq builder checks. The motivation for this is two-fold: 1) check CompositeBloq that wasn't constructed via the bloqbuilder. 2) there's a distinct possibility that the BloqBuilder checks will have to be paired back due to performance or annoyance/debugging reasons. Right now the door is still open to a world where validation is separate from constructing the object.

[fdmalone]

Maybe 5 and 6 should go away

can you clarify this? your numbered list only goes up to 5

Sorry, 4 and 5 (reinterpreting essentially) which is related to your 1-bit concern below. Should we allow the free reinterpretation of an unisgned int to a signed int under the assumption the developer know's what they're doing? In the classical case perhaps we don't care about the value in the register and just want to reuse the "variable" / qubits for something else so assume things will be appropriately cleared before use.

I think I'm most worried about

Single bit registers are ok (fine)

mainly based around the discussion about whether you can have one-bit number types (like a 1 bit unsigned integer vs a 1 bit twos-compliment signed integer). I forget: do we allow these? Even if we don't: there were some convincing arguments made in their favor. In this world: a one-bit unsigned integer is basically the same as QBit() but a one-bit twos-compliment signed integer represents the values 0 and -1 rather than 0, 1 so it's not the same

We do allow the one bit integers as you described. I think this comparison is related more generally to the point above about integers. My sense is we shouldn't be too strict to avoid adding a bunch of Cast boilerplate, but I could be convinced.

[fdmalone]

The check in process soquets checks both the type and the register size. The register size was not being checked before so this sort of deprecates the assert_connections_compatible check

I'm confused about this. My technical confusion is that you deleted the unit test but you didn't delete the testing function. Did you mean to delete both?

Philosophically: the qualtran.testing.assert_xxx generally are redundant with the bloq builder checks. The motivation for this is two-fold: 1) check CompositeBloq that wasn't constructed via the bloqbuilder. 2) there's a distinct possibility that the BloqBuilder checks will have to be paired back due to performance or annoyance/debugging reasons. Right now the door is still open to a world where validation is separate from constructing the object.

I deleted the test because the error raised was from the type check in process soquets. I wasn't sure what the right way to bypass that check was and was unsure if the function was useful elsewhere? Given your comment it seems like the correct way to test this method would be to not use the BloqBuilder or maybe the test is now redundant?

[mpharrigan]

I deleted the test because the error raised was from the type check in process soquets

Ah, I understand now. The other unit tests for the testing functions (head spin) use the helper function _manually_make_test_cbloq_cxns because otherwise the BloqBuilder would raise an exception before you could even use the assert_xxx testing functions. This is what you ran into. test_assert_connections_compatible is unique because the BloqBuilder was doing less (none?) validation on whether connections were compatible vs qlt_testing.assert_connections_compatible. The full fix is

1. update qlt_testing.assert_connections_compatible to call your new datatype validation function
2. re-write the unit test starting from _manually_make_test_cbloq_connections and muck them up a little to trigger the validation failure

[fdmalone]

@mpharrigan is this good to go?