Nexus worker improvements, graphs and docs#207
Conversation
Change tests to use format_generic_type instead of format_ptype
mwpb
force-pushed
the
docs/nexus-worker
branch
from
7cfa175 to
b08cf56
Compare
| cx q[20],q[21]; | ||
| cx q[21],q[22]; | ||
| barrier q[0],q[1],q[2],q[3],q[4],q[5],q[6],q[7],q[8],q[9],q[10],q[11],q[12],q[13],q[14],q[15],q[16],q[17],q[18],q[19],q[20],q[21],q[22]; | ||
| measure q[0] -> meas[0]; |
There was a problem hiding this comment.
I think its possible to do measure q -> meas
There was a problem hiding this comment.
No doubt you have a better idea than me. I'm using this (from https://github.com/pnnl/QASMBench/tree/master/medium/ghz_state_n23).
| OPENQASM 2.0; | ||
| include "qelib1.inc"; | ||
| qreg q[23]; | ||
| creg c[23]; |
| return g | ||
|
|
||
|
|
||
| def nexus_submit_and_poll(polling_interval: float = 30.0): |
There was a problem hiding this comment.
Is there a specific reason this is not an additional input?
| return backend_results | ||
|
|
||
|
|
||
| ## DEPRECATED TASKS ## |
There was a problem hiding this comment.
This made me think: should we add a way to forward other function decorators from tasks? e.g. if we used @deprecated() here
There was a problem hiding this comment.
In short yes. I've created https://github.com/orgs/CQCL/projects/18/views/1?pane=issue&itemId=130214819. I remember trying@deprecated and running into a problem though I don't recall what it was.
| if _is_union(annotation): | ||
| for t in get_args(annotation): | ||
| try: | ||
| return coerce_from_annotation(ser, t) |
There was a problem hiding this comment.
I'm not sure if this is working correctly in combination with the basemodel. I constructed an example in this commit where the success of the test depends on whether you use the type hints test__(val: A | B) or test__(val B | A).
I must admit, though, that this is a very contrived example, so if you think this is not a concern, I'm happy to merge the version as is
There was a problem hiding this comment.
Good thinking, this just does 'left to right' resolution because that is easiest. In future we could try to implement a 'smart mode' similar to https://docs.pydantic.dev/latest/concepts/unions/ though this is still very much at the level of heuristic. Note that at this point we only have the JSON so to use a discriminated union we would have to change our serialisation also, which might put us in hot water when interfacing with workers that don't use our library. Of course the user can always add an extra field to create a discriminator.
2 participants
EDIT: have set this to auto-merge even though I haven't written the docs part. It should be useful to have in for the pytket-worker branch as similar issue have arisen there.
format_generic_typeand de-emphasisingformat_ptypein codegen.run_graph.)Annotationfrom types and just use underlying type. Required to deal with BackendConfig.