Too many types beyond convenience

[i2000s]

I understand that you have mastered all your own definitions of types. It might be helpful for open source developing to avoid defining unnecessary types, and at least to provide dismatching methods for the most fundamental type inputs.

Here is my suggestion:

1. Use the most common Array types (both sparse and full) as the first-class definition for functions/methods. In this way, combining your package with other packages or their conventions will work seamlessly. For developing this package, if you have any changes on the definitions of self-defined types, there will be little pain to adapt to those changes in all related methods since they are defined using the first-class types. One can focus on implementing general algorithms without worry about changes of the other parts of definitions, as a result.
2. Reduce your self-defined types through some level of generalization:
   1. For operators, just defining some commonly used ones is good enough. What I think is helpful is the Pauli operators in SU(N) rotational symmetric groups, creation and anniallation operators in Fock space, X(Q) and P operators in the real space. Users should be able to define their own operators based on this set of operators. However, I would not suggest you to work on this at this stage. We can wait for the completeness of the QuRep.jl or QuDirac.jl project to have a shape so that we can render their definitions here.
   2. Use the conventions of Quantum objects and function formats that have been widely used in other well-known packages like QuTIP in Python or QOToolbox in Matlab. For example, one might have experiences of using QuTIP and now want to try your package. If your package uses the conventions that has been used in the QuTIP(inherit almost all conventions from the QOToolbox), they will be happy to adapt to the new language. In practice, you might want to consider to define a similar Qobj type to combine all your QuState and QuStateVec business in one unified interface. The master equation type and such could be avoided, in the sense that all the related development of new functions have to consider to implement vast matching rules for all these kinds of definitions. You can check the mcsolve.jl function in my mcwf branch for what I have been suffering and what I have been working on to simplify the definitions without breaking your conventions (WIP). However, you can change your definitions at any time, since I have define the first-class methods does not rely on any extra packages.
   3. For the computational setting part, you might want to define a configure type just for a unified interface to the equation solvers. These setting parameters are strongly determined by the expm and expmv functions and related ODE solving methods. So, it should include tolerance, number of processors to be used for parallel computing, max iteration times, alternative algorithms and so on. This part should be carefully designed.
3. Beyond all of the above, better to have some more comments on your code to explain definition of variables, algorithms and references while you are writing the code at the first time. Better formate your coding style and division of files will encourage people to participate your project.

Hope this helps.

[acroy]

Thanks for the input. Maybe I will change my mind about some of the points, but here are my thoughts:

1. (Use the most common Array types): I see your point, but I am not 100% sure I agree. There are certainly functions which are sufficiently general (like expmv, lindbladsuperop) and which should use the more common types. Most likely there is also no problem to integrate a PR which uses Arrays and such rather than QuStates. But I think that types, which are carefully designed, can make life a lot easier (and the code more readable). For example, look at packages like IterativeSolvers.jl to see my point. Anyways, I will keep it in mind for the future.
2. Reduce your self-defined types
   1. (operators): So far there is no operator type. One can just use any AbstractMatrix. There are just a few convenience functions which return the respective matrices, but some more would be nice. Eventually we will have something like a QuArray which stores information about coefficients and the basis. This type can be used to construct states and operators (either via typealias or as fields).
   2. (QuTIP) I have to admit that I never looked much into QuTIP et al. So I will depend on the input of others in this regard. The Qobj type sounds a bit like the QuArray I mentioned above. Regarding "master equation type and such" I strongly disagree though. One of the beautiful aspects of Julia is multiple dispatch and the possibility to define first class (custom) types. Of course the type hierarchy has to stabilize at some point, but this will need some time. Also, I don't really understand why you need all the extra definitions in your mcwf branch? BTW You are missing the problem, that for a mixed state you actually need to do a spectral decomposition to choose the initial state vector (see my latest commits). IMO mcsolve is a tricky example for using only common Arrays, since you have to distinguish between state vectors and density matrices. One could use a flag or always assume the matrix to represent a density matrix ...
   3. (configure type for solvers) This is actually what the QuPropagators will do eventually. As you say this has to be carefully designed, which will get easier if there are a few more solvers (e.g. Runge-Kutta and MCWF) and one sees what kind of options are needed/convenient.

[i2000s]

I think it is a good starting point to have density matrix initial state considered in your code. I will look forward to seeing the further development of the package.

BTW, what I have been doing this week is to have a nice documented yet simple protype code for our new developer, Hao, to get on the board. He has coding experiences on normal Monte Carlo simulations and intensive experience on data mining and parallel programing. However, he might have found difficult to read over your code which has not been well documented. So, my code is just to serve as a help doc for him to go over this process, and I did not expect to make it as powerful as it should be completed in a long time. The first practice for him is just to add the simple parallel macros onto the code, and he may want to further consider GPU computing in the future (really mainly depends on his self-satisfaction of this period of experience and future needs). I appreciate that he is busy yet he is interested in this project. Once I am done this week, he will decide what he is going to do next. Hope my input is helpful to keep Hao and more developers to this project, even they may not have much experiences on quantum theory. Best wishes to your project and community inputs.

On Wed, Aug 13, 2014 at 2:46 PM, acroy notifications@github.com wrote:

Thanks for the input. Maybe I will change my mind about some of the points, but here are my thoughts:

1.

(Use the most common Array types): I see your point, but I am not 100% sure I agree. There are certainly functions which are sufficiently general (like expmv, lindbladsuperop) and which should use the more common types. Most likely there is also no problem to integrate a PR which uses Arrays and such rather than QuStates. But I think that types, which are carefully designed, can make life a lot easier (and the code more readable). For example, look at packages like IterativeSolvers.jl to see my point. Anyways, I will keep it in mind for the future. 2.

Reduce your self-defined types

1. (operators): So far there is no operator type. One can just use any AbstractMatrix. There are just a few convenience functions which return the respective matrices, but some more would be nice. Eventually we will have something like a QuArray which stores information about coefficients and the basis. This type can be used to construct states and operators (either via typealias or as fields).
   2. (QuTIP) I have to admit that I never looked much into QuTIP et al. So I will depend on the input of others in this regard. The Qobj type sounds a bit like the QuArray I mentioned above. Regarding "master equation type and such" I strongly disagree though. One of the beautiful aspects of Julia is multiple dispatch and the possibility to define first class (custom) types. Of course the type hierarchy has to stabilize at some point, but this will need some time. Also, I don't really understand why you need all the extra definitions in your mcwf branch? BTW You are missing the problem, that for a mixed state you actually need to do a spectral decomposition to choose the initial state vector (see my latest commits). IMO mcsolve is a tricky example for using only common Arrays, since you have to distinguish between state vectors and density matrices. One could use a flag or always assume the matrix to represent a density matrix ...
   3. (configure type for solvers) This is actually what the QuPropagators will do eventually. As you say this has to be carefully designed, which will get easier if there are a few more solvers (e.g. Runge-Kutta and MCWF) and one sees what kind of options are needed/convenient.

— Reply to this email directly or view it on GitHub https://github.com/acroy/QuDOS.jl/issues/5#issuecomment-52108314.