The strongest *individual* SWNT tested thusfar was just over 60GPa.
The real problem is that the strengths quoted for SWNTs exclude the area enclosed in the nanotube, while the densities used in the calculation include that area. You can't get close to 60GPa in real stress in a nanotube, where you mean the force divided by actual area of nanotube. Of course, what matters for space elevators is really the force per unit mass....
Darcs and Arch both have this. (Arch undoubtedly has the most extensive protocol support of any revision control system.)
Although Arch does have extensive protocol support, I'm not sure it's up to par with darcs, since I think it's missing support for some obscure protocols such as http and gopher.
No, I'm afraid the footnote is dead on. When patches are commuted their content changes, although their meaning remains the same. This happens when people pull (or push) patches from one repository to another.
There is an idea, a repository of patch bundles, which could allow signed patches to be kept, at the cost of either duplication of information or inefficiency. It would "just need to be implemented." It would be a bit tedious, but is simple enough that it could be done (terribly inefficiently) using external scripts.
1. It's actually hard to use the patch commutation code to do any good outside the concept of a darcs repository.
1.5 I've thought about creating a C library for manipulating/querying darcs repositories, but haven't gotten around to it. The hard part would be of course designing the API. Ideally I'd like the interface to be such that programs using the library couldn't accidentally corrupt the repository.
2. Darcs requires ghc, since it uses some library code only available in ghc to do more efficient IO, string manipulation and to access zlib. It turns out to be a pain on many systems to link with the necesary libaries when using the interpereted version of ghc. So probably accessing darcs from perl will have to go through the executable until a C library is written (which could of course have perl bindings).
3. Rewriting darcs in perl (or parts of it) would be possible, but would be a pain. In particular, the commutation of patches which have conflicts is pretty complicated.
Darcs get (equivalent to CVS checkout) is the single least efficient command in darcs. People keep telling me I need to fix this, since it's the first thing users see, but it's really not an important command to optimize (apart from first impressions issues). When run locally (to create a new branch) it's fast.
And comparing darcs get with cvs checkout really isn't fair, since darcs gives you a copy of the full history of the repository, a separate branch on which to record changes before committing them to the centralized repository, and the ability to browse the history offline.
If you want a fast get, just run optimize --checkpoint on the parent repository (assuming you've tagged recently--if not, then tag the current state first), and then use the --partial flag when running darcs get. It'll still give you more flexibility than a cvs checkout, and will be much faster.
Actually, whether or not an RCS is self-hosting is a pretty useless test of the maturity of that RCS. It is incredibly easy to self-host an RCS, since the users are the developers. Darcs was self-hosting way back before I would even have considered suggesting that anyone else consider using it (as I'm sure was the case with Arch).
The hard part of writing an RCS is dealing with all those users who do things you never would have thought of, uncovering all sorts of interesting bugs.
Actually, I thought that Avogadro's number was now a defined quantity, but we no longer know the conversion rate between amu's and grams. If I remember right, they decided to define Avogadro's number back when I was in high school.
I would imagine that the use of AltiVec/VMX single-instruction multiple-data instructions would be somewhat more effective in doing vector and matrix floating-point computations than scalar floating-point operations as provided by the dual FPUs -- especially on these smaller (4x4, 8x8) matrices.
For me at least (and most other scientific users), AltiVec is useless, since I use double precision floats which it doesn't support.
"Speed bump" is a term Apple introduced a few years back as a punning way of describing an increase in speed (i.e. bumping up the speed). Since then it has been used to describe the process Apple goes through when it doesn't have any new computers, so it just increases the speed of each model without changing anything else (including the price).
There is no solid involved in a free electron laser. How could it be called a solid state laser? There is such a thing as a solid state laser, and it is also called a diode laser.
Another thing not widely covered in the normal monkey media: Gulf War II will almost certainly premiere our new "directed energy" weapon systems which have quietly been brought out of the labs over the past year or so...
... It's not clear if they can be directed or if it goes off in a sphere like a ghostly bomb.
So we'd be looking at an undirected directed energy weapon, then?
Ok, I'll bite. READ THIS [highliftsystems.com] (warning, it's a pdf file), and once you do, say it again.
This is just impossible!:)
But seriously, I did read it. Well, really just the section about nanotubes, and if the rest of the paper is equally fallacious, I think that would serve as pretty conclusive evidence of the imposibility of the space elevator. Using a combination of an overestimate of the strength of nanotubes with an underestimate of their density, the author uses a strength/mass ratio that is twice as large as the UPPER bound on the strength of nanotubes (which is the ideal strength). In practice the ideal tensile strength is typically many times higher than the yield strength. In case you're wondering, this is based on density functional calculations I performed myself--far better than the crude estimates refered to in the paper. And yes, I did just check his
source. It's a review paper that refers to an extrapolation of a strength based on a strain from a tight-binding molecular dynamics calculation which the authors recommend taking with a grain of salt.
On the experimental side, noone has yet (to my knowledge) produced a composite based on nanotubes which is actually particularly strong. Even if these composites are developed (and probably eventually nanotube composites will surpas carbon fiber composites), they are guaranteed to pay a major hit in strength/mass due to the mass of the epoxy. Look for more like a factor of two over carbon fiber composites, rather than the factor of 50 or so advertised.
As mentioned in the paper, the mass of cabling needed is extremely sensitive to the strength/mass ratio. I don't know the relation (since I haven't looked up the Pearson paper), but he mentions that if you diminish the strength/mass ratio by a factor of 50 (using kevlar) from his fictitious nanotube ratio, the mass goes up by about a factor of 100,000. With an overestimate of the strength of nanotubes of at least a factor of two, probably much more, it seems highly unlikely that the cost of the elevator (already estimated to be rather high) will be within reason, and for all I know there may similar "rounding up" going on in the rest of the paper.
Yeah but even so, MM has a great story to go with it. I forgot whether it was Michaelson or Morley, but one of them went to his grave wishing he had never performed the experiment (in spite of winning a Nobel prize), since it had led to special relativity. I mean, they included Foucault's pendulum! Did someone really need to prove in 1856 that the earth rotated? Just because it's really relaxing watching a Foucault pendulum go back and forth doesn't put it in the top 10 most beautiful physics experiments. Michaelson and Morley with their massive granite optical bench floating in mercury had a pretty beautiful experiment, too.
1) How do we know that determining the bubble pattern of the fob is difficult enough to determine? This seems to me to boil down a simple, but large, ray tracing problem.
For one thing, because there is no unique solution to the problem! There are many bubble patterns which may produce the same speckle pattern for a given angle of illumnation (this being the whole point of the scheme). But of course, each speckle pattern can only be used once. What you need to do is reproduce ALL the speckle patterns for all angles of incidence. This is what makes it a hard problem.
I don't know that it's a provably hard problem like factoring, but the raytracing example is totally irrelevant. The basics of raytracing were known a hundred years ago (and haven't really changed much since...). In contrast, in spite of a lot of research, noone has come very close to solving the inverse scattering problem.
Validation at an untrusted reader is done by probing the object using challenges previously performed at a trusted reader. Those challenges are "used up" as the object is validated, because otherwise, they could be replayed. This is much less convenient than a public/private key system.
This is a good point. However, for something like an ATM card, this probably would be no problem. The bank stores 1k speckle patterns from my token and uses them for the first thousand times I use it. Then (around the 900th time I use it) it tells me I need to go to the bank's ATM machine to get my card recharged. There the machine records another thousand speckle patterns at another thousand angles. Once this infrastructure was in place, this wouldn't necesarily be an inconvenience.
I think the correct term would be quasirandom. A quasirandom sequence is one that fills a space in a sort of random manner while observing some constraints. For example, when performing a monte carlo integration, you would rather avoid sampling data points that are very close, so a quasirandom sequence can give better convergence. On the other hand (in the case of the integration) you sacrifice the rigorous error estimation that is possible using true pseudorandom numbers.
I just read the article you linked, and am afraid the scientists quoted are a bit overoptimistic. They assume the space elevator will be built of nanotube composite materials which have not yet been invented, and then assumes that these (hypothetical) materials can be mass produced at very low cost.
We may indeed be able to make tons of nanotubes very soon, but we have yet to be able to make a macroscopic nanotube thread (say, the diameter of a human hair, and three centimeters long) of any size which is anywhere close to the strength of nylon.
I generally run with the newest stable kde, the newest stable kernel and the newest stable mozilla. The results are an average of a (mozilla) crash a day, sometimes far more.
I would guess that maybe you have a plugin or two installed (flash or acrobat plugin?). Once I removed those mozilla stopped crashing for me. Of course, now I am actually using galeon.
That's the whole point (well, besides some custom software, I'm sure). Alpha smarts don't need to have lots of RAM or speed or color. They are about giving kids who've never used a computer the chance to type and edit their stories and essays.
Think of it not as a limited laptop, but an extra-functional-for-the-classroom desktop. A class set of desktop computers would be useless because there is no room for them all. One or two computers in a classroom have some use, but not much, since the class can't all use them. Besides, a real computer is too hard to use for the kids who would benefit most from them (those who've never used one before).
A class set of alpha smarts is wonderful. The kids (at least in inner city Oakland) love them. They can't mess them up, and they're really easy to use. Basically, each one holds maybe 8 text files, with one convenient button for each text file. I don't remember precisely. My sister is has a quarter class set (or something like that) and explained them to me once.
The real problem is that the strengths quoted for SWNTs exclude the area enclosed in the nanotube, while the densities used in the calculation include that area. You can't get close to 60GPa in real stress in a nanotube, where you mean the force divided by actual area of nanotube. Of course, what matters for space elevators is really the force per unit mass....
Although Arch does have extensive protocol support, I'm not sure it's up to par with darcs, since I think it's missing support for some obscure protocols such as http and gopher.
No, I'm afraid the footnote is dead on. When patches are commuted their content changes, although their meaning remains the same. This happens when people pull (or push) patches from one repository to another.
There is an idea, a repository of patch bundles, which could allow signed patches to be kept, at the cost of either duplication of information or inefficiency. It would "just need to be implemented." It would be a bit tedious, but is simple enough that it could be done (terribly inefficiently) using external scripts.
1. It's actually hard to use the patch commutation code to do any good outside the concept of a darcs repository.
1.5 I've thought about creating a C library for manipulating/querying darcs repositories, but haven't gotten around to it. The hard part would be of course designing the API. Ideally I'd like the interface to be such that programs using the library couldn't accidentally corrupt the repository.
2. Darcs requires ghc, since it uses some library code only available in ghc to do more efficient IO, string manipulation and to access zlib. It turns out to be a pain on many systems to link with the necesary libaries when using the interpereted version of ghc. So probably accessing darcs from perl will have to go through the executable until a C library is written (which could of course have perl bindings).
3. Rewriting darcs in perl (or parts of it) would be possible, but would be a pain. In particular, the commutation of patches which have conflicts is pretty complicated.
Darcs get (equivalent to CVS checkout) is the single least efficient command in darcs. People keep telling me I need to fix this, since it's the first thing users see, but it's really not an important command to optimize (apart from first impressions issues). When run locally (to create a new branch) it's fast.
And comparing darcs get with cvs checkout really isn't fair, since darcs gives you a copy of the full history of the repository, a separate branch on which to record changes before committing them to the centralized repository, and the ability to browse the history offline.
If you want a fast get, just run optimize --checkpoint on the parent repository (assuming you've tagged recently--if not, then tag the current state first), and then use the --partial flag when running darcs get. It'll still give you more flexibility than a cvs checkout, and will be much faster.
Actually, whether or not an RCS is self-hosting is a pretty useless test of the maturity of that RCS. It is incredibly easy to self-host an RCS, since the users are the developers. Darcs was self-hosting way back before I would even have considered suggesting that anyone else consider using it (as I'm sure was the case with Arch).
The hard part of writing an RCS is dealing with all those users who do things you never would have thought of, uncovering all sorts of interesting bugs.
Actually, I thought that Avogadro's number was now a defined quantity, but we no longer know the conversion rate between amu's and grams. If I remember right, they decided to define Avogadro's number back when I was in high school.
The point was that you can't count either 6.0221367e23 atoms or 5.01844725e20 atoms.
Fortunately the local gravity itself can be measured in meters and seconds, so while it may be a pain, it poses no fundamental problem.
From Evan's thesis defense (which was just a few weeks ago):
:)
Random destruction is fun, but why waste a perfectly good photonic crystal?
I see that vecLib supports double precision and supports altivec, but that doesn't change the fact that altivec doesn't support double precision.
For me at least (and most other scientific users), AltiVec is useless, since I use double precision floats which it doesn't support.
"Speed bump" is a term Apple introduced a few years back as a punning way of describing an increase in speed (i.e. bumping up the speed). Since then it has been used to describe the process Apple goes through when it doesn't have any new computers, so it just increases the speed of each model without changing anything else (including the price).
There is no solid involved in a free electron laser. How could it be called a solid state laser? There is such a thing as a solid state laser, and it is also called a diode laser.
No way they can mean free electron laser by solid state laser. It could only mean an every day diode laser (except really big...).
Another thing not widely covered in the normal monkey media: Gulf War II will almost certainly premiere our new "directed energy" weapon systems which have quietly been brought out of the labs over the past year or so...
... It's not clear if they can be directed or if it goes off in a sphere like a ghostly bomb.
So we'd be looking at an undirected directed energy weapon, then?
This is just impossible! :)
But seriously, I did read it. Well, really just the section about nanotubes, and if the rest of the paper is equally fallacious, I think that would serve as pretty conclusive evidence of the imposibility of the space elevator. Using a combination of an overestimate of the strength of nanotubes with an underestimate of their density, the author uses a strength/mass ratio that is twice as large as the UPPER bound on the strength of nanotubes (which is the ideal strength). In practice the ideal tensile strength is typically many times higher than the yield strength. In case you're wondering, this is based on density functional calculations I performed myself--far better than the crude estimates refered to in the paper. And yes, I did just check his source. It's a review paper that refers to an extrapolation of a strength based on a strain from a tight-binding molecular dynamics calculation which the authors recommend taking with a grain of salt.
On the experimental side, noone has yet (to my knowledge) produced a composite based on nanotubes which is actually particularly strong. Even if these composites are developed (and probably eventually nanotube composites will surpas carbon fiber composites), they are guaranteed to pay a major hit in strength/mass due to the mass of the epoxy. Look for more like a factor of two over carbon fiber composites, rather than the factor of 50 or so advertised.
As mentioned in the paper, the mass of cabling needed is extremely sensitive to the strength/mass ratio. I don't know the relation (since I haven't looked up the Pearson paper), but he mentions that if you diminish the strength/mass ratio by a factor of 50 (using kevlar) from his fictitious nanotube ratio, the mass goes up by about a factor of 100,000. With an overestimate of the strength of nanotubes of at least a factor of two, probably much more, it seems highly unlikely that the cost of the elevator (already estimated to be rather high) will be within reason, and for all I know there may similar "rounding up" going on in the rest of the paper.
Yeah but even so, MM has a great story to go with it. I forgot whether it was Michaelson or Morley, but one of them went to his grave wishing he had never performed the experiment (in spite of winning a Nobel prize), since it had led to special relativity. I mean, they included Foucault's pendulum! Did someone really need to prove in 1856 that the earth rotated? Just because it's really relaxing watching a Foucault pendulum go back and forth doesn't put it in the top 10 most beautiful physics experiments. Michaelson and Morley with their massive granite optical bench floating in mercury had a pretty beautiful experiment, too.
For one thing, because there is no unique solution to the problem! There are many bubble patterns which may produce the same speckle pattern for a given angle of illumnation (this being the whole point of the scheme). But of course, each speckle pattern can only be used once. What you need to do is reproduce ALL the speckle patterns for all angles of incidence. This is what makes it a hard problem.
I don't know that it's a provably hard problem like factoring, but the raytracing example is totally irrelevant. The basics of raytracing were known a hundred years ago (and haven't really changed much since...). In contrast, in spite of a lot of research, noone has come very close to solving the inverse scattering problem.
This is a good point. However, for something like an ATM card, this probably would be no problem. The bank stores 1k speckle patterns from my token and uses them for the first thousand times I use it. Then (around the 900th time I use it) it tells me I need to go to the bank's ATM machine to get my card recharged. There the machine records another thousand speckle patterns at another thousand angles. Once this infrastructure was in place, this wouldn't necesarily be an inconvenience.
I think the correct term would be quasirandom. A quasirandom sequence is one that fills a space in a sort of random manner while observing some constraints. For example, when performing a monte carlo integration, you would rather avoid sampling data points that are very close, so a quasirandom sequence can give better convergence. On the other hand (in the case of the integration) you sacrifice the rigorous error estimation that is possible using true pseudorandom numbers.
I just read the article you linked, and am afraid the scientists quoted are a bit overoptimistic. They assume the space elevator will be built of nanotube composite materials which have not yet been invented, and then assumes that these (hypothetical) materials can be mass produced at very low cost.
We may indeed be able to make tons of nanotubes very soon, but we have yet to be able to make a macroscopic nanotube thread (say, the diameter of a human hair, and three centimeters long) of any size which is anywhere close to the strength of nylon.
I would guess that maybe you have a plugin or two installed (flash or acrobat plugin?). Once I removed those mozilla stopped crashing for me. Of course, now I am actually using galeon.
Just curious: what is reftex, and how does it relate to bibtex (which is what I use)?
That's the whole point (well, besides some custom software, I'm sure). Alpha smarts don't need to have lots of RAM or speed or color. They are about giving kids who've never used a computer the chance to type and edit their stories and essays.
Think of it not as a limited laptop, but an extra-functional-for-the-classroom desktop. A class set of desktop computers would be useless because there is no room for them all. One or two computers in a classroom have some use, but not much, since the class can't all use them. Besides, a real computer is too hard to use for the kids who would benefit most from them (those who've never used one before).
A class set of alpha smarts is wonderful. The kids (at least in inner city Oakland) love them. They can't mess them up, and they're really easy to use. Basically, each one holds maybe 8 text files, with one convenient button for each text file. I don't remember precisely. My sister is has a quarter class set (or something like that) and explained them to me once.