search

Strilanc / Quirk

A drag-and-drop quantum circuit simulator that runs in your browser. A toy for exploring and understanding small quantum circuits.
http://algassert.com/quirk
Apache License 2.0
933 stars 158 forks source link

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

Closed Cortexelus closed 3 years ago

Cortexelus commented 3 years ago

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 :)

Strilanc commented 3 years ago

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".

Cortexelus commented 3 years ago

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.

Strilanc commented 3 years ago

Ah I see. For that you will likely need to make custom code modifications and build your own version, or hook into quirk's internals by calling methods from the browser's console.

(Quirk is very much a "do it by hand not by code" sort of tool, and you are hitting up against the limitations of that design; namely it doesn't compose well into an ecosystem.)

On Wed, Sep 29, 2021, 5:42 AM CJ Carr @.***> wrote:

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.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/Strilanc/Quirk/issues/485#issuecomment-930138894, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAATQRMC67A23PZJGGUV63DUEMCT7ANCNFSM5E6O4RTQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.