### My GSoC Experience

Recently, I gave a talk at UIC Friendly Friday session!

The slides give an overview about Google Summer of Code, some relevant links and what is in it for students.

Take a peek.

..where we discuss density operators wrt SymPy

Recently, I gave a talk at UIC Friendly Friday session!

The slides give an overview about Google Summer of Code, some relevant links and what is in it for students.

Take a peek.

Advertisements

This has been a great 12 week run filled with learning and valuable experience! I believe I have accomplished most of what I had set out to do. The only other thing pending as far as proposed tasks goes is to relocate the Tr module. This would be based on decisions that needs to be taken by more experienced folks here! Once, the decision is made, I don’t think this would take too much of my time. (I am estimating this based on the current approaches that have been proposed). Therefore, I am committed to getting this done even if this goes beyond GSoC pencils down deadline which is this week!

So, that was all about the wrap up! So, what I am doing now?

~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.

Looking forward, I have taken up another interesting task I am excited to work on. Past week I started working on implementing/completing Shor’s algorithm. The 2 major activities that consumed my time this week were

a) Understand Shor’s algorithm in more detail to help me understand what is available in the current implementation.

b) Review the current implementation and plan on next steps.

After reviewing the current implementation, I have decided to approach this task with the following smaller tasks:

a) Review and complete the implementation of ** QFT gate** ( include tests, documentation), so that it can work independent of Shor’s algorithm.

b) Review and complete the implementation of ** CMOD gate**. Right now, the implementation is not complete, and needs more tests too. This is the set of gates that would do the |a mod N> * |state> over 2^j times for j = { 0, 1, ….2^(n-1)}

c) Put this all together and re-factor the current implementation (especially break down current ** period_find()** ) to help more detail testing.

d) Also, I plan to provide a argument to shor() method, to work as a *flag* to turn on detail logging as the circuit progresses.

All the code I am currenly reviewing and planning to work on are available on the master branch even though it is not complete.

Happy coding!

As discussed in my previous weeks report, this week I started addressing some of the issues in the pending PR’s and all the pending PRs were merged!

In addition to getting the pending PRs accepted, I have stated working on 2 other tasks. One of them, that was completed is the feature to compute Fidelity (PR 1459) of quantum states. Some screen-shots follow (taken from notebook examples available with code base). Information regarding fidelity can be found at these 2 wikis: 1, 2

For the next week, my plan is to finish up work on the implementation of Shor’s algorithm available here.

Here are some examples of using the fidelity function:

This week I largely wrapped up most of the items I had listed in the proposal. The current pending PR addresses and completes most of the major features I had proposed to implement. Some minor issues that are still pending should be addressed during the next week.

1. Adjust qapply() to complete some density based operations more gracefully.

2. Relocate the trace.py modules from core to another suggested folder. There have been some discussions on this on the mailing thread, which I plan to re-initiate and get a closure on this week.

Apart from these 2 items, based on some IRC discussions I had with Brian during past week, I have started looking at following 2 items. My plan is to work on the following 2 items during this month.

1. Finish up implementation of Shor’s algorithm currently available here: git

2. Implement the fidelity and trace distances for density matrices: Ref

Happy Coding!

In the latest PR 2 features have been implemented and relevant examples were added to notebook. Some examples for the first feature, can be found at this post. Some updates and test cases were added after I had discussed it there.

The second is a minor change to qapply() as seen in the following 2 examples:

Happy Coding!

This week was primarily spent on 2 tasks. Getting some of the issues addressed in the currently pending PR 1396. Apart from work on this I have spent some testing some changes I had to make to implement the operations needed when Unitary operations are applied to Density operators.

Some use cases I am currently working on for this are as follows:

1. Using basic kets/bras and generic UnitaryOperator

2. Apply Gates of Density operators with states as Qubits.

Currently, qapply() works on UnitaryOpearator*Ket correctly. But, as seen in the second print statement Bra*Dagger(UnitaryOperator) does not expand out fully. I am currently working on fixing this so that the second part of the expression expands out smoothly.

Therefore, my goal this week is to complete the implementation of UnitaryOperators applied to Density operators, plus address tasks for current PR and another PR ( related to partial trace on qubits) I plan to submit this week.

Happy Coding!

This week has been lot less coding and more of understanding some pieces of codes for next set of changes. As far as the implementation goes, the Tr operations ( including partial trace/reduce density operations) for qubits was implemented.

Some examples of the Tr operations on qubits can be seen here.

An example of an reduced density operation on a mixed-state is shown below

The changes shown above are currently available in my git branch over here. I plan to submit a PR of this branch as soon as the my current PR 1396 is merged.

Another task I have been working on this week is figuring changes needed to qapply() to perform the L and R operations of density matrix. I plan to work on this tasks during next week.

In summary, plan for next week:

1. Address comments on current PR 1396.

2. Submit PR for trace_qubit branch and address any reviews on that.

3. Work on the L and R operations.

With these activities, the next major task that would remain is to set up trace operations for Time Dependent states. I will start researching on the current implementation of this code to understand where my changes would have to go.

On a side note, we are breaking record temperatures in Chicago this week, and it was tough to keep myself cool without an air-conditioner! Hope other Chicagoan Sympy members are doing just fine by the beach!

My week started with some design discussion with my mentors @ellisonbg and @flacjacket. We had a preliminary discussion on how we should go about implementing the Tr (trace) operator.

Based on the preliminary discussion, I submitted a PR 1333 purely for review and got some useful comments. I went back to work and addressed almost all the comments/suggested provided and I have updated the PR with my new changes.

As it stands now, the current PR 1333 has the basic functionality needed for Tr operation. This version still does not handle reduced trace operations and also does not use any options passed through **kwargs. Even, printing will have to be fixed. But, barring any major issues after few more iterations the coming week I am confident this PR can be merged.

So, assuming I will not be adding any more features to the PR, my plan for next week is make sure this PR gets accepted. Since, I am at the summer school next week, I may not be doing any other new coding activity. So, my minimal goal is to make sure this PR is merged by end of next week.

I plan to branch out of this PR, to work on the following activities during next 2 weeks(mostly week after):

1. Fix printing for Tr operator. Currently, the printing is pretty crude. I will also add examples for Notebook along with this task.

2. Fix the is_number operation ( based on what suggestions I get). I am still to understand what “is_number” means to sympy and what scenarios Tr needs to handle. I need to work on this property, since this property is called from the base classes for when 2 Tr objects are added through Add(*[Tr(args,indices)]) operation.

3. Integrate currently existing Qubit logic for partial trace operation.

The above 3 tasks should go into the next PR.

4. Meanwhile, I would like to chat with my mentors and about all use cases (general/special) that we will have to address to TensorProducts wrt to density operators and eventually partial trace operations.

Edit 1: Update (1) to include Notebook.

This week there was fewer lines of code than last week. But, with this week I have almost(except partial trace) merged all changes from @ellisonbg’s densityop branch and ready to extend the implementation to incorporate other features. Most of the time I spent this week is to review and structure my work for the coming weeks and address comments on previous PR . I have provided a detailed plan below.

1. Responded to and completed all comments on last weeks pull PR1312.

2. Pushed a minor code change branch to my git account. This change handles **entropy for general density operators**. (*I am still waiting for the previous pull request to get merged, since this pull request was branched off that.)
*3. Review and understand the partial trace operations and qubit related implementation. Further notes will be prepared for the discussion.

4. Understand current implementation of tensor products to plan work for coming weeks.

*(Note, the detailed plan here still meets the timeline outlined in the proposal. The only change is I will be working fewer hours during Week 4(June 10-16), since I am at the summer school. Hopefully, I can contain the work to not flow into later weeks). *

Implement/test partial trace methods [ **_eval_partial_trace** ] and other required methods for following classes:

QubitDensity (*name suggestion needed!*) : for this I will use the current bit-twiddling algorithm but add detailed test cases.

TensorProduct : Code to handle density operators ( both qubit based, and generic) during expand, mul operations.

TensorProduct : _eval_partial_trace method will split the sub-system to trace. and then based on states inside Tr(|i><k|). [ *This needs more discussions during the next few days and during IRC session.*]

Sub-classes of ‘State’ : Need to decide which subclasses need and how it should be done.

Symbolic Trace operations and Partial Trace operations.

Changes to qapply for L and R operations and any operations that would be needed based on changes so far. (will also fix the bug identified in PR 1312)

I tried IPython Notebook and I absolutely love it. Now, I am using that as my command line interface for running sympy commands and understanding current implementation. The best thing Notebook has done to my workflow is help me save my scratch work and go back whenever I need it. Thanks @ellisonbg.

I did have to jump some hoops to set up Notebook on Ubuntu 11.04, since I had to build a lot of dependencies myself. I plan to blog about it as part of another post. A minor pain point with it is, I need to drag/drop files I want to work on. Wish it gave me an option to type in the URL to a saved notebook rather than forcing me to open a FileManager window to find file to drag and drop.

Today I submitted a pull request

What went into this weeks pull request

The framework and routines were inherited from Brian’s github branch.

- The _eval_args function was added. I went back-and-forth on deciding if we needed strong checks to make sure the states used to build density objects should be strictly
**KetBase**and**Qubits**. But, there were scenarios where just symbols could be used for states, or even QExpr could be used. So, discarded that check. But, this would mean Density objects could have arbitrary objects for states.*Flip side to this is, represent() on density objects which do not have a KetBase object does not work very well.*For example, having ‘mul’ expressions for ‘state’ creates problems in represent functions. But, my assumption is represent function need not handle such scenarios. Similarly, I went back and forth regarding checking for valid values for probabilities. Then, I dropped those validations as well. - Added test routines for all public facing methods in density.py. Some methods from original DensityOp branch are not in this pull request. I will add them back in future requests.
- I also created a minor pull request for minor printing changes that were in the original densityOp branch. This takes care of changes to the latex() in operator.py. I will add checks for density operator after this pull request is accepted.
- Added test routines for changes related to density in qapply.py. These checks will have to be extended after I make density operators work well with Qubits.
- Added doc strings.

Where I spent a my time while trying to accomplish this weeks tasks:

- Understanding the process-function call flow of _eval_args, _print methods.
- Getting familiarized with operator.py , represent(), and qapply().

(The following point is also a question for my next task)

- The way
*_qsympify_sequence(seq)*method is implemented, it treats any Qubit() passed as state to Density as a sequence object. Therefore, the Qubit object is lost and a tuple is replaced instead of the Qubit object. This needs to a fixed or a work around decided so that Qubits can be provided as states to Density objects.

My next steps ( plan for next week’s pull request):

- Discuss with the mentor team and see how to approach the problem with Qubits being converted to sequence. ( in next 2 days )
- Add remaining functionality into density.py ( entropy, reduced trace operations ) ( should be completed by middle of next week )
- Blog about the implementation details of changes to tensorproduct.py with respect to what we would need for density operators. I hope to also have this part implemented by end of next week.
- Address issues with the current pull request. I plan to have this as the top priority task and work on this every time it comes back to me.

Misc:

I gave a lightening talk at Google Chicago office this week regarding my GSoC 2012 project and there was lot of interest in Sympy. Particularly, folks were very excited to know about Sympy Live website which I spoke about in the presentation.

Also, met one of our Sympy contributors Matthew Rocklin at the meeting. Nice to meet someone you know only as an email-id, in person!