I've been neglectful of this blog lately, but this paper has what I think are some ideas that are a good fit for quantum networking. We're just beginning the discussion about QRNA (Quantum Recursive Network Architecture), though, and comments are very welcome!
Our paper Recursive quantum repeater networks is part of a special issue of Progress in Informatics on quantum information technology.
Thanks to Joe Touch (and his Recursive Network Architecture (RNA) project), and Clare Horsman for their work on the paper. Wouldn't have happened without them.
Thursday, April 14, 2011
#Quakebook
"2:46" is now available on Amazon. 100% of the proceeds go to the Japanese Red Cross. Buy your copy today!
http://www.quakebook.org/
http://www.quakebook.org/
Tuesday, April 12, 2011
Abstracts for Systems Papers
Generic advice on abstract writing for systems papers:
6 sentences in an abstract:
1. Define the problem you're solving
2. Give the key idea for how you solved it
3. Describe how you demonstrate the success of your solution
4. Give key results, preferably numerically
5. Describe how this impacts the world/industry/whatever (big picture)
Next, go back and reread it, and figure out which of those topics
needs a second sentence, and fill that in. Most often, it's the data
or experiment. Viola! Six sentence abstract!
...now go back and think about whether you really need that first
sentence. Often the first two can be combined, if what you are
working on is a well-understood "hot topic". But be *very* careful
about eliminating it, lest you appear to be doing empty-headed "cool
prototype" building. This is also one of the key places your paper
needs to be timeless; people will hopefully read your abstract for
years to come, but they won't read the paper if they don't like the
abstract!
The abstract *must* be clear about whether your results are analytic,
simulated, or measurements of a real-world system or lab prototype.
Not a perfect formula, and formulas shouldn't be over-used anyway, but
it's a pretty good way to do it. The abstracts of 90% of the papers I
read could be improved by following this approach.
6 sentences in an abstract:
1. Define the problem you're solving
2. Give the key idea for how you solved it
3. Describe how you demonstrate the success of your solution
4. Give key results, preferably numerically
5. Describe how this impacts the world/industry/whatever (big picture)
Next, go back and reread it, and figure out which of those topics
needs a second sentence, and fill that in. Most often, it's the data
or experiment. Viola! Six sentence abstract!
...now go back and think about whether you really need that first
sentence. Often the first two can be combined, if what you are
working on is a well-understood "hot topic". But be *very* careful
about eliminating it, lest you appear to be doing empty-headed "cool
prototype" building. This is also one of the key places your paper
needs to be timeless; people will hopefully read your abstract for
years to come, but they won't read the paper if they don't like the
abstract!
The abstract *must* be clear about whether your results are analytic,
simulated, or measurements of a real-world system or lab prototype.
Not a perfect formula, and formulas shouldn't be over-used anyway, but
it's a pretty good way to do it. The abstracts of 90% of the papers I
read could be improved by following this approach.
Subscribe to:
Posts (Atom)