search

JuliaQuantum / JuliaQuantum.github.io

Public forum and website repository for JuliaQuantum.
http://JuliaQuantum.github.io
MIT License
39 stars 13 forks source link

J/GSoC2016 discussion #32

Closed acroy closed 3 years ago

acroy commented 8 years ago

As it is already time to think about J/GSoC2016 I created this issue to facilitate the discussion.

Here are some project ideas that came up:

jrevels commented 8 years ago

Visualization: It would be cool to have a package to visualize states etc using a framework which allows it to switch the underlying plotting platform.

I think this specifically should be left to existing packages, like Gafly.jl, Plots.jl, or GLVisualize.jl.

acroy commented 8 years ago

@jrevels : Certainly, but you still need something that "converts" the quantum state into some form, which can be plotted (e.g. it might not be useful to plot the coefficients of the density matrix). The plotting would of course be done via Gadfly et al.

acroy commented 8 years ago

@jrevels : Do you know if there was any further discussion of the "array with basis" type elsewhere? I sort of remember that in our last chat we figured out that this part should be redesigned and pulled out of QuBase, right?

jrevels commented 8 years ago

Certainly, but you still need something that "converts" the quantum state into some form, which can be plotted

Yes, but I don't think it's reasonable for a GSoC project to be devoted to this - it's generally up to the user to decide what they're plotting and in what format. Following your example, the "conversion" you mention could be a purity calculation, measurement expectation value, etc. It might be a JuliaQuantum package's job to help the user obtain these values; once they are calculated, the user can plot them easily using the packages I mentioned.

Do you know if there was any further discussion of the "array with basis" type elsewhere? I sort of remember that in our last chat we figured out that this part should be redesigned and pulled out of QuBase, right?

There's a bunch of different approaches to this, all focusing on different pieces of the same whole. TensorOperations.jl does some label-based indexing at compile-time via @generated functions, then there is CompEcon.jl which is closer to what I originally had in mind for QuBase.jl. I think anybody who attempts this should have very detailed goals that outline where it will be similar to or deviate from existing work. I, unfortunately, don't currently have the time/vision to mentor somebody in such a project.

Roger-luo commented 8 years ago

About the simulator

My original plan was to have three quantum computation models:Adiabatic, Quantum Circuit and one way. The Adiabatic Simulator was written for our lab's use. And I pushed part of the code as a simple adiabatic computation simulator as AdiaRoll on github.

The many-body thing was considered a to-do enhancement for AdiaRoll. But as an undergraduate I do not know much details about the many-body algorithms. I was just thinking if it was possible to simulate more details. So I asked for some mature packages from Prof. He. However it seems the Fortran's modules cannot be compiled to a link library.

And another question

Prof. Han from our lab agreed to be my mentor if it's possible. He can help me to develop packages about Quantum encoding,quantum storage, and some other quantum computation& storage related problems.

But the problem is GSoC only allowed the contributors of the very organization to be mentors? See Rules And Prof.Han do not use Julia, so there may not have code review for me. And he may not familiar with the structure of JuliaQuantum's packages.

And I do not know who else are willing to be my mentor. I'm concerned about if I will have a mentor.

Roger-luo commented 8 years ago

@jrevels I have a simple Bohmian trajectory plotter and I will push it to github after I have my essay checked. And I still think a structure to store the function of states may be necessary due to if I want to draw a Bohmian trajectory I need to do numerical differential operations on the states. And one of the certain type should act like a function or is able to call a function. So the numerical result comes from solvers can also be used like a state. issue 46

@acroy And I think so does the visualization. Users can draw things easily by PyPlot.jl,Winston.jl,Gadfly.jl, but a data structure for storing a state may be needed or sometimes the result of a numerical states becomes much larger. Let users draw what they needs instantly or store things by themselves may not be a good idea.

for more details, I think a state for storage should have such element at least

type state
   coeffs
   bases#the type should be a Union or other ways that can point to a file(a reader function?) or a function
end

for example, a wave function in an area is gained from a Schrodinger equation solver.But for a large area,the numerical data can be pretty large(in my own solver for multi-slits,it can be nearly 200MB for a JLD file,and it can be larger if higher precision is needed). The data of this wave function's value at every position on grids should be stored in a file (JLD file?). And a type that can identify the data file in the source code should be presented to users.

I recommend the JLD,cause it is based on HDF5, and have more potential on distributed computation,but the JLD package use strings to store Julia types in HDF5,so I'm not sure about the performance and if it is appropriate in our condition.

And I'm still not sure about the QuDirac.jl can do this job? Do you mean the type Ket?

reference

Bloch Sphere in QuTiP Visualization in QuTip Quantum++

i2000s commented 8 years ago

@acroy To give a relief to @Roger-luo, could you confirm a mentor without any open-source project experience plus you or other JuliaQuantum developers can make a mentor committee for either GSoC or JSoC project? I think @Roger-luo concerned himself too much on this issue. He actually prefers to start an application-level package on Quantum Information rather than the initial choice of Many-body physics from my correspondence with him.

acroy commented 8 years ago

@jrevels : Re visualization: You are probably right regarding the suitability for GSoC. However, what I had in mind was rather visualization of states, e.g. on a Bloch sphere, as Husimi or Wigner function, state tomography etc. (see also the links given by @Roger-luo). This involves more than just plotting.

Re "array with basis": Its too bad that you are not available for (co)mentoring this one. I think this would be a really useful project. Maybe we can suggest it on the mailing list and see if someone is interested?

acroy commented 8 years ago

@Roger-luo : Re mentor: We could invite Prof. Han to join JuliaQuantum, which would make him a contributor (I think). However, large part of the mentoring is code-review - in particular since the project is supposed to help the organization. I could certainly help with that, but (unfortunately) I won't have as much time as last year, so I can't do it alone.

Re quantum simulator: It is still not entirely clear to me what you want to do, but I have to admit that I had only a brief look into your repo. IMHO it is important to emphasize those parts of the project, which complement/improve the existing code in a broader sense. For example, if you would do many-body systems, we would have to see if the current infrastructure in QuBase is sufficient (probably not) and will need to develop a framework to deal with those sates. This would be useful in a broader sense. Of course this doesn't mean that we shouldn't have an application-focused project (especially if we consider the application crucial for our org), but I think it would be helpful to identify the components/milestones of the project and to see how they fit into the current scheme.

acroy commented 8 years ago

@Roger-luo : Re state type: You should have a look at QuArrays which are in the QuBase repo. The reason for using them instead of normal Arrays is that we need to store information about the basis (this is also the topic of the "array with basis" project). At the moment we don't have any fancy basis types, because no one had time to implement them. QuDirac is way ahead in this respect. In principle, there is no problem in having bases with Gaussians, Hermite polynomials, ... it just requires some work to implement the missing functions etc.

If you want to do computations with the state you have to read it into memory anyways (reading just some parts from the file is probably taking too long). Doing distributed computations, which require distributed arrays, is a different story, which we haven't explored to much. But again, there is no fundamental issue with implementing a basis type for QuArrays, which stores/reads information from a file.

Roger-luo commented 8 years ago

@acroy I see, so I will not worry about the base type uses anymore.

About the simulators

Currently, I think the simulator should have

It can be something like LIQUi>,but may not have all the function that LIQUi> has.For topological part, I have not learnt about this model and error correction yet,so I may not be able to write simulations for topological based computation.Prof. Han can help me in the coding in quantum error correction part.

I think this may about the Quantum circuit model simulations and Quantum error correction in Roadmap.

I may not be able to finish this but it may be possible to start developing this part?

amitjamadagni commented 8 years ago

Hello @Roger-luo, just wanted to know if we are looking at Liquid, is it possible that we are looking something on the lines of Quipper ?! And also regarding the topological part, are we dealing with anyonic braiding for quantum computation ?! If so it would be nice to hear the features that we are looking to implement on these lines.

Roger-luo commented 8 years ago

@amitjamadagni

Further Description of My Proposal

I think it can be something like Quipper. But what I had in mind is a lib like cadence/autoCAD in industry that have APIs for the physical realization rather than a programming language. It's like computer aided design for quantum computation rather than a programming language. So experimental physicists may be able to do experiment more efficiently.(though it's not possible to solve all the problems by our library and will be a long term to achieve this goal)

but I think there's something can be achieved in a short term as listed in my last comment, and I think the currently solver of QuDynamics.jl is able to do some applications.

For Topological part

I just start learning this part. So I cannot design or thinking about it's application at present, but as one of the possible models and have a great error correction ability I think this feature should be discussed or add into the package after I'm capable to write related code, or by someone else to finish this job.

amitjamadagni commented 8 years ago

@Roger-luo

I think it can be something like Quipper. But what I had in mind is a lib like cadence/autoCAD in > industry that have APIs for the physical realization rather than a programming language. It's like > computer aided design for quantum computation rather than a programming language. So experimental physicists may be able to do experiment more efficiently.(though it's not possible to solve all the problems by our library and will be a long term to achieve this goal)

Please do correct me if I am missing something on this, Cadence is more of a grand assemble of libraries, atleast we used it for building various circuits at the physical level and then simulating the same, but do we have a similar standardized quantum architecture at the physical level for simulating quantum circuits ?! If not then it would be a package where we put a particular quantum architecture realization into prime picture implying a library only suiting a very particular setup of realizing quantum systems.

Certain material can be simulated first by our library by setting up some parameters and then be > realized in experiment. So I was planning to be able to simulated the coherence and other details in > the system by many-body library or other libraries.

And for the computation models given above, there should be some APIs that allowed users change details in a certain model,so a modified model can also be simulated by this library.

As I mentioned above is there something pretty common to all the experiments or is it a single experiment in focus ?! if it is the former then we could work on having a base library which supports all the basic functionality which branch out to support various experiments.

a translator and some macro or functions as APIs for Julia to quantum computer can be possible and more useful(in my opinion) by defining some certain programming rules. Like the Dwave's lisp/python/MATLAB And >that's why I tried to write input instructions in binary code in my simulator.

So is it that we are looking at a sort of API for DWave (like systems) or more of an general API but then if this is the case I guess we would be looking something on the similar lines of the above cases.

When I referred to Quipper or Liquid I was mainly thinking of support for generating quantum circuits, mainly this paper as the reference, figure 1 something on those lines.

Please do correct me if something is not in sync !

Roger-luo commented 8 years ago

@amitjamadagni I'm agree with you.I mentioned cadence only for a comparison. I just wanted to emphasize the role this package should play in. I'm not sure if there's something commonly used in experiments.About this I'll ask profs in our lab.

I'm still not sure what can simulators do in further use. But I'm agree that a quantum circuit simulator is necessary. And will it be necessary to create a language based simulator?

About Dwave API.It's because I was thinking you mentioned Liquid.etc to suggest a language based quantum simulator. But I wonder if it is necessary.If we plan to develop a new language,it could be a huge job and users may not want to learn a new one.

So the currently proposal may only be:

Roger-luo commented 8 years ago

hello,everybody! This is Prof. Han(@yongjianhan) from LQCC

rgaiacs commented 8 years ago

Hi all,

I'm talking with @acroy about the GSoC application under NumFOCUS umbrella. I created https://github.com/numfocus/gsoc/pull/69 for this. Tomorrow I will find some time to copy most of the discussion on this thread to a GSoC ideas page.

Cheers, Raniere

acroy commented 8 years ago

Hi together,

It would be great if you could help Raniere doing the copying. At least until the end of this week I won't be able to do anything. On Mon 15 Feb 2016 at 13:34 Raniere Silva notifications@github.com wrote:

Hi all,

I'm talking with @acroy https://github.com/acroy about the GSoC application under NumFOCUS umbrella. I created numfocus/gsoc#69 https://github.com/numfocus/gsoc/pull/69 for this. Tomorrow I will find some time to copy most of the discussion on this thread to a GSoC ideas page.

Cheers, Raniere

— Reply to this email directly or view it on GitHub https://github.com/JuliaQuantum/JuliaQuantum.github.io/issues/32#issuecomment-184187581 .

Roger-luo commented 8 years ago

@acroy @amitjamadagni @yongjianhan @i2000s

I wrote a short abstract about the quantum computation simulator thing. If you have any advice please tell me and I want to ask if this this application for quantum computation really necessary and helpful at present? I've simply realized a lib Kebab ,it can do quantum circuit and adiabatic computation, and some simple quantum algorithms.

And I will write a detailed proposal about quantum simulation/many-body later.

Abstract

As the research of quantum computation grows rapidly, solutions for experimental physicist and quantum algorithm designers may become necessary.

The simulation framework aims to provide a user-friendly numerical solution for simulations of quantum computation in Julia language, which aims to be as close as possible to real experimental equipment(including noises and other non-ideal conditions) and providing APIs for high level programming language or Julia it self. Some of the functions in the to-do list are inspired by Microsoft's LIQUi|>.

The project's idea aims to realize:

BTW,I find the qubit's state can be stored by QuArray cause it is actually a vector and another question:

Will it be possible to add some of the features to QuBase by the develop of other libs?If it is possible, will there be a standard for naming functions or other things? It seems only QuDyanmics have a wiki article for adding new solvers?

About the visualization how about make a list about what kind of physical quantity should be visualized?Or I think the visualization can be done one by one during we develop other features which may need finally visualization rather than make it a project.(cause it may not need a special framework to achieve the features)

PS. I've already have some visualization methods for visualizing Bohm trajectory in Julia (not on github), so if anyone need it, please contact me.

amitjamadagni commented 8 years ago

Hello @Roger-luo

Could you open an issue here detailing the entire proposal (add a .md file) which should broadly include the aim of the project, the plan to achieve it and also a timeline. I guess you could include prototypes on how the code structure could look, this is not required however it would give everyone a clear picture.

As well, for pointers you could look at my previous proposal here, which is on the same repo.

amitjamadagni commented 8 years ago

BTW,I find the qubit's state can be stored by QuArray cause it is actually a vector and another question: Will it be possible to add some of the features to QuBase by the develop of other libs?If it is possible, will there be a standard for naming functions or other things? It seems only QuDyanmics have a wiki >article for adding new solvers?

IMHO and the discussions I have been involved regarding QuBase and new packages happening to depend on QuBase - I think it would be nice if the new feature set or package is independent of QuBase or uses minimum functionality, so as to adapt to the changes in QuBase that might happen in the near future ! (QuDynamics is currently dependent on QuBase, and we plan to make it independent (refer https://github.com/JuliaQuantum/QuDynamics.jl/issues/35) in such a way that, after QuBase is revamped we could always port QuDynamics back to be dependent on the newer version.

One could always add features to the current version but again it should be kept in mind that it would be reworked when someone starts to work on QuBase as the Base package. That said, there is no specific standards as far as I know for adding features to QuBase, just have a scan at the previous PR's (sadly there is no wiki page on this :-( which focus on adding new features to QuBase), that should give a good idea :-)

Roger-luo commented 8 years ago

@amitjamadagni Thanks,I get it. Cause for the Kebab, I will need to define some new basic type to store gates and adiabatic system.

I wrote my proposal by taking the official GSoC proposal example, only have abstract and time line, it seems different with yours, I will rewrite it first.

And I mentioned this idea again, just to ask if it will have contribution to the org? And will it be a nice idea to realize? (I've realize apart of the simulator in Kebab)

A brief intro to Kebab

Kebab's structure is based on the quantum circuit. Everything is supposed to be a gate-like module in this framework. Because a single qubit quantum circuit is a line with many gates on it , which looks like a Kebab :-) so I named it like that.

I just wrote it to explain what I want to do and to make everybody believe it can be independent and not so far from realization in Julia.

More detailed features that have already been realized can be found in README. And I will add more documents.

i2000s commented 8 years ago

While I am reading Roger's proposal, let me ask a few questions and comment out some general thoughts here before I make specific comments in the separated PR:

  1. @acroy and @amitjamadagni , have you figured out how to divide the proposals between GSoC and JSoC? I have been watching the continuous growth of the idealist of the GSoC under Julialang and the julia-dev mailing list, and haven't seen our input from discussions here. As the GSoC program starts to accept proposals very soon, I think it is time to clarify our potentially mentored projects and mentorships. @acroy you may be the main mentor for the projects, but @amitjamadagni can help do a part of code-reviewing for @Roger-luo as there is a big overlap of works AFAIK. If there is anything I can coordinate with @Roger-luo and his other mentor next week, feel free to let me know. After next week, I will be pretty much fully scheduled again (my first time working on 3 research projects in parallel with 5 collaborating groups in different fields).
  2. @amitjamadagni and @Roger-luo, I think you guys can work together for a lot of things, especially for the base repo types and dynamics solvers. I think those overlaps related to QuBase.jl and QuDynamics.jl projects as well as the basic state visualization project can go to another proposal lead by @amitjamadagni other than the one by @Roger-luo . These two proposals of projects if feasible are inter-connected, and making each other easier to implement, also good for a stronger JuliaQuantum. For example, the adiabatic quantum dynamics solver part can be implemented directly by using existing QuDynamics.jl methods, or otherwise enhanced by the feedback from designing the adiabatic solver part in @Roger-luo's work. Although this is going to be determined by @acroy's answer to question 1, I think @amitjamadagni it is a good time for you to divide out some work from @Roger-luo's proposal on what you can do for the base projects and think out an idealist for the JSoC thing for example. Vice verse for @Roger-luo . Otherwise, I don't think the current proposal is feasible for a single person to achieve in 12-14 weeks.
  3. An off-topic point: @amitjamadagni , as we discussed last year, the parallel computing feature could be a big deal for programming in Julia. You may be interested in doing something like GPU computing as well. If you need to get a hand on cluster, GPU or Xeon-phi computings, maybe I can help ask my university's HPC for a collaborator account where is the home of Matlab and a research center for Matlab's GPU computing. In any case, keep in mind that our goal is not to write everything in Julia, I think it is more about bring the users a unified interface in Julia for the best performance and ease of use. Once you finish the basic construction of the base projects in Julia, we will need people to think about integrating other packages written in other languages like Fortran to our library and optimize the performance and parallel computing capability. @amitjamadagni or anyone interested can PM me off-line. If you find any ideas, packages or references that could be useful for future development, I would encourage you to include them to the Roadmap repo (keep the repo updated as current projects go as well).
  4. @jrevels We haven't talked about the future of the QuDirac.jl project for a while. I think it may be feasible for you to think about making QuDirac a symbolic calculus completely compatible package. Surely one can call SymPy from Julia to do some basic symbolic computing and there are other symbolic packages. However, SymPy and others I know of have a lot of not-working features when you do things in quantum language. For example, observed by @jarthurgross SymPy cannot handle trace of density operators properly. I think, moreover, Julia has a better programming abstraction so that it can do things better than Python and other packages. For example, it might be feasible in Julia that once a commutator is defined for operators, the program can simplify equations involving those operators (questioned by @ciaranra). You have demonstrated some of the features when you implemented the creation and annihilation operators in the QuDirac package if I remember it correctly. Think about it, JuliaQuantum will need this and it might become a future GSoC project you can mentor in the future as a full replacement of the Mathematica Quantum Toolbox...
obiajulu commented 8 years ago

Hello,

My name is Joseph Obiajulu, and I'm currently a junior study mathematics, physics, and computer science at Princeton University who is interested in contributing to ODE.jl this summer as part of GSoC.

I know I'm a little late to the game, but I didn't discover JuliaQuantum's own GSoC discussions, which were kind of hidden from sight by the general Julia GSoC mailing-list and idea page.

I was reading up on last year's JuliaQuantum GSoC, and all I can say is that the end result was very impressive. My natural question was if there are any other PDE solvers that JuliaQuantum might want to implement? Also, what testing has been done or still needs to be done with the recent developments?

Also, since the spirit of open source projects is all about contributing to the group project, I am curious what projects the JuliaQuantum community may like to see implemented (for example: I saw some talk about QuDirac in @i2000s' last post)

Hopefully there is a project that I might be able to help progress!

Also, @Roger-luo , your project idea sounds absolutely cool. Whether or not I get to join the JuliaQuantum team for the summer, I will be very curious to see how this project develops. Keep up the great work!

-Joseph

i2000s commented 8 years ago

@obiajulu Thanks for your interest on this thread of discussion. I think you have noticed the masterpiece of work done by @amitjamadagni , @acroy and @jrevels , there has been a framework set up for the basic quantum dynamics solvers involving the ODE.jl package. Possibly @amitjamadagni and others have better comments on this area than mine, but I would say there are basically two major directions that you can dig deeper. One is the optimization of the differential equation solvers--especially considering parallel computing on various platforms. The other is the not-well-covered solvers, like the solver for Stochastic differential dynamics/equations. I cannot comment on the testing part.

I noticed you have comments on the symbolic computing package on the Julia-user group. Seems everyone is satisfied with the SymPy.jl package, but there seems to be non-working pieces in the original SymPy package for quantum simulations experienced by other users. If you are interested in this direction, feel free to accumulate some ideas and references on the _Roadmap_ repository over time and try to implement some ideas. It would be nice to have a prototype implemented on your own before starting a GSoC project for a fast-paced run.

Just comment in the repos under the org if you have any other related questions. Thank you for your interest again!

amitjamadagni commented 8 years ago

@obiajulu

I would say there are basically two major directions that you can dig deeper. One is the optimization of the differential equation solvers--especially considering parallel computing on various platforms. The other is the not-well-covered solvers, like the solver for Stochastic differential dynamics/equations. I cannot comment on the testing part.

Yup, Qi is spot one, you could work on the optimization of the solvers or could add more solvers. For adding new solver to QuDynamics, please refer to the following wiki article. Also you could have a look at the issues and pick up from there. If you have any questions relating to QuDynamics.jl please feel free to ask me questions on gitter (amitjamadagni-github handle) !

Just comment in the repos under the org if you have any other related questions. Thank you for your interest again!

You could also reach us at the gitter room. Thanks for your interest !

acroy commented 8 years ago

@obiajulu : Thanks for your interest. Most of the general points have already been said, let me give some specific ideas regarding dynamics:

As the others said, feel free to browse the issues for our current projects and ask how to contribute by posting a message (some even have a "help wanted" tag).

obiajulu commented 8 years ago

Hey guys,

First off, thanks for all of the help and feedback so far. I should start by thanking everyone for giving such great feedback as to what they think would make a good J/GSoC project over the last three days. I have researching and working on different project proposals, and wanted to update you all with a couple of GSoC projects. I am especially interested to hear what you all think of these potential directions for the summer and see if there are any who would like to be a mentor on one of these projects. Also, I'm eager to help the Julia community, and some of these proposal may be a bit ambitious; I would greatly appreciate your help in predicting what could be done in one summer and what I must save for later contributions:

Project idea: Implementation of Numerical Methods Useful for Solving Time Dependent Schrodinger equations. Would focus on one or more of the following, depending on which the Julia and JuliaQuantum community most are interested in

  1. Implementation of symplectic splitting methods
    1. PRK (Partitioned Runge–Kutta)
      1. http://personales.upv.es/serblaza/2002JCAM.pdf
      2. http://sanzserna.org/pdf/645_JMSS-A.%20Portillowavepacket.pdf
    2. Implementation of Lanczos method time propagation
      1. Motive: The Lanczos method “For time-dependent Hamiltonian operators the Lanczos method is the best choice, because it provides good accuracy and efficiency for a wide class of potentials” (source: http://arxiv.org/pdf/1407.7370.pdf)
      2. Reach goal: Other Krysolv space methods, like BICGSTAB(I) and/or other polynomial approximation method Chebseyv, potentially building off work done in ApproxFun.jl
    3. Implementation of Floquet Change of Basis Method
      1. For systems with periodic time-depedent Schrodinger
      2. Motive: Issue #34 in QuDynamics.jl
    4. Other General Resources:
      1. http://lup.lub.lu.se/luur/download?func=downloadFile&recordOId=3363166&fileOId=3363176
      2. https://na.uni-tuebingen.de/ex/num4_ss10/lecture/chap3.pdf
      3. http://www.sam.math.ethz.ch/~mhg/pub/biksm.pdf
      4. http://qutip.org/docs/3.1.0/guide/dynamics/dynamics-floquet.html#
      5. https://en.wikipedia.org/wiki/Lanczos_algorithm
      6. https://en.wikipedia.org/wiki/Biconjugate_gradient_stabilized_method I am and will continue to work on this idea and the various details of implementation. Also, I figure having multiple potential implementation projects is always a good thing, especially if one finds themselves finishing one earlier than anticipated.

Once again, I would love to hear your feedback and be curious to see who might be interested in mentoring for this project.

PS: Sorry for posting here again instead of glitter or different repos, I just figured since I was looking for someone who might be interested in mentoring the project, posting this here would ensure most people in the conversation thus far get to see it.

i2000s commented 8 years ago

@obiajulu Thanks for your efforts! I think your ideas are pretty concrete and well-organized. The main constrain here is whether if you can find a mentor for this project if you plan to commit to a GSoC project. I would suggest you to implement the framework aside to see if this is feasible and compatible with the current JuliaQuantum projects. The community would definitely welcome your contributions in any form. Others may have better comments here.

i2000s commented 8 years ago

@JuliaQuantum/juliaquantum As proposed by @Roger-luo and @yongjianhan, there can be a Gitter/Skype meeting at 21:00 Beijing time on Monday (March 21st). The main topic is to form a GSoC team for the project proposed by @Roger-luo and to detail the timeline. We haven't received all confirmations from the member team of the org, but please let me and @acroy know if you are interested in participating and helping code review for the related project. We are most likely to chat on Gitter so that people can find the chat record if missing the event. We still hope to see more helpers on the project. It is also possible to chat on other ideas and proposals during the meeting. Further notice may come soon.

i2000s commented 8 years ago

@JuliaQuantum/juliaquantum We are on Gitter now. Click the Amit-Gitter button on the frontpage, or teleport here. https://gitter.im/JuliaQuantum/JuliaQuantum.github.io . See you there :)