-
Notifications
You must be signed in to change notification settings - Fork 65
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add programming section to docs #782
base: develop
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still some room for improvement but this is a very good start :)
# Programming a neutral-atom Quantum Computer | ||
|
||
## Introduction | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
how about having in every page the list of "what will you learn in this page".
This can help the user a lot and probably be very helpful for indexing pages for search engines, like typing in google "rydberg" would bring us up in the search. Wdyt?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you really think it will help for page indexation in Google ? If you have documentation regarding this I am all hear
I have not found better than this https://blog.readthedocs.com/seo-for-technical-docs/
But they don't mention this. However, I guess it can help the user so let's try to write something indeed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So my starting point was to facilitate the users and I think also the structure of the documentation. In principle by just looking at this first box for each page we should be able to see what we cover and what we don't.
The indexing was a bit speculative: I don't know any detail about how this could work but at the same point I am pretty confident that this should help in this direction.
Probably the best people to ask as frontend people. I iwll drop a message askingif anyone has good advice in this direction too
$$ | ||
|
||
If $d=2$ and $N=1$, you have the state of a qubit as above $\left|\Psi\right> = c_{1}\left|a_{1}\right> + c_{2}\left|a_{2}\right>$. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you think that it would help the reader to mention here the three most used levels (ground, Rydberg, hyperfine) maybe in a plot like the one we have here https://pulser--782.org.readthedocs.build/en/782/review.html#digital-approach?
I see the reader has the link to the convention page but there, there is no info about the energetic levels.
:::{important} | ||
With Pulser, you program the driving Hamiltonian by setting $\Omega(t)$, $\delta(t)$ and $\phi(t)$, all the while Pulser ensures that you respect the constraints of your chosen device. | ||
::: | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason for not introducing also the formula written with the Pauli matrix representation here? (similar to what we do in https://pulser--782.org.readthedocs.build/en/782/review.html#rydberg-states ?)
:width: 600 | ||
::: | ||
|
||
The `Device` you select will dictate some parameters and constrain others. For instance, the value of the $C_6$ and $C_3$ coefficients of the [interaction Hamiltonian](programming.md#22-interaction-hamiltonian) are defined by the device. For a complete view of the constraints introduced by the device, [check its description](./apidoc/core.rst). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of referring to the C constant which in the end is not to crucial, I would say here that different devices would support different channels and therefore they would allow different hamiltonian implementation.
Also, the link brings the reader to the general API reference. Probably we should instead point the user to the section of the user manual where we talk about the implementation of analog and digital analog devices in pulser.devices?
The idea is to add a section explaining how to program the machine from an hamiltonian point of view.