It's probably just referring to the separation of heavy water from normal water, which is then electrolyzed to produce the deuterium.
284 karma · joined April 30, 2009
While the disruptions in distribution mechanisms and increasing ease of deploying web-apps has provided the appearance of it being easy to launch your own business and make money, I'd argue that it might very well be a transitory period until bigger players with deeper pockets lock down profitable sectors.
I just can't see a long term steady-state where the market is spread so thinly that everyone can simultaneously be a business-owner serving some small collection of a few hundred customers, instead of aggregating into single, monolithic companies that serve thousands or millions.
I would assume that the US has very few of the ancient "enough fissile material to go critical trivially" sorts of bombs. The miniaturization of atomic weapons to fit into, among other things, ICBM warhead nose cones, likely came about by using smaller quantities of fissile material with much higher precision explosives, timings, and pit shapes to push that smaller nuclear pit into supercriticality. Instead of a soccer-ball of dozens of explosive lenses like the Fat Man, you've got maybe two or three lenses tops. Less moving parts, smaller overall bomb, but much much more timing sensitive.
So if tampering or failing the PAL blows out an EEPROM with the detonation timings on it, you've got a chunk of fissile material that's likely not enough by itself to construct a working nuclear bomb without 30-40 years of superpower-levels-of-funded R&D into materials sciences, precision machining of nasty stuff like beryllium, slapper detonators, so on and so forth.
Most of the gigantic TOP500 supercomputer clusters we've built over the years at national laboratories are likely used towards simulating whether the pits, even in their current configurations, are decaying in a reliable way that the weapons still function if needed. Reprocessing a single given pit into a new weapon is quite possibly an even harder problem.
Now, if you can steal a whole cache of nuclear weapons, then it gets a lot more feasible, since you can probably make one "easy" bomb out of a few hard ones, and either way you have nasty dirty-bomb potential, but I think if you had the capacity to build a working nuclear weapon out of a modern warhead, you probably already have them to begin with.
http://www.mtbs3d.com/phpBB/viewtopic.php?f=138&t=15086
It'll be great to actually get some hardware to play with.
Upscaling an intrinsically low-resolution image is still in the realm of creating information where there was none, I think.
The skill of a decent programmer is to decompose a large problem space into orthogonal components, so that each appears to be a small program that keeps you from being mentally entangled into the needs of the larger problem. Or even better, be sufficiently knowledgeable of the field to recognize when some of these orthogonal components already exist.
Once you've crossed the line where a component is "large", by the above definition, you've reached the point where future programmers will find it easier to insert new functionality ad-hoc wherever it seems to work, rather than attempt to understand the design and modify it appropriately. This design-by-accretion style can rapidly make a codebase unmaintainable.
I think if you look closely you can see the barest edge of a bucket behind the central part of the structure, where they'd drain the actual initial liquid. (You can see that the fluid seems to arrest before that transition in the video, as well.)
(1/p)((p)/(p+1))((p+1)/(p+2)) ... ((n-1)/n))
e.g. the fifth element's probability in an eight-element list is
1/5 * 5/6 * 6/7 *7/8
Since the numerator of each successive term cancels out the denominator of the last, the product is always 1/n.
This question seems ill-defined. Assuming you interpret "random" as "have an equal probability of returning any given element", then the probability is 1/infinite which is undefined.
I think there could be three possiblities:
A) The interviewer was baiting your friend into trying to elaborate the problem, in a "my client is asking me to do something absurd but I'll try to piece out his actual intent" sort of way. If so, you could come up with some hypothetical scenarios this algorithm would solve and show how actual problems would have actual bounds on how far the random window needs to go.
B) You could be remembering the problem wrong. It could be "Given a finite linked list whose length you don't know a priori..." instead. This is much more tractable as a stereotypical tech interview question.
C) Return the ninth element. http://dilbert.com/strips/comic/2001-10-25/
Changing the normal offered beverages from "Short", "Tall", and "Grande" to "Tall", "Grande", and "Venti" obtains the same effect as described in this post without being as overt about it. (On the face of it, "Grande" is an odd thing to call a medium beverage in the first place.)
Furthermore, I would guess the offset has even less entropy on average than the bitsequence you're hoping to compress, so if you had an algorithm that would shorten the expression of the offset you might very well be able to apply it to the original bitsequence with the same or better results.
I'd think an information theory expert could probably tackle these sorts of questions very rigorously, but I am not one so this is mostly conjecture.
Since "NPR" is defined as true if what follows it is never printed twice in succession, and "NPRNPR" is never printed as a given, then "NPRNPR" as a statement is true.