polish README #195
polish README #195
Conversation
Codecov Report
@@ Coverage Diff @@
## master #195 +/- ##
=====================================
Coverage 20% 20%
=====================================
Files 2 2
Lines 5 5
=====================================
Hits 1 1
Misses 4 4Continue to review full report at Codecov.
|
Pull Request Test Coverage Report for Build 1204
💛 - Coveralls |
3 similar comments
Pull Request Test Coverage Report for Build 1204
💛 - Coveralls |
Pull Request Test Coverage Report for Build 1204
💛 - Coveralls |
Pull Request Test Coverage Report for Build 1204
💛 - Coveralls |
Pull Request Test Coverage Report for Build 1205
💛 - Coveralls |
|
@GiggleLiu good to merge? |
| Our design enables: | ||
|
|
||
| * Hierarchical design of quantum algorithms and greater abstraction for quantum circuits | ||
| * Heterogeneous computing |
There was a problem hiding this comment.
What is exactly heterogeneous computing?
There was a problem hiding this comment.
heterogeneous means it can run on different hardware.
The design of block IR is hardware free. It enables heterogeneous computing.
I could add a link to wiki for this.
There was a problem hiding this comment.
Why not remove it if it requres wiki, it is not the key feature. Do you mean GPU backend? Then just say GPU support.
There was a problem hiding this comment.
It is not only about GPU support, it is about the why is the design hardware free, what does this hardware free capable of. Heterogeneous is conceptually a more powerful and precise description of hardware free.
There was a problem hiding this comment.
Simply say it is GPU support cannot cover other work in YaoExperiment, YaoGraphs, and other possible direction that other people are interested in (like real hardware support in Regetti). Thus heterogeneous is better, if you think this needs some description, we could add a link. But you can't get rid of this concept if we are still dealing with this arch, and this is a very common feature among many softwares.
This concept has been existing for decades, if people don't understand it, they should read wiki and learn it.
There was a problem hiding this comment.
Most framework supports hardware... I mean this is not a unique feature. Also, YaoExperiment has only basic support.
There was a problem hiding this comment.
Yeah, but I mean even it is basic, we have it, and we also have RBNF for QASM. The design of quantum block IR itself is mature to support heterogeneous computing already. And since some companies are interested in using it, heterogeneous shows the ability of Yao that can be extended to their own hardware, and if the Harvard group is going to use it, we (or at least you, you are the guy got hired) need to support their hardware at least.
So what would you suggest here? a link? or?
There was a problem hiding this comment.
So far, we do not have reliable support to QASM. So let's just remove it?
There was a problem hiding this comment.
You misunderstand what I meant here. Heterogeneous computing is a feature for quantum block IR (note there is "our design enables" as the condition), it's not about QASM and other features of Yao, we didn't say "our design supports"
The whole point of getting rid of T and MatrixBlock is to make it a better design for heterogeneous computing (or it can be hardware related). This feature means you can extend Yao easily to your desired hardware, which doesn't have to be supported by ourselves.
Without this feature of quantum block IR, you can't extend Yao to QASM/CUDA/etc without dealing with the hardware abstraction (like the precision of blocks).
Even you think heterogeneous computing is a hard word to understand for non-CS background people, we can change the language, but it is a very important feature of quantum block IR. I believe this is something deserve to be mentioned in README.
|
It does not change much, I think? This package is for physists, this is important. My suggestion is
|
|
This goal of this PR is to make it more native in English. Not to change the contents. I'm working on documentation for benchmarks, will add it in another PR. I don't think it is good to put examples to README, it is painful to read a huge README. It is better to be short and straight forward. We can provide links to documentation and examples. A glance of the interface (like a 3 line QFT code) might be sufficient, but I don't want to make README huge, that should be in documentation and front page. |
Can't agree, but agree with you that README should not be too long, and current README is already too long. Making it concise does not mean containing no example at all. I can look into it later. I am ok to merge this PR. |
|
I mean we can't put all the examples to README, this is not a good README. A glance of code with reasonable size, like an example of QFT is good, since it only has 3 lines. But anything larger should be in documentation or a front page instead of putting it in README. |
|
Let's merge this and revise things after the paper is done? @GiggleLiu |
|
ok |
Polish the README to make it more native based on @ViralBShah's suggestions. Thanks BTW.