This is completely not true - before you make flames at other people, you may want to check your own information.
Isolated memory spaces, interrupt handling, etc. - those exist only in kernel space only if that's the only place where you want it, not because there's some compsci-theoretical reason that it "has" to be there. Embedded systems regularly have a poorly defined difference between "kernel mode" and "user mode". On x86 systems, it's clear because the system is usually set up to not be able to execute certain instructions unless it's in supervisory (ring 0) mode. On other systems, it's not necessarily true.
The library lack is also pointless if you're doing low level coding (yah... lacking printf might suck, but it's always nice knowing where the UART registers are!) where you honestly couldn't give a rat's ass about stdlib functions.
Your point is (somewhat) correct, if a bit naive, if only referring to modern PCs, with massively complex memory space and interfaces (how many different buses are hooked to a modern PC? 9? 10?) but on an embedded system, in general, coding in userspace and coding in kernelspace isn't that different.
The better point is what the hell is the difference between writing a device driver that sits inside an OS, and writing a portion of an OS that improves its performance? Or is SCO claiming that all device drivers belong to them as well?
How would you ever tell? You'd need, at -least-, a datalogger to record the temperature on a non-volatile medium (and one that could withstand pretty decent extremes of temperature) and then if it failed, you'd want to recreate the temperature conditions on Earth as well. You'd -probably- want to recreate the pressure conditions as well, so you probably want a datalogger that measures pressure and temperature, completely independent of the PC104 system, thermally coupled to it.
It's not like it's going to fall to Earth broken with a big sign saying what failed.
Granted, I think it'll probably be fine. But you don't design things expecting them to work - you design things expecting them to fail, and expecting to discover -how- they fail.
Is ISR actually planning a push to a space elevator? It looked more like they were interested in skyhook/power generation aspects of space tethers.
We'll see, in time, how things go. Right now ISR's resources aren't needed. Still need to do research - mainly on CNTs, but also on other things as well - and so you don't really only need researchers, so you really only need to give out money. NASA probably isn't so keen on giving money to organizations so they can give out money to other people.:)
Highlift did not go down the toilet. They existed to be an entity to receive money from NASA for the NIAC Phase 1 and Phase 2 grants. Those phases are over, and therefore Highlift has no reason to exist (it wasn't really a 'company' per se).
Contrary to what Slashdot has said, LiftPort (www.liftport.com/www.liftport.org) is not a competitor to Highlift - it was simply the natural next step (in Michael Laine's opinion - Brad Edwards thought that the time wasn't right for a public push yet) of moving from a government-funded research lab to a privately-funded company.
Incidentally, if you haven't been to www.liftport.com recently, they overhauled their website (it looks very good now) and are in an investment phase - they've already received over $1M in funding (not bad!). The "public" end, akin to Highlift, is going to be at www.liftport.org.
G/second is jerk. d^3 x/dt^3, da/dt. I wish there was a "-1, Idiot" in the moderating list. Look it up. Better yet, go look at "maximum stress hard drive" on google, and grab the first data sheet you see. What do you know! probably around 100 G/1 ms or so.
Frequency of accelerating force is definitely important, and amazingly enough, acceleration*frequency is, go fig, jerk.
You're not talking about the same acceleration for less time - you're talking about da/dt. How rapidly the acceleration changes, because you're talking about a force change. Going from applying 0 N to applying 10,000N in 1 step is much much harder on something than going in 1N steps of the same duration. You'll cause vibrations, etc. throughout the whole thing.
Naively, to a person who's only had basic kinematics, it might seem as if jerk doesn't have any bearing. However, in truth, it does, because of the oscillations through the body due to a near-step function in acceleration.
You don't want to just measure in G's - you want G/s, or G Hz. You want to know jerk, not acceleration (woo hoo, actually using jerk!).
If the 15 G's happens in a millisecond, sure, that's easy. If it happens over a second, again, no problem, but if it happens in a microsecond... that might be an issue.
IBM Travelstars, even non-operating, take 700 G/1ms. If the 15 Gs happened in 1 us, they'd bite it.
That being said, they could probably survive. But operating - I wouldn't trust it. The parachute deployment also probably is pretty severe.
Actually not - when it's not spinning, hard shock (depending on the frequency) can do bad things - shove the read head into the platter, yank the platter around, etc.
If you have a 10g burst acceleration that happens for a fraction of a second (say, less than a millisecond) some hard drives can toast from that. You can find ones which are rated to that, though, but you DO need to be careful. If it was a CF hard drive though (spinny), I doubt it'd take the shock of a full sized drive though. The internals are probably pretty cramped.
Actually, that's what I was commenting about. Flash storage that I've seen lists maximum operating altitude as 50K feet (the M-Systems IDE flash drives). That's almost definitely a "well, we can't guarantee it'll work!" because it's not like the chips are really pressure dependent.
Then there's the whole thermal design thing, which I didn't see anything regarding that in the paper... I wonder if they're just going to skip the thermal design portion, and just trust that it's a quick up-and-down, so there's not much worry.
2 things - first, they're not operating in the unlicensed mode - they're using a licensed Ham operator, so they can boost the power.
Second, they've got clear line of sight (um, unless they plan on launching the thing in the middle of the woods) so you don't lose any signal strength going through things, so you've only got 1/r^2 to deal with. It's a distance, hell yes, but a good enough antenna on both ends will do fine. The only problem with that is that only the ground has a pointable antenna, so here's hoping they've got plenty of link margin.
Heck, I'd worry about the CF card. I doubt it's a hard disk (of the spinny-type) as the paper states, as that'd crash on either liftoff or chute deployment. I'd bet it's a flash-type, just like a simple camera memory card. And then I'd wonder whether it'd survive too. Many of them have altitude restrictions (though I seriously doubt they're for real - it's probably a "don't use this in an airline design!" warning) as well. Remember to put some sort of retaining mechanism on the CF slot. Wouldn't want the card pulling out on liftoff, now would you.:)
Yipes. High-altitude, high stress stuff is always a pain (which is why aerospace companies make so much money designing things).
It'll definitely be cool to see if this works. The paper's a little light on details of the design (for certain things - like the actual construction or parts choices - for other things it seems pretty detailed).
And, if your light is bending due to the curvature of space, wouldn't your straight edge also curve? So, it would be difficult to determine space is curved from the perspective of the straight edge.
Nah. The straight edge is rigid, and kept rigid because of intermolecular forces. Light rays are not. So long as the intermolecular forces are stronger than the differential gravitational forces, it'll stay straight.
The curvature in spacetime would produce stress on the straight edge, but an 'ideal' (i.e. infinitely strong) straight edge would be just that - straight.
Gravitational lensing is a unique situation where you can refract light without a change in the index of refraction of materials.
For a better example, imagine this: Throw a rock perpendicular to the Earth's semimajor axis (i.e. along its orbital path). It won't go straight - that is, you set up a Cartesian coordinate system, and its motion won't be linear. It'll start going in a circle around the Sun. Throw it faster, and it'll go in a wider circle (or ellipse). Speed it up to the speed of light and it won't loop in a circle, but it will be distorted slightly.
Now imagine a very very long, infinitely strong pole, extended in the same direction. It won't curve. It'll just keep going straight. The fact that it isn't following the curvature of spacetime simply means there's a stress along it.
Anyway, you're right in most everyday applications. Some wacky quantum effects and (as stated) gravitational effects complicate the precise statement, but in general, refraction (bending of light) happens with a gradient in the index of refraction (be it a delta function or a smooth curve).
That's crazy. Ecosystems do NOT necessarily "adapt" to a more stable state, NOR to a better state. For an analogy, think of Genetic diversity is the real key to a stable ecosystem, because it increases the number of possibilities from mutation.
Take the Mediterranean Sea, for example. There's a really god awful variety of aquatic seaweed which was introduced there in early 90s (or late 80s). It's reproduced like wildfire, and is taking over a huge portion of the Mediterranean Sea bed. You might say that "ah, who cares, the ecosystem's adapting." Well, yes. It's adapting to a new lifeform which is killing everything else, reducing the biomass of the ecosystem, and the genetic diversity, because the new plant reproduces asexually. That is, the entire Mediterranean seabed is slowly becoming a mass of cloned seaweed, with only a tiny amount of genetic variation. Now, along comes a disease vector which infects the seaweed, and *poof* - all of it dies. No, not most of it - most likely ALL of it, because it's doubtful that the few genetic changes caused by random mutation rather than sexual reshuffling will allow it to survive a disease vector. Poof. Suddenly the entire Mediterranean is dead.
Yah. It'll regrow. In a long time. In the meantime, the Earth has a LOT less biomass producing a lot less oxygen. You are breathing because ecosystems work. Never forget that.
Ecosystems adapt, and evolve, sure. But nothing says that they have to return to their healthy state in a human lifespan. Nor does it say that it has to adapt and evolve to a stae in which humans can live.
Yah. Keep thinking it's dumb. You'll keep thinking it's dumb until countries start spending millions, then billions, then trillions trying to stabilize their ecosystems, and failing. First it'll be natural habitats. Then fisheries. Then farms. Then us.
It's not about being able to do simple math without a calculator. It's that it simply is NOT 3.333. It is 3.33333333... and depending on how accurate you need it, it will come back and bite you later.
If you take a 10 cm ruler and divide it in thirds, you get a 3.333333... cm ruler. You can make a GUESS at that, but the best you can repeatably do is determined by the gradation on the ruler, so probably 3.3 cm. Now make 12 bricks that are 3.3 cm cm long, that you wanted to be 1/3 of your 10 cm length, and stack them together, end to end. You wanted it to be 40 cm long. It's not. It's 38.8 cm long. If it were a woodworking project, it simply would not work.
Compare that to an imperial system, with base 12, which can be evenly divided in 2, 3, and 4. There, the gradation on the ruler is exactly what you want, and you can make the bricks extraordinarily accurate, if you're careful, and it WILL work.
I'm not saying that the metric system wouldn't work in this case. Of course it would. You'd just have to be MUCH more careful, or find other ways of doing it. It's just that that system based on base 12 makes it easier right from the beginning.
Personally, I don't see what the heck's so hard about having both metric and imperial around. It's not THAT difficult, and both of them are useful (though to be honest, metric's more of a pain. You can't buy ANY specialty metric screws quickly - not here, not anywhere. It's a disaster...). Most of us in engineering and the sciences don't have that much problem with it, and those that do (see also NASA) need to work on "internal standards" a little better.:)
I doubt they'd do that. First off, those two execution paths don't even do the same thing! One is
c = a+b e = c*d
or e = (a+b)*c
and the second one is
c = a+b e = d*f
which of course can be executed in parallel. In any case, the final result (e) is not the same between the two, unless you stuck a (c=f) in there somewhere.
These are GPUs, not x86 processors - they likely have an absolute ton of registers, so it's trivially easy to do
c = b+a instead of c = a+b
which looks like a different instruction (if you had a three operand instruction, which I don't know that they do...) even though it does the same thing. You're just trying to fool the CRC. You don't have to work that hard.
No. Because you lose information there, and it's NOT always possible to do this, nor is it easy. What if you have 50 PDF files? OK, click the first one... great. Now... scroll down to find the last one.. damn, not yet, not yet, not yet, ah, there it is, shift click, wait five minutes for the graphical update... oh wait, can't just drag to the folder as the folder has to be in the VIEW of the window. Might as well click edit, go to copy, scroll down to the folder, enter the folder, click paste.
There's about twenty extra clicks there. Plus you're not counting the extra clicks to restore the previous sorting.
It is nowhere NEAR as easy to move many things in a GUI as it is from a commandline, and that's probably the most used feature when moving files around. "I want all of these, there."
Um. Yes. I never disputed that. However, you're making it sound random as to which is heavier. In fact, it's NOT possible for Pb-208 to be the heavier of the two, considering the fact that Bi-208 has one more proton than Pb-208. The (residual) nuclear strong force has isospin symmetry due to the approximate chiral symmetry, which means that the strong binding force is equivalent between 208 protons, 208 neutrons, and any internal combination thereof.
The electric repulsive force, however, is clearly greater with Bi-208 than Pb-208, because Bi-208 has an extra charge +1 in its nucleus, therefore, it must be less bound.
and since the second term is strictly greater than zero, the binding is less for V_Bi (more bound = more negative, less bound = less negative = more positive).
Obviously Tl-208 is going to weigh less, and Po-208 is going to weigh more.
Not really. He's talking about energy that's 'borrowed' from the vacuum. A different way of saying it is that the energy that a particle possesses isn't really an 'exact' quantity, but a distribution, and a small fraction of the time it's going to be actually have enough energy to leap the gap. Gaussians distributions are nice that way...
Hawking radiation is where you're borrowing energy from the black hole, not the vaccuum. That's why you can 'keep' it - because it's actually just a very slow reaction of a black hole with the vaccuum.
Not true - this is what's told to people a lot of times in basic science classes, but it's wrong. A neutron is not a bound state of a proton and an electron. It's a bound state of two d quarks and a u quark. Inverse beta decay (electron capture) happens when an electron emits a virtual W-, turning into an electron neutrino, and the virtual W- interacts with the u quark in the proton, turning it into a d quark.
So the proper answer is, a neutron weighs more than a proton, because a neutron is mass of proton plus the mass difference between a u and d quark, and the binding energy difference between the uud and the udd combination. The mass of an electron doesn't enter into it at all (at least, in the standard model. It might in other theories).
The main reason this is true is because a neutron isn't a bound state - it isn't stable. It decays when absolutely nothing overcomes its binding energy into a proton, an electron, and an electron antineutrino.
Er? GUI file managers are nice, but efficiency really comes with commandline tools if you're scatterbrained like me. Want to create a new folder with all of the PDFs in one directory? No problem: mkdir pdf; mv *.pdf pdf, and you're done. The number of clicks that it takes to do that in a GUI file manager is really insane. In Windows I'd bring up a commandline interface in a heartbeat to do something like that.
Half the problem with Windows is the fact that the file management development really has only been on the GUI side. Cygwin's the first thing I install when I get a new Windows machine, and THAT makes it usable.
Less than 8%. It was 8% in one benchmark, and ~0 in all others, which ended up being 1.9%. ATI's probably fudging the pixel/vertex shader programs in Game 4. The same behavior wasn't seen with NVIDIA, which makes it very unlikely that FutureMark's changes did anything. In addition, the changes were meaningless ones (removing a splash screen, switching registers around, etc.) which do nothing except change the exact bits of the program.
With NVIDIA, it was about 25% lower overall, which I don't believe they spelled out in terms of per-game change, but it's a LOT of driver cheating. A lot more than ATI's, in any case.
Well, true and false. It's difficult to find out any info whether or not natural infertility is higher in developing countries or in third-world countries, and naively you'd expect it to be better in first-world because of nutrition, though this isn't a guarantee.
Age-induced infertility problems are MUCH more common in first world than in third world, because in third-world countries children are born much earlier than first-world (people don't wait as long).
Oddly, even though the original idea was wrong, the argument is still valid. There's no reason to believe that this condition will continue. It's not clear that age-related fecundity drops are fundamental.
Let's put it this way. It's difficult to gauge exactly how much of a concern this is, but there's two mitigating factors here. How much parents want to have children, and how able they are to have them. It's reasonable to believe that how much parents want children is pretty much biological, so the drop is most likely related to lack of ability (age-related drops). If medical science is able to treat that, there's really no reason to believe that the population wouldn't start growing again.
You ignore a large number of countries in Europe and Japan whose birth rates have dropped so perilously low they are in danger of losing population. Eastern European countries' fertility rates, while higher than those of Western Europe, dropped dramatically after the fall of the Soviet Union, a totalitarian government. The female literacy rate correlates better than the type of government with low growth rates.
Actually, that's an interesting point, because you used "fertility rates", rather than "birth rates", which is very true - there are a -lot- of infertile people in first world countries. Note that there's no reason to assume that this will extend to other countries, like China, India, and Africa, nor is it reason to assume that it will be identical in all ethnic groups, as the birth rate drop is distinctly not uniform across the US.
Bottom line is that I wouldn't claim that first world countries naturally head towards stable populations. That's a little too optimistic, and we have far too few data points and far too many mitigating factors. This is why a lot of the population studies that predict we'll be at X population globally are not that good, because predictions that the birth rate for populations will continue on their current trends are naive at best.
That's not entirely correct, either. He's talking about "bank interleaving" -- multiple banks on the same module all communicate through a single bus, so there's no benefit to having two banks read at the same time, as only one can return the data.
Normal RAID works this way too. There's only one SCSI/IDE bus, so they can't read at the same time, because only one can return the data.
Here's how you get a benefit:
(Memory here has a latency of 2 clock cycles)
1: Controller issues Read A to Chip A - Chip A begins fetching data.
2: Controller issues Read B to Chip B - Chip B begins fetching data
3: Chip A presents data
4: Chip B presents data
This is interleaved reading. Serial reading would be
1: Controller issues Read A to Chip A
2: Controller waits, knowing Chip A is busy
3: Chip A presents data
4: Controller issues Read B to Chip A
5: Controller waits
6: Chip A presents data
The above interleaved read saved 2 clock cycles - the read latency - because it issued two reads to two chips.
The above example could be substituted for RAID by replacing "Chip" with "Drive", and of course, increasing the latency by about 10,000. There's only one SCSI bus - only one set of data lines - so each SCSI clock, only one drive can return data on the bus. RAID helps because the latency for returning data is (much) larger than the SCSI clock, so scattered accesses get latency benefits. It also doesn't help a ton because you don't read single bytes from drives that often, and so the latency benefit is offset by the fact that the bus is constantly busy.
Basically, if the bus cycle time is much much less than the access latency (i.e. if the number of wait states is much much greater than 1), you'll win out with interleaving if your access pattern is pretty staggered. In any case, you will rarely lose out.
Definitely correct. Plus some of the other definitions were a little off (interleaving is essentially RAID for memory: it gets benefits because multiple devices can respond in parallel, rather than in series, so the latency penalty isn't incurred twice).
What makes this terrible is the fact that there are latency measuring tools out there, lmbench specifically. It really wouldn't take that long to measure both latency and bandwidth.
Considering the fact that this definitely would be interesting, it's a little annoying that he didn't do that.
There are much more intensive memory benchmarks than Sandra. That's why it's a little annoying that Sandra's become so popular. There are other, easy to automate benchmarks that do a much better job. Sandra's useful, but not for this kind of thing.
Slashdot Mirror
This is completely not true - before you make flames at other people, you may want to check your own information.
Isolated memory spaces, interrupt handling, etc. - those exist only in kernel space only if that's the only place where you want it, not because there's some compsci-theoretical reason that it "has" to be there. Embedded systems regularly have a poorly defined difference between "kernel mode" and "user mode". On x86 systems, it's clear because the system is usually set up to not be able to execute certain instructions unless it's in supervisory (ring 0) mode. On other systems, it's not necessarily true.
The library lack is also pointless if you're doing low level coding (yah... lacking printf might suck, but it's always nice knowing where the UART registers are!) where you honestly couldn't give a rat's ass about stdlib functions.
Your point is (somewhat) correct, if a bit naive, if only referring to modern PCs, with massively complex memory space and interfaces (how many different buses are hooked to a modern PC? 9? 10?) but on an embedded system, in general, coding in userspace and coding in kernelspace isn't that different.
The better point is what the hell is the difference between writing a device driver that sits inside an OS, and writing a portion of an OS that improves its performance? Or is SCO claiming that all device drivers belong to them as well?
How would you ever tell? You'd need, at -least-, a datalogger to record the temperature on a non-volatile medium (and one that could withstand pretty decent extremes of temperature) and then if it failed, you'd want to recreate the temperature conditions on Earth as well. You'd -probably- want to recreate the pressure conditions as well, so you probably want a datalogger that measures pressure and temperature, completely independent of the PC104 system, thermally coupled to it.
It's not like it's going to fall to Earth broken with a big sign saying what failed.
Granted, I think it'll probably be fine. But you don't design things expecting them to work - you design things expecting them to fail, and expecting to discover -how- they fail.
Is ISR actually planning a push to a space elevator? It looked more like they were interested in skyhook/power generation aspects of space tethers.
:)
We'll see, in time, how things go. Right now ISR's resources aren't needed. Still need to do research - mainly on CNTs, but also on other things as well - and so you don't really only need researchers, so you really only need to give out money. NASA probably isn't so keen on giving money to organizations so they can give out money to other people.
Highlift did not go down the toilet. They existed to be an entity to receive money from NASA for the NIAC Phase 1 and Phase 2 grants. Those phases are over, and therefore Highlift has no reason to exist (it wasn't really a 'company' per se).
Contrary to what Slashdot has said, LiftPort (www.liftport.com/www.liftport.org) is not a competitor to Highlift - it was simply the natural next step (in Michael Laine's opinion - Brad Edwards thought that the time wasn't right for a public push yet) of moving from a government-funded research lab to a privately-funded company.
Incidentally, if you haven't been to www.liftport.com recently, they overhauled their website (it looks very good now) and are in an investment phase - they've already received over $1M in funding (not bad!). The "public" end, akin to Highlift, is going to be at www.liftport.org.
G/second is jerk. d^3 x/dt^3, da/dt. I wish there was a "-1, Idiot" in the moderating list. Look it up. Better yet, go look at "maximum stress hard drive" on google, and grab the first data sheet you see. What do you know! probably around 100 G/1 ms or so.
Frequency of accelerating force is definitely important, and amazingly enough, acceleration*frequency is, go fig, jerk.
You're not talking about the same acceleration for less time - you're talking about da/dt. How rapidly the acceleration changes, because you're talking about a force change. Going from applying 0 N to applying 10,000N in 1 step is much much harder on something than going in 1N steps of the same duration. You'll cause vibrations, etc. throughout the whole thing.
Naively, to a person who's only had basic kinematics, it might seem as if jerk doesn't have any bearing. However, in truth, it does, because of the oscillations through the body due to a near-step function in acceleration.
You don't want to just measure in G's - you want G/s, or G Hz. You want to know jerk, not acceleration (woo hoo, actually using jerk!).
If the 15 G's happens in a millisecond, sure, that's easy. If it happens over a second, again, no problem, but if it happens in a microsecond... that might be an issue.
IBM Travelstars, even non-operating, take 700 G/1ms. If the 15 Gs happened in 1 us, they'd bite it.
That being said, they could probably survive. But operating - I wouldn't trust it. The parachute deployment also probably is pretty severe.
Actually not - when it's not spinning, hard shock (depending on the frequency) can do bad things - shove the read head into the platter, yank the platter around, etc.
If you have a 10g burst acceleration that happens for a fraction of a second (say, less than a millisecond) some hard drives can toast from that. You can find ones which are rated to that, though, but you DO need to be careful. If it was a CF hard drive though (spinny), I doubt it'd take the shock of a full sized drive though. The internals are probably pretty cramped.
Actually, that's what I was commenting about. Flash storage that I've seen lists maximum operating altitude as 50K feet (the M-Systems IDE flash drives). That's almost definitely a "well, we can't guarantee it'll work!" because it's not like the chips are really pressure dependent.
Then there's the whole thermal design thing, which I didn't see anything regarding that in the paper... I wonder if they're just going to skip the thermal design portion, and just trust that it's a quick up-and-down, so there's not much worry.
2 things - first, they're not operating in the unlicensed mode - they're using a licensed Ham operator, so they can boost the power.
Second, they've got clear line of sight (um, unless they plan on launching the thing in the middle of the woods) so you don't lose any signal strength going through things, so you've only got 1/r^2 to deal with. It's a distance, hell yes, but a good enough antenna on both ends will do fine. The only problem with that is that only the ground has a pointable antenna, so here's hoping they've got plenty of link margin.
Heck, I'd worry about the CF card. I doubt it's a hard disk (of the spinny-type) as the paper states, as that'd crash on either liftoff or chute deployment. I'd bet it's a flash-type, just like a simple camera memory card. And then I'd wonder whether it'd survive too. Many of them have altitude restrictions (though I seriously doubt they're for real - it's probably a "don't use this in an airline design!" warning) as well. Remember to put some sort of retaining mechanism on the CF slot. Wouldn't want the card pulling out on liftoff, now would you. :)
Yipes. High-altitude, high stress stuff is always a pain (which is why aerospace companies make so much money designing things).
It'll definitely be cool to see if this works. The paper's a little light on details of the design (for certain things - like the actual construction or parts choices - for other things it seems pretty detailed).
And, if your light is bending due to the curvature of space, wouldn't your straight edge also curve? So, it would be difficult to determine space is curved from the perspective of the straight edge.
Nah. The straight edge is rigid, and kept rigid because of intermolecular forces. Light rays are not. So long as the intermolecular forces are stronger than the differential gravitational forces, it'll stay straight.
The curvature in spacetime would produce stress on the straight edge, but an 'ideal' (i.e. infinitely strong) straight edge would be just that - straight.
Gravitational lensing is a unique situation where you can refract light without a change in the index of refraction of materials.
For a better example, imagine this: Throw a rock perpendicular to the Earth's semimajor axis (i.e. along its orbital path). It won't go straight - that is, you set up a Cartesian coordinate system, and its motion won't be linear. It'll start going in a circle around the Sun. Throw it faster, and it'll go in a wider circle (or ellipse). Speed it up to the speed of light and it won't loop in a circle, but it will be distorted slightly.
Now imagine a very very long, infinitely strong pole, extended in the same direction. It won't curve. It'll just keep going straight. The fact that it isn't following the curvature of spacetime simply means there's a stress along it.
Anyway, you're right in most everyday applications. Some wacky quantum effects and (as stated) gravitational effects complicate the precise statement, but in general, refraction (bending of light) happens with a gradient in the index of refraction (be it a delta function or a smooth curve).
That's crazy. Ecosystems do NOT necessarily "adapt" to a more stable state, NOR to a better state. For an analogy, think of Genetic diversity is the real key to a stable ecosystem, because it increases the number of possibilities from mutation.
Take the Mediterranean Sea, for example. There's a really god awful variety of aquatic seaweed which was introduced there in early 90s (or late 80s). It's reproduced like wildfire, and is taking over a huge portion of the Mediterranean Sea bed. You might say that "ah, who cares, the ecosystem's adapting." Well, yes. It's adapting to a new lifeform which is killing everything else, reducing the biomass of the ecosystem, and the genetic diversity, because the new plant reproduces asexually. That is, the entire Mediterranean seabed is slowly becoming a mass of cloned seaweed, with only a tiny amount of genetic variation. Now, along comes a disease vector which infects the seaweed, and *poof* - all of it dies. No, not most of it - most likely ALL of it, because it's doubtful that the few genetic changes caused by random mutation rather than sexual reshuffling will allow it to survive a disease vector. Poof. Suddenly the entire Mediterranean is dead.
Yah. It'll regrow. In a long time. In the meantime, the Earth has a LOT less biomass producing a lot less oxygen. You are breathing because ecosystems work. Never forget that.
Ecosystems adapt, and evolve, sure. But nothing says that they have to return to their healthy state in a human lifespan. Nor does it say that it has to adapt and evolve to a stae in which humans can live.
Yah. Keep thinking it's dumb. You'll keep thinking it's dumb until countries start spending millions, then billions, then trillions trying to stabilize their ecosystems, and failing. First it'll be natural habitats. Then fisheries. Then farms. Then us.
Ack, bad math alert.
3.3*12 = 39.6, not 38.8. The rounding error is 0.1 per 10 cm, not 0.1 per brick. Whoops...
Oh well, the point is still valid, even if the math isn't. Serves me right for not previewing...
It's not about being able to do simple math without a calculator. It's that it simply is NOT 3.333. It is 3.33333333... and depending on how accurate you need it, it will come back and bite you later.
:)
If you take a 10 cm ruler and divide it in thirds, you get a 3.333333... cm ruler. You can make a GUESS at that, but the best you can repeatably do is determined by the gradation on the ruler, so probably 3.3 cm. Now make 12 bricks that are 3.3 cm cm long, that you wanted to be 1/3 of your 10 cm length, and stack them together, end to end. You wanted it to be 40 cm long. It's not. It's 38.8 cm long. If it were a woodworking project, it simply would not work.
Compare that to an imperial system, with base 12, which can be evenly divided in 2, 3, and 4. There, the gradation on the ruler is exactly what you want, and you can make the bricks extraordinarily accurate, if you're careful, and it WILL work.
I'm not saying that the metric system wouldn't work in this case. Of course it would. You'd just have to be MUCH more careful, or find other ways of doing it. It's just that that system based on base 12 makes it easier right from the beginning.
Personally, I don't see what the heck's so hard about having both metric and imperial around. It's not THAT difficult, and both of them are useful (though to be honest, metric's more of a pain. You can't buy ANY specialty metric screws quickly - not here, not anywhere. It's a disaster...). Most of us in engineering and the sciences don't have that much problem with it, and those that do (see also NASA) need to work on "internal standards" a little better.
I doubt they'd do that. First off, those two execution paths don't even do the same thing! One is
c = a+b
e = c*d
or e = (a+b)*c
and the second one is
c = a+b
e = d*f
which of course can be executed in parallel. In any case, the final result (e) is not the same between the two, unless you stuck a (c=f) in there somewhere.
These are GPUs, not x86 processors - they likely have an absolute ton of registers, so it's trivially easy to do
c = b+a
instead of
c = a+b
which looks like a different instruction (if you had a three operand instruction, which I don't know that they do...) even though it does the same thing. You're just trying to fool the CRC. You don't have to work that hard.
No. Because you lose information there, and it's NOT always possible to do this, nor is it easy. What if you have 50 PDF files? OK, click the first one... great. Now... scroll down to find the last one.. damn, not yet, not yet, not yet, ah, there it is, shift click, wait five minutes for the graphical update... oh wait, can't just drag to the folder as the folder has to be in the VIEW of the window. Might as well click edit, go to copy, scroll down to the folder, enter the folder, click paste.
There's about twenty extra clicks there. Plus you're not counting the extra clicks to restore the previous sorting.
It is nowhere NEAR as easy to move many things in a GUI as it is from a commandline, and that's probably the most used feature when moving files around. "I want all of these, there."
Um. Yes. I never disputed that. However, you're making it sound random as to which is heavier. In fact, it's NOT possible for Pb-208 to be the heavier of the two, considering the fact that Bi-208 has one more proton than Pb-208. The (residual) nuclear strong force has isospin symmetry due to the approximate chiral symmetry, which means that the strong binding force is equivalent between 208 protons, 208 neutrons, and any internal combination thereof.
The electric repulsive force, however, is clearly greater with Bi-208 than Pb-208, because Bi-208 has an extra charge +1 in its nucleus, therefore, it must be less bound.
In other words:
Pb-208: V_Pb = F_em(82 protons) - F_s(208 hadrons)
Bi-208: V_Bi = F_em(82 protons)*(83^2)/(82^2) - F_s(208 hadrons)
Obviously V_Bi = V_Pb + F_em(82 protons)*(83^2/82^2 - 1)
and since the second term is strictly greater than zero, the binding is less for V_Bi (more bound = more negative, less bound = less negative = more positive).
Obviously Tl-208 is going to weigh less, and Po-208 is going to weigh more.
Not really. He's talking about energy that's 'borrowed' from the vacuum. A different way of saying it is that the energy that a particle possesses isn't really an 'exact' quantity, but a distribution, and a small fraction of the time it's going to be actually have enough energy to leap the gap. Gaussians distributions are nice that way...
Hawking radiation is where you're borrowing energy from the black hole, not the vaccuum. That's why you can 'keep' it - because it's actually just a very slow reaction of a black hole with the vaccuum.
Not true - this is what's told to people a lot of times in basic science classes, but it's wrong. A neutron is not a bound state of a proton and an electron. It's a bound state of two d quarks and a u quark. Inverse beta decay (electron capture) happens when an electron emits a virtual W-, turning into an electron neutrino, and the virtual W- interacts with the u quark in the proton, turning it into a d quark.
So the proper answer is, a neutron weighs more than a proton, because a neutron is mass of proton plus the mass difference between a u and d quark, and the binding energy difference between the uud and the udd combination. The mass of an electron doesn't enter into it at all (at least, in the standard model. It might in other theories).
The main reason this is true is because a neutron isn't a bound state - it isn't stable. It decays when absolutely nothing overcomes its binding energy into a proton, an electron, and an electron antineutrino.
Er? GUI file managers are nice, but efficiency really comes with commandline tools if you're scatterbrained like me. Want to create a new folder with all of the PDFs in one directory? No problem: mkdir pdf; mv *.pdf pdf, and you're done. The number of clicks that it takes to do that in a GUI file manager is really insane. In Windows I'd bring up a commandline interface in a heartbeat to do something like that.
Half the problem with Windows is the fact that the file management development really has only been on the GUI side. Cygwin's the first thing I install when I get a new Windows machine, and THAT makes it usable.
Less than 8%. It was 8% in one benchmark, and ~0 in all others, which ended up being 1.9%. ATI's probably fudging the pixel/vertex shader programs in Game 4. The same behavior wasn't seen with NVIDIA, which makes it very unlikely that FutureMark's changes did anything. In addition, the changes were meaningless ones (removing a splash screen, switching registers around, etc.) which do nothing except change the exact bits of the program.
With NVIDIA, it was about 25% lower overall, which I don't believe they spelled out in terms of per-game change, but it's a LOT of driver cheating. A lot more than ATI's, in any case.
Well, true and false. It's difficult to find out any info whether or not natural infertility is higher in developing countries or in third-world countries, and naively you'd expect it to be better in first-world because of nutrition, though this isn't a guarantee.
Age-induced infertility problems are MUCH more common in first world than in third world, because in third-world countries children are born much earlier than first-world (people don't wait as long).
Oddly, even though the original idea was wrong, the argument is still valid. There's no reason to believe that this condition will continue. It's not clear that age-related fecundity drops are fundamental.
Let's put it this way. It's difficult to gauge exactly how much of a concern this is, but there's two mitigating factors here. How much parents want to have children, and how able they are to have them. It's reasonable to believe that how much parents want children is pretty much biological, so the drop is most likely related to lack of ability (age-related drops). If medical science is able to treat that, there's really no reason to believe that the population wouldn't start growing again.
You ignore a large number of countries in Europe and Japan whose birth rates have dropped so perilously low they are in danger of losing population. Eastern European countries' fertility rates, while higher than those of Western Europe, dropped dramatically after the fall of the Soviet Union, a totalitarian government. The female literacy rate correlates better than the type of government with low growth rates.
Actually, that's an interesting point, because you used "fertility rates", rather than "birth rates", which is very true - there are a -lot- of infertile people in first world countries. Note that there's no reason to assume that this will extend to other countries, like China, India, and Africa, nor is it reason to assume that it will be identical in all ethnic groups, as the birth rate drop is distinctly not uniform across the US.
Bottom line is that I wouldn't claim that first world countries naturally head towards stable populations. That's a little too optimistic, and we have far too few data points and far too many mitigating factors. This is why a lot of the population studies that predict we'll be at X population globally are not that good, because predictions that the birth rate for populations will continue on their current trends are naive at best.
That's not entirely correct, either. He's talking about "bank interleaving" -- multiple banks on the same module all communicate through a single bus, so there's no benefit to having two banks read at the same time, as only one can return the data.
Normal RAID works this way too. There's only one SCSI/IDE bus, so they can't read at the same time, because only one can return the data.
Here's how you get a benefit:
(Memory here has a latency of 2 clock cycles)
1: Controller issues Read A to Chip A - Chip A begins fetching data.
2: Controller issues Read B to Chip B - Chip B begins fetching data
3: Chip A presents data
4: Chip B presents data
This is interleaved reading. Serial reading would be
1: Controller issues Read A to Chip A
2: Controller waits, knowing Chip A is busy
3: Chip A presents data
4: Controller issues Read B to Chip A
5: Controller waits
6: Chip A presents data
The above interleaved read saved 2 clock cycles - the read latency - because it issued two reads to two chips.
The above example could be substituted for RAID by replacing "Chip" with "Drive", and of course, increasing the latency by about 10,000. There's only one SCSI bus - only one set of data lines - so each SCSI clock, only one drive can return data on the bus. RAID helps because the latency for returning data is (much) larger than the SCSI clock, so scattered accesses get latency benefits. It also doesn't help a ton because you don't read single bytes from drives that often, and so the latency benefit is offset by the fact that the bus is constantly busy.
See here, , or here for more info.
Basically, if the bus cycle time is much much less than the access latency (i.e. if the number of wait states is much much greater than 1), you'll win out with interleaving if your access pattern is pretty staggered. In any case, you will rarely lose out.
Definitely correct. Plus some of the other definitions were a little off (interleaving is essentially RAID for memory: it gets benefits because multiple devices can respond in parallel, rather than in series, so the latency penalty isn't incurred twice).
What makes this terrible is the fact that there are latency measuring tools out there, lmbench specifically. It really wouldn't take that long to measure both latency and bandwidth.
Considering the fact that this definitely would be interesting, it's a little annoying that he didn't do that.
There are much more intensive memory benchmarks than Sandra. That's why it's a little annoying that Sandra's become so popular. There are other, easy to automate benchmarks that do a much better job. Sandra's useful, but not for this kind of thing.
Just plain useless.