Giters

Strilanc / Quirk

A drag-and-drop quantum circuit simulator that runs in your browser. A toy for exploring and understanding small quantum circuits.

Home Page:http://algassert.com/quirk

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

What exactly is the "output_amplitudes" metadata, and can we get more of it?

Cortexelus opened this issue · comments

commented

When exporting the Simulation Data JSON, what exactly are the "output_amplitudes"?

It seems like a list of real/imag for every classical state (I'm guessing it's in order 000, 001, etc?). It would be more helpful if each were labeled.

But what if my circuit has a looping t value? Is the output_amplitudes just using the current value of t as soon as I press generate? It would be super helpful for my use case to get a list of output_amplitudes for every value of t :)

commented

I'm guessing it's in order 000, 001, etc?

That's right.

what if my circuit has a looping t value? Is the output_amplitudes just using the current value of t as soon as I press generate?

Yes, that's what it's doing. The value that was used is in the dictionary under the key "time_parameter"; it's actually the first entry.

It would be more helpful if each were labeled.

This is a good suggestion; I do agree it would be initially helpful to explicitly key each one. It would avoid ambiguity about big-endian vs little-endian. And it would be doable in a backwards compatible way by adding a "bits" field.

However, I don't want to do this. The issue is that it would noticeably increase the size of the json and you can already feel the browser grind to a halt when generating the json for large circuits. Honestly, I probably shouldn't even have labelled the "r" and "i" components or indented the json of the amplitudes. I don't want to take something that's already too slow and make it even slower.

Anyways, because of that reason, and because it's possible to figure out what the data is by trying a few test cases, I'm going to close this issue as working as intended or at least as "has a not-too-hard workaround so the benefits don't outweigh the performance cost".

commented

Smaller more efficient JSON makes sense.

However, what I really care about is a feature to get the values from many time_parameters between 0 to 1 (e.g. at least 1000 points of time) and wouldn't mind the lag to get it.

commented