China is already selling to everyone willing to buy. There is no missing demand in the global system, no extra waiting to pick up the slack if another region falters. There is no place that China told "nope, we're busy, wait in line." That's what globalization is, and that's why recessions lately end up going global.
You'll get the "how do I hack?" "how do I make games?" questions no matter what. But if you do the talk about right, those will be flippant jokes rather than serious questions.
Basically you need to open with your way of saying "everything you've seen on TV or in movies is wrong. There are no falling columns of Matrix code controlling everything, and there is no 'hacking' by flying through 3D cities or typing for 30 seconds. World of Warcraft took sixty million dollars and three years to build. Whoever fried Iran's uranium centrifuges, wink wink, took years of planning."
You don't really have time to go in depth, nor do they have the background for you to show them actual code. So don't worry about those. The key is to pick examples that they'll already be at least a little familiar with and that you're comfortable with, and realistically de-magic those examples a bit.
I'd recommend two flavors of examples before you open for questions. The first one is based around "this is what I do in real life". You can very easily tie your database stuff to, well, every big popular site the students have ever used. Facebook, Google search and maps, any webmail, ebay, Amazon, itunes, 4chan, Slashdot, and so on. All of that is based on gathering, sorting, storing, and searching through vast amounts of information. You can do the old dictionary example - use a physical dictionary, solicit a word from the crowd, and then look it up quickly right in front of them. Then point out how it'd take all day if you had to read every line in order from the front or the back. Then point out that Google's database printed out as dictionaries wouldn't fit in the entire internal volume of the school - floor to ceiling, wall to wall, all the rooms and hallways and the cafeteria and gym and auditorium and so on - and yet Google needs to do millions of lookups per second. All that is math. Not Einstein's rocket ship time machine math, but stuff not much harder than what they'll see next year in Precalculus. But without the math, it's like the warehouse at the end of Indiana Jones, where cool things go to die (because no one can ever find them again).
The second one would be any common-but-hard problem in games. Something like pathing AI. You don't need to have actually written those programs; the idea is that you can explain it's too complex to calculate every possible path and pick the best one. The gamers in the crowd will grasp this fairly well, because they've all seen games where the pathing sucked, or where the third person viewpoint kept blocking them, or where the AI enemies seemed to cheat, or where the interface was poorly designed and you could never find what you needed in its maze of nested sub-menus. Again, it's all math. But it's hard-but-interesting math. The computer can do the calculations, but you need to know what its limits are, what calculations need to be done to do the work you want, and how to tell the computer to do those. You cannot say "computer, make me a sandwich"; you've got to write it a cookbook first.
> hyper accelerate us at higher than gravitational effect of earth > 2G acceleration
I don't know why you think we need these things. Assuming for the moment that getting to a cruising speed of 90% of lightspeed is practical and desirable, time dilation cuts the cruise part of the trip in half for the crew. But even rounding down, the nearest star is 4 light years away, so even if we had instant acceleration and deceleration, it would still take more than 2 years to get there (crew's point of view. Obviously viewed from earth it'd still take them over 4 years).
Doing the acceleration and deceleration phases at 2G instead of 1G would cut the time needed for those parts in half, but there really isn't much benefit to it. (Checking the math on another site, it only actually saves you a bit over a year). But since the ship already needs to take a couple years to get there, a couple years to get back, and would presumably spend a couple years exploring the other system... cutting two years off the round trip actually doesn't matter much. Either way, you have to have solved the crew's life support issues with heavy recycling. And if you've solved the life support issue, then if a 2G mission is viable timewise, then so is a 1G mission. Likewise, even if you can aim for a higher cruising speed (for even better time dilation), whether you're at 1G or 2G, you're going to be spending years accelerating and decelerating.
And that is enough, by itself, for humanity to outright take over the entire galaxy. Because although the galaxy is 100,000 light years wide and 10,000 light years thick, you only have to go from one star to the next. That means you can do it in easy hops of 3-10 light years at a time.
I don't mean to say that 3-10 light years is easy, just that we don't need more than 1G acceleration to do it. We do need better tech than we have right this moment - I left all of that out of the post to keep it down to reasonable length - but we don't need magical warp drives. Also, that other thread from a day or two ago - about average healthy lifespan hitting 150 years - would certainly also help.
Well, with a few more digits of pi, you could get the error down to some arbitrarily small fraction of one Planck length. Then you're well below the absolute hard limit of measurability, and therefore the circle really would be perfect.
Hmm. A bit of googling, and someone else has already done the calculations. Apparently that only requires 61 digits of pi.
That's only the visible universe, though. You might want a few more digits, just to be sure. You're still not going to need ten trillion digits, though. Probably not even a hundred digits.
You'd be able to see Imaginary Colors . Note the graph in the top right; normally, two or three cones are reacting to the same wavelength, and our brain does some interpretation afterwards.
So, for example, if red and blue cones were shut off, you'd only be able to see green (and, well, also the monochrome from rods). Impossibly pure green at the peak, and duller green at the extremes. And any two wavelengths with the same y value on the green curve of that graph? Those two colors would look identical to you. That means it'd be possible to make a red and blue checkerboard pattern that looks like uniform green to you.
Or it could be that demand has grown fast enough to keep pace with growth in supply. This does happen naturally sometimes. The smartphone market has been growing for that entire time, the amount of flash in each phone is been going up, there's also the tablet market and the ebook reader market, the digital camera market, solid state drives for all those Macbook Airs, and so on. This can keep prices high without monopoly or collusion. If the manufacturers know they're guaranteed to sell everything they make at the current price, then it doesn't benefit them to lower their prices.
If flash fabs didn't cost tens of billions of dollars to make, then yes, we might still be able to argue that manufacturers were colluding to limit production to keep prices high. But due to the expense, they've got a pretty good argument that building new fabs is too risky. Especially since we're bumping up against the reliability limits of flash now; they can't just double density again.
This is where HP hopes to swoop in with memristor tech and save the day / get rich. They're claiming their test runs are already competitive with flash performance and with better reliability, and that the tech is no where near its limits yet. Theoretically, as soon as they start putting this into production, they'll start grabbing the high end market share, and either the price of flash with crash in response (the fabs are about paid off already, so they have a lot of flexibilty to lower prices) or everyone will license from HP and make memristors.
Banks don't have all the money on hand because it is invested (loaned out). In the long run and on average, the loans are repaid with interest. A bank can and does operate this way indefinitely. It's also regulated as to what percentage of the accounts does have to be on hand, and it's also federally insured up to a certain amount per account. The money lent out isn't gone off of the face of the earth; it exists as debt that someone owes back to the bank.
Ponzi schemes don't have all the money on hand because it doesn't all even exist. That's a key, defining feature of the scheme: that some portion of the stated assets are fictitious. The owner of the scheme has been taking some of the money for himself instead and lying about the returns from the investments (which never happened). Payouts to other investors are only to perpetuate the illusion that the whole thing is as profitable as claimed.
The Poker thing much more closely matches the Ponzi scheme, not the bank. For starters, the players' balances were never supposed to be invested or loaned out. (Consider how the poker game works: people play against each other and the house collects its cut no matter who wins. All money involved would normally be immediately on hand because the total amount never changed, only how much of it belongs to who). The money was not there because the company owners took it! Gone from the company completely, not invested and not living on as debt owed back to the company.
They were only able to do this for so long because it was operated online; in a normal casino, every player is cashing out their chips on their way out, but on the internet they had virtual chips to leave in their digital account for the next time they played. Thus the owners could spend most of the actual underlying money, and as long as enough new players were putting money into their accounts, the few players that wanted to make withdrawals could be paid out of that new money. You know, just like in a Ponzi scheme.
I'd think this doesn't actually eliminate trial and error. Consider:
Step 1: algorithm suggests what to try first
Step 2a: we also try small variants of everything from step 1
Step 2b: we play around with everything from step 1 and step 2a that wasn't what we wanted, to see if it has other uses.
So unless the algorithm is so good that the first try is always what we were looking for, we'll still end up doing things pretty much the same way as we had been before. We're just starting out with what is hopefully a better first guess.
Oh, and if the suggested materials take many steps to synthesize, we'll also have other stuff to play with - all the middle steps, plus any batch of middle step that we make mistakes creating and end up with something unexpected.
If your goal is to save the environment, please don't bring up batteries.
House batteries don't have to meet the same energy density requirements (both volume and weight) as, say, cell phone batteries or electric car batteries. We don't need to pick them up and move them, and we don't need to store them somewhere especially small.
That frees us to use other tech. (I assume you were referring to either the toxicity of chemical batteries, or the strip mining for lithium? Or both). For example, the stuff from this recent slashdot article: http://hardware.slashdot.org/story/11/06/01/1549209/Using-Flywheels-to-Meet-Peak-Power-Grid-Demands Those are just carbon fiber flywheels in steel cases. (And looking up the size of the thing: for a house, one fridge-sized unit would be enough. It's good for storing 25 kwh.)
You may *think* that your high school covered all of that, but honestly, they likely did not. Even if it seems like total crap, you'll likely learn things about art, philosophy, English, history and the like that a high school class could never cover.
This is something that really needs to come up more often in these slashdot college discussions. The standards in college are higher. I went to a decent high school, but even at a fairly cheap state college, a one-semester college class ends up covering what would have taken two years in high school. Yes, that means they're also going to seem hard compared to the four years of vacation you just finished in high school, and they're sometimes going to require amounts of work that look absolutely insane compared to high school homework. They're also much, much more interesting; yes, even the mandatory gen ed classes that I originally didn't want to take.
I had maybe one class that I could call fluff. But now that I think back... the final paper for that class was longer than the final paper I had to do for high school AP English. And this was a music class, and I was a CS major and Math minor.. (The math for me was what programming was for Penguinisto... the thing I originally didn't want to take, and then ended doing a lot more of).
At the risk of invoking Plato's rant about youth: this isn't very new. The last couple waves of technology befuddled new users too. Remember all the VCRs permanently blinking 12:00 in the 1980s, followed by microwaves doing the same in the 1990s? And that's just sticking to old jokes about digital clocks. But I'm sure most of us who're old enough, or knew others who were old enough, have heard a wealth of similar things about devices of the same decades... and similar things about cars dating to several decades before that (not even the maintenance issues, but even simple operation issues like finding the lights and wipers on different models, or driving a manual shift vehicle at all).
Some of these even apply in the other timewise direction; today's youth would not find many devices from the 1960s intuitive at first contact either. Record players and typewriters (and adding machines) come to mind as things one might have trouble using without instruction, especially if they weren't already set up and ready to use.
Yeah, at the same time I can't click 'post anonymously' either.
I found that in FF4, if you right click the link several times you'll eventually get the menu to show up, and then you can open it in a new tab. In Chrome a single right click gets the equivalent menu.
> The current multi-tiered age of majority is ridiculous anyway
The best explanation I've heard for it is that at 18 we trust you to do a bunch of stuff. But we don't trust you to do all that stuff when drunk until 21.
Well, yes and no. The physics is unforgiving; as Kaku says, we're going to hit a transistor shrink wall. At that point, the easy advances are over.
The transistor shrink wall isn't the same thing as peak computation power, only a predictor of it. We have room for advancement in how well we used the transistors we have; once we've got them as small as possibly, we can improve how densely we pack them, and how efficiently we utilize them for computation. Those problems are harder to solve, so we haven't been doing them as quickly yet as the transistor shrinks. But Kaku's conclusion does partially still stand even then, because the pace of improvement is going to drastically slow down. And it will be a very interesting time to be a computer engineer or computer scientist when that happens, as we're likely to resume trying wildly different experimental architectures to eke out some more improvements.
Some paths are already kind of obvious. From ARM's successes, we can see that we can get the power requirements lower, which then means we can have more cores. From AMD's upcoming chips, we can see that cores can be partly merged (to reduce the amount of idle duplicate hardware). There's room for improvement in software, too, of course. But to put it in mathy ways: there exists a Most Efficient Computer that can be made with transistors, and the pace of advancement is going to slow down as we approach it. I don't know how much time it'll take between getting the smallest transistors and getting close enough to their optimal use; I'm guessing at least another decade (so, until 2030), but that's a very loose guess.
Note that this speculation all goes out the window if we figure out another approach entirely, like quantum computing, or replacing the transistor entirely with something that can get us a better calculation density.
Many other posts explain why certain math-that-doesn't-matter really does matter to CS students.
Part of the problem is just that different fields need to master different math in different orders, even if at the end all of them end up having mastered almost all the same things. The math department's ordering specifically works best for math majors, though, and colleges aren't going to make a special duplicate math department for the exclusive use of the computer science department.
Therefore, we end up getting our math content in a less than ideal order; some things maybe much too early, other things too late. It can take a few semesters before all the pieces snap together well. This contributes to the attrition among CS students; certain CS classes may be much harder if you haven't mastered the right math yet, and sometimes certain math classes may be harder if you don't yet understand how you'll be applying it.
I'll be happy enough when it's up to competing with rotating memory, which is a lot more likely.
Serial memory is serial memory, and promising to replace Random Access Memory in latency-critical applications like main memory is just nonsense. Either the people putting out these claims are stupid or they think we are.
You won't be asking to access the one bit at the end of a 8KB track (and stalling the CPU waiting for it).
Modern chips move a whole line of cache at once - a whole 64 bytes for my current chip. And according to the wikipedia article on racetrack memory, the tracks are only 10-20 bits each - not terribly serial. If one track can be cycled around as fast as DRAM, then a bunch of tracks can be done in parallel to handle 64 bytes at once just as fast as DRAM. That's probably years away, but it's not as crazy as your instincts say it is.
The answer is that *local* population density is not the only issue. You have to not only connect some people to each other, but also connect the people to the content. In South Korea, half the population and all the content are already in the greater Seoul metro area. In Japan, 20% of the population are in the greater Tokyo metro area. When you have a natural hub like that, there's an obvious incremental strategy; wire the core, then gradually plug in more outlying areas. Each step of the plan links more people to the total body of content. Many of the smaller European countries have some of the same plans - though they are not as densely packed, all the native language content is in the same smallish area.
In the US, the major cities are individually fairly small fractions of the total population (New York City is the biggest at 6-7%); you'd have to not only wire them up, but connect them all to each other. Otherwise you've got a blazing fast connection to your neighbor but dialup-like speed to the server on the other side of the country. And they're not close together at all; they're spread all along thousands of miles of coastline and chunks of the interior.
And, as far as I know, that's how it was - eventually - done. The higher density areas were done sooner and hooked into a very large backbone network. And that's why it's taking so long. To *really* connect the most English-speakers to the most English language content, it also has to be tightly linked in to Canada and the UK.
Part of why energy density (and fuel tank size) matter for combustion engines is that refueling is inconvenient. You have to go to a gas station to do it, and we don't want to do that much more often than once a week. Basically, our needs here are actually being dictated by the other limitations of the system.
Electrical availability is different, and so our needs are not exactly the same as with gas cars. Electrics need one day worth of range, not one week's worth. The new ones go 100 miles on a charge, and most people drive well under 50 miles per weekday, so they've even got a very comfortable buffer of extra range.
With a little bit of searching, I come up with about 20 megapixels for a perfect shot on perfect 35mm film, 12 megapixels for a merely "good" shot. The best film scanners can go up to 36 bit color depth per pixel, also.
The best DSLRs I can find on newegg today are 21 megapixel cameras in the $6000 range and claim true 14 bits per color channel (which would be 42 bit color), so yes, it seems they've passed 35mm film.
The camera tier under that are about 18 megapixels and 22 bit color, for $800-$1300.
Keep in mind that to get that top quality data, you'd have to set the camera to save everything raw instead of using lossy compression, so the files will be huge. (A quick, rounded calculation says 110 MB per shot). 35mm film comes in 24 shot rolls, right? So that's 2640 MB for a roll-equivalent. For kicks, looking up the biggest and fastest flash memory card, I see a 64 MB card for over $600 that claims 90 MB/sec write speed. That's equivalent to 24 rolls of film (576 shots), though, and it's reusable. Cheap 35mm film looks to be about $10 for four rolls, so $60 for the same number of shots, but I don't know what higher quality film costs and I'm not sure how to find out. Still, you've come out ahead with the memory card if you fill it more than ten times. Oh, and I left the cost (time and/or money) of developing and scanning the film.
It's the air version of what submarines do. Subs have a few tanks that can be empty (full of air) for buoyancy or full (full of seawater) for a dive. The airships are like that, except "full" of air to lose lift, and "empty" to gain lift.
> If you want to hide your data, the file must ostensibly have some other purpose... something that isn't obviously a lie
Hmm. I bet you could hide a lot in the form of actual executable machine code. Part of it would, of course, be dummy code that doesn't accomplish anything if run (but doesn't do any damage either). Considering "Hello World" C++ compiles to a 450+ KB executable, who's going to notice a few extra functions in a program that has a big executable and a bunch of libraries? Your data hider/"compiler" could be arbitrarily complex at making the hidden data look like real code. Possibly to the level of the data retrieval process involving running parts of it in a VM to pluck out a few bytes here and there that would be left on the stack.
Further, if the legit runnable program with data hidden in it is something really big like a game, you could probably have extra things stuffed into the non-executable resources of the game. If your big compressed glob of textures *works*, containing all the structure you'd expected out of it, who's going to notice the few MB of textures that the game loads but never uses? Maybe you use an indie game with lots of mods available, and you say some of the mods you downloaded were a bit sloppily put together. It's just that if you jump at the right spot in the right map, you fall out of the world and into the real application.
For extra kicks, it doesn't have to be code for the actual hardware you're running - it could be java or.net bytecode. Hell, the java bytecode could be sitting in your browser's cache.
It's not as obvious as it sounds. Some things get easier if you're basically still building a 2D chip but with one extra z layer for shorter routing. It quickly gets difficult if you decide you want your 6-core chip to now be a 6-layer one-core-per-layer chip. Three or four issues come to mind.
First is heat. Volume (a cubic function) grows faster than surface area (a square function). It's hard enough as it is to manage the hotspots on a 2D chip with a heatsink and fan on its largest side. With a small number of z layers, you would at the very least need to make sure the hotspots don't stack. For a more powerful chip, you'll have more gates, and therefore more heat. You may need to dedicate large regions of the chip for some kind of heat transfer, but this comes at the price of more complicated routing around it. You may need to redesign the entire structure of motherboards and cases to accommodate heatsinks and fans on both large sides of the CPU. Unfortunately, the shortest path between any two points is going to be through the center, but the hottest spot is also going to be the center, and the place that most needs some kind of chunk of metal to dissipate that heat is going to have to go through the center. In other words, nothing is going to scale as nicely as we like.
Second is delivering power and clock pulses everywhere. This is already a problem in 2D, despite the fact that radius (a linear function) scales slower than area and volume. There's so MUCH hardware on the chip that it's actually easier to have different parts run at different clock speeds and just translate where the parts meet, even though that means we get less speed than we could in an ideal machine. IIRC some of the benefit of the multiple clocking scheme is also to reduce heat generated, too. The more gates you add, the harder it gets to deliver a steady clock to each one, and the whole point of adding layers is so that we can add gates to make more powerful chips. Again, this means nothing will scale as nicely as we like (it already isn't going as nicely as we'd like in 2D). And you need to solve this at the same time as the heat problems.
Third is an insurmountable law of physics: the speed of light in our CPU and RAM wiring will never exceed the speed of light in vacuum. Since we're already slicing every second into 1-4 billion pieces, the amazing high speed of light ends up meaning that signals only travel a single-digit number of centimeters of wire per clock cycle. Adding z layers in order to add more gates means adding more wire, which is more distance, which means losing cycles just waiting for stuff to propagate through the chip. Oh, and with the added complexity of more layers and more gates, there's a higher number of possible paths through the chip, and they're going to be different lengths, and chip designers will need to juggle it all. Again, this means things won't scale nicely. And it's not the sort of problem that you can solve with longer pipelines - that actually adds more gates and more wiring. And trying to stuff more of the system into the same package as the CPU antagonizes the heat and power issues (while reducing our choices in buying stuff and in upgrading. Also, if the GPU and main memory performance *depend* on being inside the CPU package, replacement parts plugged into sockets on the motherboard are going to have inherent insurmountable disadvantages).
It's generally not size of RAM that breaks radix sort; it's the size of cache. Modern processors are highly reliant on cache, which means they're highly reliant on things in memory being in small tight chunks that fit in cache - because cache misses are expensive enough that if you thrash cache badly enough, you may end up running slower than if you hadn't had any cache at all.
Good comparison sorts may start fragmented, but by their very nature each pass of the algorithm makes them less so. Radix sort is the other way around; it follows pointers (so more precious scarce cache in use already) that point in more and more fragmented patterns with every pass. That's why even though radix sort's average speed is theoretically faster than quicksort, quicksort still wins on real life hardware. And that's probably why radix sort wins on GPUs - the data fits in the card's dedicated memory, which is already optimized to be accessed in a much more parallel way than main memory.
Slashdot Mirror
China is already selling to everyone willing to buy. There is no missing demand in the global system, no extra waiting to pick up the slack if another region falters. There is no place that China told "nope, we're busy, wait in line." That's what globalization is, and that's why recessions lately end up going global.
You'll get the "how do I hack?" "how do I make games?" questions no matter what. But if you do the talk about right, those will be flippant jokes rather than serious questions.
Basically you need to open with your way of saying "everything you've seen on TV or in movies is wrong. There are no falling columns of Matrix code controlling everything, and there is no 'hacking' by flying through 3D cities or typing for 30 seconds. World of Warcraft took sixty million dollars and three years to build. Whoever fried Iran's uranium centrifuges, wink wink, took years of planning."
You don't really have time to go in depth, nor do they have the background for you to show them actual code. So don't worry about those. The key is to pick examples that they'll already be at least a little familiar with and that you're comfortable with, and realistically de-magic those examples a bit.
I'd recommend two flavors of examples before you open for questions. The first one is based around "this is what I do in real life". You can very easily tie your database stuff to, well, every big popular site the students have ever used. Facebook, Google search and maps, any webmail, ebay, Amazon, itunes, 4chan, Slashdot, and so on. All of that is based on gathering, sorting, storing, and searching through vast amounts of information. You can do the old dictionary example - use a physical dictionary, solicit a word from the crowd, and then look it up quickly right in front of them. Then point out how it'd take all day if you had to read every line in order from the front or the back. Then point out that Google's database printed out as dictionaries wouldn't fit in the entire internal volume of the school - floor to ceiling, wall to wall, all the rooms and hallways and the cafeteria and gym and auditorium and so on - and yet Google needs to do millions of lookups per second. All that is math. Not Einstein's rocket ship time machine math, but stuff not much harder than what they'll see next year in Precalculus. But without the math, it's like the warehouse at the end of Indiana Jones, where cool things go to die (because no one can ever find them again).
The second one would be any common-but-hard problem in games. Something like pathing AI. You don't need to have actually written those programs; the idea is that you can explain it's too complex to calculate every possible path and pick the best one. The gamers in the crowd will grasp this fairly well, because they've all seen games where the pathing sucked, or where the third person viewpoint kept blocking them, or where the AI enemies seemed to cheat, or where the interface was poorly designed and you could never find what you needed in its maze of nested sub-menus. Again, it's all math. But it's hard-but-interesting math. The computer can do the calculations, but you need to know what its limits are, what calculations need to be done to do the work you want, and how to tell the computer to do those. You cannot say "computer, make me a sandwich"; you've got to write it a cookbook first.
> hyper accelerate us at higher than gravitational effect of earth
> 2G acceleration
I don't know why you think we need these things.
Assuming for the moment that getting to a cruising speed of 90% of lightspeed is practical and desirable, time dilation cuts the cruise part of the trip in half for the crew. But even rounding down, the nearest star is 4 light years away, so even if we had instant acceleration and deceleration, it would still take more than 2 years to get there (crew's point of view. Obviously viewed from earth it'd still take them over 4 years).
Doing the acceleration and deceleration phases at 2G instead of 1G would cut the time needed for those parts in half, but there really isn't much benefit to it. (Checking the math on another site, it only actually saves you a bit over a year). But since the ship already needs to take a couple years to get there, a couple years to get back, and would presumably spend a couple years exploring the other system... cutting two years off the round trip actually doesn't matter much. Either way, you have to have solved the crew's life support issues with heavy recycling. And if you've solved the life support issue, then if a 2G mission is viable timewise, then so is a 1G mission. Likewise, even if you can aim for a higher cruising speed (for even better time dilation), whether you're at 1G or 2G, you're going to be spending years accelerating and decelerating.
And that is enough, by itself, for humanity to outright take over the entire galaxy. Because although the galaxy is 100,000 light years wide and 10,000 light years thick, you only have to go from one star to the next. That means you can do it in easy hops of 3-10 light years at a time.
I don't mean to say that 3-10 light years is easy, just that we don't need more than 1G acceleration to do it. We do need better tech than we have right this moment - I left all of that out of the post to keep it down to reasonable length - but we don't need magical warp drives. Also, that other thread from a day or two ago - about average healthy lifespan hitting 150 years - would certainly also help.
Well, with a few more digits of pi, you could get the error down to some arbitrarily small fraction of one Planck length. Then you're well below the absolute hard limit of measurability, and therefore the circle really would be perfect.
Hmm. A bit of googling, and someone else has already done the calculations. Apparently that only requires 61 digits of pi.
That's only the visible universe, though. You might want a few more digits, just to be sure. You're still not going to need ten trillion digits, though. Probably not even a hundred digits.
You'd be able to see Imaginary Colors . Note the graph in the top right; normally, two or three cones are reacting to the same wavelength, and our brain does some interpretation afterwards.
So, for example, if red and blue cones were shut off, you'd only be able to see green (and, well, also the monochrome from rods). Impossibly pure green at the peak, and duller green at the extremes. And any two wavelengths with the same y value on the green curve of that graph? Those two colors would look identical to you. That means it'd be possible to make a red and blue checkerboard pattern that looks like uniform green to you.
Or it could be that demand has grown fast enough to keep pace with growth in supply. This does happen naturally sometimes. The smartphone market has been growing for that entire time, the amount of flash in each phone is been going up, there's also the tablet market and the ebook reader market, the digital camera market, solid state drives for all those Macbook Airs, and so on. This can keep prices high without monopoly or collusion. If the manufacturers know they're guaranteed to sell everything they make at the current price, then it doesn't benefit them to lower their prices.
If flash fabs didn't cost tens of billions of dollars to make, then yes, we might still be able to argue that manufacturers were colluding to limit production to keep prices high. But due to the expense, they've got a pretty good argument that building new fabs is too risky. Especially since we're bumping up against the reliability limits of flash now; they can't just double density again.
This is where HP hopes to swoop in with memristor tech and save the day / get rich. They're claiming their test runs are already competitive with flash performance and with better reliability, and that the tech is no where near its limits yet. Theoretically, as soon as they start putting this into production, they'll start grabbing the high end market share, and either the price of flash with crash in response (the fabs are about paid off already, so they have a lot of flexibilty to lower prices) or everyone will license from HP and make memristors.
Banks don't have all the money on hand because it is invested (loaned out). In the long run and on average, the loans are repaid with interest. A bank can and does operate this way indefinitely. It's also regulated as to what percentage of the accounts does have to be on hand, and it's also federally insured up to a certain amount per account. The money lent out isn't gone off of the face of the earth; it exists as debt that someone owes back to the bank.
Ponzi schemes don't have all the money on hand because it doesn't all even exist. That's a key, defining feature of the scheme: that some portion of the stated assets are fictitious. The owner of the scheme has been taking some of the money for himself instead and lying about the returns from the investments (which never happened). Payouts to other investors are only to perpetuate the illusion that the whole thing is as profitable as claimed.
The Poker thing much more closely matches the Ponzi scheme, not the bank. For starters, the players' balances were never supposed to be invested or loaned out. (Consider how the poker game works: people play against each other and the house collects its cut no matter who wins. All money involved would normally be immediately on hand because the total amount never changed, only how much of it belongs to who). The money was not there because the company owners took it! Gone from the company completely, not invested and not living on as debt owed back to the company.
They were only able to do this for so long because it was operated online; in a normal casino, every player is cashing out their chips on their way out, but on the internet they had virtual chips to leave in their digital account for the next time they played. Thus the owners could spend most of the actual underlying money, and as long as enough new players were putting money into their accounts, the few players that wanted to make withdrawals could be paid out of that new money. You know, just like in a Ponzi scheme.
I'd think this doesn't actually eliminate trial and error. Consider:
Step 1: algorithm suggests what to try first
Step 2a: we also try small variants of everything from step 1
Step 2b: we play around with everything from step 1 and step 2a that wasn't what we wanted, to see if it has other uses.
So unless the algorithm is so good that the first try is always what we were looking for, we'll still end up doing things pretty much the same way as we had been before. We're just starting out with what is hopefully a better first guess.
Oh, and if the suggested materials take many steps to synthesize, we'll also have other stuff to play with - all the middle steps, plus any batch of middle step that we make mistakes creating and end up with something unexpected.
If your goal is to save the environment, please don't bring up batteries.
House batteries don't have to meet the same energy density requirements (both volume and weight) as, say, cell phone batteries or electric car batteries. We don't need to pick them up and move them, and we don't need to store them somewhere especially small.
That frees us to use other tech. (I assume you were referring to either the toxicity of chemical batteries, or the strip mining for lithium? Or both). For example, the stuff from this recent slashdot article: http://hardware.slashdot.org/story/11/06/01/1549209/Using-Flywheels-to-Meet-Peak-Power-Grid-Demands
Those are just carbon fiber flywheels in steel cases.
(And looking up the size of the thing: for a house, one fridge-sized unit would be enough. It's good for storing 25 kwh.)
You may *think* that your high school covered all of that, but honestly, they likely did not. Even if it seems like total crap, you'll likely learn things about art, philosophy, English, history and the like that a high school class could never cover.
This is something that really needs to come up more often in these slashdot college discussions. The standards in college are higher. I went to a decent high school, but even at a fairly cheap state college, a one-semester college class ends up covering what would have taken two years in high school. Yes, that means they're also going to seem hard compared to the four years of vacation you just finished in high school, and they're sometimes going to require amounts of work that look absolutely insane compared to high school homework. They're also much, much more interesting; yes, even the mandatory gen ed classes that I originally didn't want to take.
I had maybe one class that I could call fluff. But now that I think back... the final paper for that class was longer than the final paper I had to do for high school AP English. And this was a music class, and I was a CS major and Math minor.. (The math for me was what programming was for Penguinisto... the thing I originally didn't want to take, and then ended doing a lot more of).
At the risk of invoking Plato's rant about youth: this isn't very new. The last couple waves of technology befuddled new users too. Remember all the VCRs permanently blinking 12:00 in the 1980s, followed by microwaves doing the same in the 1990s? And that's just sticking to old jokes about digital clocks. But I'm sure most of us who're old enough, or knew others who were old enough, have heard a wealth of similar things about devices of the same decades... and similar things about cars dating to several decades before that (not even the maintenance issues, but even simple operation issues like finding the lights and wipers on different models, or driving a manual shift vehicle at all).
Some of these even apply in the other timewise direction; today's youth would not find many devices from the 1960s intuitive at first contact either. Record players and typewriters (and adding machines) come to mind as things one might have trouble using without instruction, especially if they weren't already set up and ready to use.
Religion in general can coexists with science. The issue is *specific* religions.
If a specific religion demands absolute faith in its doctrine, then any time the doctrine clashes with science, they become mutually exclusive.
Yeah, at the same time I can't click 'post anonymously' either.
I found that in FF4, if you right click the link several times you'll eventually get the menu to show up, and then you can open it in a new tab. In Chrome a single right click gets the equivalent menu.
> The current multi-tiered age of majority is ridiculous anyway
The best explanation I've heard for it is that at 18 we trust you to do a bunch of stuff.
But we don't trust you to do all that stuff when drunk until 21.
Well, yes and no. The physics is unforgiving; as Kaku says, we're going to hit a transistor shrink wall. At that point, the easy advances are over.
The transistor shrink wall isn't the same thing as peak computation power, only a predictor of it. We have room for advancement in how well we used the transistors we have; once we've got them as small as possibly, we can improve how densely we pack them, and how efficiently we utilize them for computation. Those problems are harder to solve, so we haven't been doing them as quickly yet as the transistor shrinks. But Kaku's conclusion does partially still stand even then, because the pace of improvement is going to drastically slow down. And it will be a very interesting time to be a computer engineer or computer scientist when that happens, as we're likely to resume trying wildly different experimental architectures to eke out some more improvements.
Some paths are already kind of obvious. From ARM's successes, we can see that we can get the power requirements lower, which then means we can have more cores. From AMD's upcoming chips, we can see that cores can be partly merged (to reduce the amount of idle duplicate hardware). There's room for improvement in software, too, of course. But to put it in mathy ways: there exists a Most Efficient Computer that can be made with transistors, and the pace of advancement is going to slow down as we approach it. I don't know how much time it'll take between getting the smallest transistors and getting close enough to their optimal use; I'm guessing at least another decade (so, until 2030), but that's a very loose guess.
Note that this speculation all goes out the window if we figure out another approach entirely, like quantum computing, or replacing the transistor entirely with something that can get us a better calculation density.
Many other posts explain why certain math-that-doesn't-matter really does matter to CS students.
Part of the problem is just that different fields need to master different math in different orders, even if at the end all of them end up having mastered almost all the same things. The math department's ordering specifically works best for math majors, though, and colleges aren't going to make a special duplicate math department for the exclusive use of the computer science department.
Therefore, we end up getting our math content in a less than ideal order; some things maybe much too early, other things too late. It can take a few semesters before all the pieces snap together well. This contributes to the attrition among CS students; certain CS classes may be much harder if you haven't mastered the right math yet, and sometimes certain math classes may be harder if you don't yet understand how you'll be applying it.
I'll be happy enough when it's up to competing with rotating memory, which is a lot more likely. Serial memory is serial memory, and promising to replace Random Access Memory in latency-critical applications like main memory is just nonsense. Either the people putting out these claims are stupid or they think we are.
You won't be asking to access the one bit at the end of a 8KB track (and stalling the CPU waiting for it). Modern chips move a whole line of cache at once - a whole 64 bytes for my current chip. And according to the wikipedia article on racetrack memory, the tracks are only 10-20 bits each - not terribly serial. If one track can be cycled around as fast as DRAM, then a bunch of tracks can be done in parallel to handle 64 bytes at once just as fast as DRAM. That's probably years away, but it's not as crazy as your instincts say it is.
The answer is that *local* population density is not the only issue. You have to not only connect some people to each other, but also connect the people to the content. In South Korea, half the population and all the content are already in the greater Seoul metro area. In Japan, 20% of the population are in the greater Tokyo metro area. When you have a natural hub like that, there's an obvious incremental strategy; wire the core, then gradually plug in more outlying areas. Each step of the plan links more people to the total body of content. Many of the smaller European countries have some of the same plans - though they are not as densely packed, all the native language content is in the same smallish area.
In the US, the major cities are individually fairly small fractions of the total population (New York City is the biggest at 6-7%); you'd have to not only wire them up, but connect them all to each other. Otherwise you've got a blazing fast connection to your neighbor but dialup-like speed to the server on the other side of the country. And they're not close together at all; they're spread all along thousands of miles of coastline and chunks of the interior.
And, as far as I know, that's how it was - eventually - done. The higher density areas were done sooner and hooked into a very large backbone network. And that's why it's taking so long. To *really* connect the most English-speakers to the most English language content, it also has to be tightly linked in to Canada and the UK.
That condition is sufficient but not necessary.
Part of why energy density (and fuel tank size) matter for combustion engines is that refueling is inconvenient. You have to go to a gas station to do it, and we don't want to do that much more often than once a week. Basically, our needs here are actually being dictated by the other limitations of the system.
Electrical availability is different, and so our needs are not exactly the same as with gas cars. Electrics need one day worth of range, not one week's worth. The new ones go 100 miles on a charge, and most people drive well under 50 miles per weekday, so they've even got a very comfortable buffer of extra range.
I need to preview more. 64 GB flash card, not 64 MB.
With a little bit of searching, I come up with about 20 megapixels for a perfect shot on perfect 35mm film, 12 megapixels for a merely "good" shot. The best film scanners can go up to 36 bit color depth per pixel, also.
The best DSLRs I can find on newegg today are 21 megapixel cameras in the $6000 range and claim true 14 bits per color channel (which would be 42 bit color), so yes, it seems they've passed 35mm film.
The camera tier under that are about 18 megapixels and 22 bit color, for $800-$1300.
Keep in mind that to get that top quality data, you'd have to set the camera to save everything raw instead of using lossy compression, so the files will be huge. (A quick, rounded calculation says 110 MB per shot). 35mm film comes in 24 shot rolls, right? So that's 2640 MB for a roll-equivalent. For kicks, looking up the biggest and fastest flash memory card, I see a 64 MB card for over $600 that claims 90 MB/sec write speed. That's equivalent to 24 rolls of film (576 shots), though, and it's reusable. Cheap 35mm film looks to be about $10 for four rolls, so $60 for the same number of shots, but I don't know what higher quality film costs and I'm not sure how to find out. Still, you've come out ahead with the memory card if you fill it more than ten times. Oh, and I left the cost (time and/or money) of developing and scanning the film.
You don't have to vent or compress the lifting gas. You can use one these: http://en.wikipedia.org/wiki/Ballonet
It's the air version of what submarines do. Subs have a few tanks that can be empty (full of air) for buoyancy or full (full of seawater) for a dive. The airships are like that, except "full" of air to lose lift, and "empty" to gain lift.
> If you want to hide your data, the file must ostensibly have some other purpose... something that isn't obviously a lie
Hmm. I bet you could hide a lot in the form of actual executable machine code. Part of it would, of course, be dummy code that doesn't accomplish anything if run (but doesn't do any damage either). Considering "Hello World" C++ compiles to a 450+ KB executable, who's going to notice a few extra functions in a program that has a big executable and a bunch of libraries? Your data hider/"compiler" could be arbitrarily complex at making the hidden data look like real code. Possibly to the level of the data retrieval process involving running parts of it in a VM to pluck out a few bytes here and there that would be left on the stack.
Further, if the legit runnable program with data hidden in it is something really big like a game, you could probably have extra things stuffed into the non-executable resources of the game. If your big compressed glob of textures *works*, containing all the structure you'd expected out of it, who's going to notice the few MB of textures that the game loads but never uses? Maybe you use an indie game with lots of mods available, and you say some of the mods you downloaded were a bit sloppily put together. It's just that if you jump at the right spot in the right map, you fall out of the world and into the real application.
For extra kicks, it doesn't have to be code for the actual hardware you're running - it could be java or .net bytecode. Hell, the java bytecode could be sitting in your browser's cache.
It's not as obvious as it sounds. Some things get easier if you're basically still building a 2D chip but with one extra z layer for shorter routing. It quickly gets difficult if you decide you want your 6-core chip to now be a 6-layer one-core-per-layer chip. Three or four issues come to mind.
First is heat. Volume (a cubic function) grows faster than surface area (a square function). It's hard enough as it is to manage the hotspots on a 2D chip with a heatsink and fan on its largest side. With a small number of z layers, you would at the very least need to make sure the hotspots don't stack. For a more powerful chip, you'll have more gates, and therefore more heat. You may need to dedicate large regions of the chip for some kind of heat transfer, but this comes at the price of more complicated routing around it. You may need to redesign the entire structure of motherboards and cases to accommodate heatsinks and fans on both large sides of the CPU. Unfortunately, the shortest path between any two points is going to be through the center, but the hottest spot is also going to be the center, and the place that most needs some kind of chunk of metal to dissipate that heat is going to have to go through the center. In other words, nothing is going to scale as nicely as we like.
Second is delivering power and clock pulses everywhere. This is already a problem in 2D, despite the fact that radius (a linear function) scales slower than area and volume. There's so MUCH hardware on the chip that it's actually easier to have different parts run at different clock speeds and just translate where the parts meet, even though that means we get less speed than we could in an ideal machine. IIRC some of the benefit of the multiple clocking scheme is also to reduce heat generated, too. The more gates you add, the harder it gets to deliver a steady clock to each one, and the whole point of adding layers is so that we can add gates to make more powerful chips. Again, this means nothing will scale as nicely as we like (it already isn't going as nicely as we'd like in 2D). And you need to solve this at the same time as the heat problems.
Third is an insurmountable law of physics: the speed of light in our CPU and RAM wiring will never exceed the speed of light in vacuum. Since we're already slicing every second into 1-4 billion pieces, the amazing high speed of light ends up meaning that signals only travel a single-digit number of centimeters of wire per clock cycle. Adding z layers in order to add more gates means adding more wire, which is more distance, which means losing cycles just waiting for stuff to propagate through the chip. Oh, and with the added complexity of more layers and more gates, there's a higher number of possible paths through the chip, and they're going to be different lengths, and chip designers will need to juggle it all. Again, this means things won't scale nicely. And it's not the sort of problem that you can solve with longer pipelines - that actually adds more gates and more wiring. And trying to stuff more of the system into the same package as the CPU antagonizes the heat and power issues (while reducing our choices in buying stuff and in upgrading. Also, if the GPU and main memory performance *depend* on being inside the CPU package, replacement parts plugged into sockets on the motherboard are going to have inherent insurmountable disadvantages).
It's generally not size of RAM that breaks radix sort; it's the size of cache. Modern processors are highly reliant on cache, which means they're highly reliant on things in memory being in small tight chunks that fit in cache - because cache misses are expensive enough that if you thrash cache badly enough, you may end up running slower than if you hadn't had any cache at all.
Good comparison sorts may start fragmented, but by their very nature each pass of the algorithm makes them less so. Radix sort is the other way around; it follows pointers (so more precious scarce cache in use already) that point in more and more fragmented patterns with every pass. That's why even though radix sort's average speed is theoretically faster than quicksort, quicksort still wins on real life hardware. And that's probably why radix sort wins on GPUs - the data fits in the card's dedicated memory, which is already optimized to be accessed in a much more parallel way than main memory.