Add subcommand to convert to/from various result formats #600
Conversation
Also updated run_captured_stim_main to take std::string instead of cstrings, so that a sequence of bytes containing a null byte doesn't get interpreted as a null terminator effectively truncating the sequence.
After updating run_captured_stim_main to take std::string for stdin instead of a cstring, main.help_modes started failing. For cases where an empty string was passed instead of nullptr, run_captured_stim_main created a tmp file and passed it with `--in`. This caused some test cases in help_modes to behave differently than expected. This commit simply updates the output on a single test case to reflect the real output of this command (`stim --help --sample`).
There was a problem hiding this comment.
This is a good start, but there are several more use cases that I think need to be covered. Extend this to include the following use cases:
- I have the DEM, not the circuit, and want to convert detection event data.
- I have neither the DEM nor the circuit but I know all the values that would be derived from them like the bits per shot
- I know how many bits per shot, but I don't know if it's detection event data or measurement data (and I'm not using the DETS format which is the only one where that distinction matters)
- The input file has observable data appended to the detector data, and I want to split the observable data out into a separate file
These use cases all kind of differ in what information they need. In general the command should infer everything it can from whatever the user provides, and if it can't infer a needed quantity it should raise an error identifying that quantity and saying various ways it can be provided.
Thanks, that is a very good point. I naively assumed the user would always have the circuit on hand. I added support for all of these cases, but there is another I'm wondering if we should add. For DETS files we can also attempt to parse the text looking for the value prefixes, but this may not be reliable as the file would need to include the max index of each type, which may not always occur. What do you think? |
|
Because it's not reliable to infer sizes or types from a det file, I would not attempt to do so. |
This can be very useful when comparing results from experiments when the outputs were stored in different formats.