Time is not required to be all that different from a spatial dimension. Some theories describe perception of time merely as a consequence of increasing entropy, which is itself a consequence of an expanding universe.
While entropy does indeed determine the direction in which time appears (to us) to "flow", timelike dimensions _are_ physically distinct from spacelike dimensions. There's a - sign instead of a + sign in front of them in one of the SR equations, which has important consequences.
A more detailed explanation is left to someone with a better background than I have.
Would there be a credible "space defense" by putting up an impenetrable shield of jagged space junk? We'd seal ourselves up on the Earth for thousands of years, but we'd be safe from the aggressive alien menace our space probes discovered out in orbit around Jupiter.
An interesting idea, but it probably wouldn't work.
Firstly, if you have enough debris in orbit to harm anything that simply passes through briefly, then you have enough debris that it will collide with itself quite often. These perturbations will cause a lot of it to fall back to Earth, and the rest of it to clump together into large masses, ending when collisions become infrequent again (making the shield useless).
Secondly, aliens would probably just drop rocks on us if they didn't like us:). Those wouldn't mind a debris field.
It would be very effective at killing our own satellites, though.
When you can manipulate the atom, there is no point having huge unwieldy craft several metres long - why not just build something the size of a blade of grass?
Because your grassblade starship won't have enough power to send a signal back to earth to report its findings.
This is the main factor that provides a final lower limit on the size/mass of space probes, be they in-system or interstellar. An in-system one that stays inside the orbit of Mars can get away with being big but light, as it can draw power from the sun. For the outer solar system or for deep space, it'll have to carry a radiothermal power source large enough to power a microwave beam that outshines background noise and instrument noise when seen from Earth.
The electronics for the transmitter aren't going to be small or light either.
While I agree that space debris is a big problem for objects that have to be in space for long periods, I think you're overstating some of the hazards.
Then, there's the danger of a chain reaction. One satellite or rocket fragmenting from a collision, generating enough debris that those fragments will, in turn, hit other objects, and so on.
This would only happen if a very large chunk struck a satellite, which is extremely unlikely (size distribution is going to be a 1/x type of deal). A fleck striking a satellite might kick up ejecta from the hole it leaves, but these secondary flecks will (for the most part) be smaller than the original impacting object. Yes, you'll get more dust, but you won't get many more shuttle-window-puncturing pieces.
Some pathological substances (like paint) may flake off more readily when disturbed, but this is a small fraction of the total mass out there (and paint is vulnerable to abrasion from dust, and so will eventually disintegrate into more dust instead of staying in big flecks).
With many satellites with their own fuel systems, etc, to keep them correctly positioned, you'd better hope that there are fail-safes installed. With space becoming ever-more crowded, we don't need rogue satellites playing astro-pinball.
Space - even the relatively small volume called low earth orbit - is big. Really, *really* big. Even with a few tens of thousands of satellites up there, you'd have to *actively* *try* to hit something to have a reasonable chance of colliding with another satellite any time soon. Debris is a problem because instead of one big chunk of metal flying through space you have a thousand little flecks of paint. *This* does have a chance of striking something (eventually - and that's the key word).
Essentially, Earth would become isolated by an impenetrable barrier of it's own making.
Not a chance. If you're only in low orbit for a short time (like, say, less than a decade), you can go through just about any debris field imaginable without worry. Again, even LEO is *really* *big*, and we haven't really put that much matter up there.
Debris is only a problem if you're planning to stay in the debris zone for years or decades. This makes it a threat to satellites, and to the ISS, and to the shuttle. It's not a threat to space probes, Moon or Mars missions, satellites in higher orbits, or anything else that isn't sticking around in the debris zone. While still significant, and definitely worth doing something about, this hardly qualifies as an "impenetrable barrier".
You still have a very viable, and mroe efficient anyway coal plant working, and now, you add some bacteria and mirrors, and you get some raw material back, as well as cleaner emissions. There is no efficiency loss, you are just adding free sunlight.
The "loss" is the effort, resources, and sheer space required to build and maintain the several *square kilometres* of mirrors that this would require. My argument is that if you're going to this much trouble and expense, you might as well build a photoelectric or photothermal power plant instead of a coal-and-mirrors plant (less effort for the same amount of power).
This is *not* a "free addition" to an existing plant. The cost of the addition will be comparable to the cost of the plant itself.
They're using SUNLIGHT! You know, the BIG BALL OF INCANDESCENT GAS THAT BURNS BRIGHTLY! It ain't goin' anywhere for awhile, and it's esentially FREE!
Sunlight doesn't magically route itself to the smokestack. The proposed project would use mirrors to divert it.
Enough sunlight has to come into the stack to convert all of the plant's oxidized carbon back into non-oxidized carbon. This represents about a third of the energy throughput of a fossil fuel plant, even if it's burning something rich in hydrogen.
Because bacteria have pretty lousy energy conversion efficiency, you'd probably be better off just building an equivalent area of solar panels instead of your mirrors and coal plant to produce power. You'll need to use at least this much area in mirrors already. This is what the original poster was talking about.
Coal is not carbon. It is a hydrocarbon. Those carbon-hydrogen bonds contain a lot of energy. The bacteria use light and the CO2 to create carbon (not a hydrocarbon). So basically you're converting CO2 gas and light via bacteria to C (soot) and O2 and keeping the carbon out of the atmosphere.
Actually, coal is largely carbon, if I recall correctly. Natural gas, oil and tar are hydrocarbons.
Either way, a fossil fuel plant burns its fuel fairly completely. A hydrocarbon will give you CO2 and water out. There are no CH bonds for the bacteria to draw energy from (which would still require oxidation).
Fossil fuel plants will produce soot, but not very much of it compared to the amount of fuel that they process. Soot is, after all, fuel that can still be burned.
I think that asteroids are one of the coolest things we can study: they are much more useful for raw materials than bodies like the moon, since they have the energy bonus of being out of the Earth's gravity well.
Actually, the moon's almost completely out of the Earth's gravity well. The main energy cost for exporting lunar material is getting the material out of the _moon's_ gravity well, and this is pretty low (especially since lunar vacuum lets you build mass drivers and the like easily).
It would be quite difficult to ship material from most asteriods (the ones in the belt) to Earth's location, because the great difference in GPE (Gravitational Potential Energy) from their different orbital radii about the _sun_. It could certainly be done; it's just probably more of a pain than using lunar material.
For supplying Earth's surface, we're always better mining material from the crust. No expensive shuffling about required at all.
Earth orbit is probably best supplied from the moon, though it'll be easier to ship stuff to higher orbits than lower (again, due to GPE).
Still, it's nice to have direct confirmation that some asteroids in the neighbourhood are made of mineable materials. This will make it much easier to build bases on _them_ (or to transform them into gaggles of space stations).
The hardware folks like open, certified specs [PCI, AGP, USB, etc.] that they can conform to. Any company with a few talented chip engineers could make a card that outperforms the GeForce 2's, make it plug into any AGP board, and compete.
While to some extent that's true, in practice you'd get your arse sued off until you could prove in court that you really *weren't* violating any of nVidia's implementation patents (or anyone else's). There were a few sabre-rattling sessions last year in this vein.
There are only a few straightforward approaches to building any given part of a graphics pipeline. Just about all of these are patented (usually preemptively) by the big graphics card companies. It's not as bad as the software patent arena, but it's still not nice.
If you have lots of money, you can hold out long enough that the big companies will offer to cross-licence technology with you. Otherwise, you'd better pray that they don't consider you a threat.
Perhaps it's not quite this bad, but you'd have to do quite a bit of patent research to avoid stepping on anyone's toes.
Lastly, a nit-pick re. AGP, PCI, and USB. For some of these, you have to pay licensing fees to get the specification manual. For all, if I understand correctly, you have to pay licensing fees to build any hardware that talks to them. The standards bodies are money-driven too.
In practice, the cost will be low compared to the cost of the rest of your card, but it's still there.
Every model is incomplete. "The suggests that the Standard Model is incomplete" -- Every model is finite and can not explain complete reality, which is infinitely complex. New and better models will always be invented. Hopefully they will come closer and closer to the limit (as in asymptote) - reality.
You are making a big assumption here - that reality is infinitely complex.
The universe may (or may not) be infinite in _size_, but that has no bearing on the complexity of the laws that govern it.
Behavior of the universe may look complicated, but again, this may very well be just complicated consequences of simple laws.
I see no reason to believe that the fundamental laws governing the universe wouldn't be very simple. Complexity is usually a sign that we've missed something fundamental going on.
By writing a driver for POVray and given enough processingpower could I use beowulf-cluster as my graphics card? And play nicely rendered counterstrike?..and and get more girls?
Yes, no (unless you like playing at 5 beautiful frames per second), and only if they're geeks, respectively.
The guy has a point, a tesselated mesh isn't a nurb:). And how would you calculate rendering in nurbs? JFYI 3D programs converts subpatch/nurbs to polygons before rendering. The more detail you want, the more it will "add polygons (normally triangles)" to mimic the nurb curve.
As you point out, a NURB is usually _implemented_ as a tesselated mesh (though not a flat one, so we may just be disagreeing over the definition of "tesselated mesh").
For implementation, you'd either let the graphics card indiscriminately assume that all triangles are really curved surfaces, and interpolate and tesselate surfaces with normals and corner vertices matching the original triangle's corner vertices and normals, or define a GL extension for such curved patches (possibly specified by NURBS parameters, possibly not).
The first approach gives you benefits for all models, though it can cause nasty artifacts on models that aren't constructed nicely, and the second approach makes all of your models look fine, but requires that the programmer know about the extension to take advantage of it.
Implement the translation (if any) in GLUT, and your Playstation III programmers don't even have to know about it. Distribute a modified GLUT library with your SDK that probes for this feature and uses it to accelerate GLUT's NURBS, and you might even get game designers using this in other games (paving the way for a PC graphics card based on this or a similar chip).
I doubt Sony's actually _doing_ this, but that's one of the things I'd use a high poly-rate chip for if I was writing the firmware and SDK for it.
think the real push should start moving away from higher polygon rates and more towards greater visualization enhancements for each polygon. We're already dealing with cool things such as environmental bump mapping. I'm still waiting for the fully featured ray-tracing engine. I'd be perfectly happy with a scene that was only 30fps, 800x600, average number of polygons if I could just feel the glimmer of living light.
If you have decent calculation engines on-chip, you can use a silly polygon throughput to emulate nicer features that might be difficult to implement directly. Tesselate large polygons to make NURBS surfaces. Add multiple semitransparent "halos" for fancy lighting effects. Use various sneaky tricks to emulate volume effects like smoke and Ye Canonical Plasma Field. Etc.
You can do all of these in the main CPU, but it bogs down the CPU like crazy and saturates your system bus (sending all of those triangles to the chip). If you can get the chip to do it for you, then it'll look almost as good as real curved surfaces/lighting/etc, without hogging system resources (just rendering resources).
While a true hardware implementation of nifty features would be more efficient, the brute force approach lets you use mainly well-understood designs, and lets you patch bugs in firmware instead of needing a new chip revision.
I've just finished reading the article. A few thoughts spring to mind:
First of all, this sounds like the Emotion Engine hype all over again. It might be an amazing chip, but it'll probably just be "decent" when it finally gets here.
Secondly, don't expect to see this in quantity until 0.15/0.13 micron fabs get here. Remember the Emotion Engine. Fabbing a chip that big is a royal pain. It'll get much easier when finer linewidths shrink the die size.
Thirdly, CMOS fabrication processes can be optimized for good quality DRAM, or for good quality logic. Not both (without throwing lots of money at it). The two types of circuit have contradictory requirements for transistor characteristics. In practice, this has meant that DRAM-plus-core chips have either had slow cores or bulky, slow, hot DRAM.
The only saving grace is that most of the chip area will be DRAM. This means that most of it will be tolerant of manufacturing faults (you usually have more DRAM rows than you need, and cut out the faulty ones before packaging). This is the only thing that will let them fab a chip this size at all.
The chip should provide interesting perspective when it arrives (much as the Emotion Engine did), but I don't expect it to take the world by storm.
Do you have any sample code or resources you could point to?
A search for "genetic algorithm"+"simulated annealing" gives mixed results.
I once wrote a brief description of both for a friend. I'll email it to you.
There are definitely points in the spreadsheet where it stops being a good idea to buy more new machines and instead becomes a better idea to add more RAM to your existing machines. So the GA solution would somehow need to take into account the number and type of machines available at a given time T in order to optimize what should happen at time T+1.
That's all in how you decide to specify the system state vector and evaluate costs.
SA and GA approaches represent "solutions" to the task as long strings of numbers (vectors). How you translate a vector to a real system configuration is up to you; the GA or SA, on the other hand, just needs the vector, and doesn't care how its interpreted.
One approach is to just have two numbers, specifying the number of machines and the RAM per machine. Another approach is to use variable-length vectors and have one (speed,RAM) pair per entry. A myriad of other approaches are possible. You just have to have a black-box function that can evaluate how well the configuration specified by a given vector would perform. Both GA and SA approaches work by perturbing state vectors in various ways, trying to get a system with a better "performance" number. That's all they do.
The re-use of existing equipment can be taken into account when generating the "performance" number. A system that's more expensive could be deemed to "perform" worse (this isn't just compilation speed - it's an arbitrary figure of merit that you define). This would give better "performance" for systems that re-used existing hardware, and would place an upper bound on how much new hardware you could buy while still improving "performance".
This is an interesting idea. Right now this particular model is embedded in a pretty large scalability spreadsheet, but I could probably extract the key variables and formulas. What's less clear to me is how to model this over time under a GA approach.
For any GA or SA-based solution, you only need to come up with two things: a way of representing a system configuration as a vector, and a way of figuring out how "good" the solution represented by a given vector is. Plug these in, and watch it go:).
hmmm.. interesting....! Which model are we talkin about here?
CAVEAT: Bear in mind that I've only taken one systems course, so my terminology and descriptions may be a bit off, and I won't know about the more advanced techniques...
The idea is to represent your system as a series of processing nodes with task queues, and to see what happens as you send tasks through the system. Based on the length of time spent at each node for the different classes of tasks you're sending around (specified as a probability distribution), you get the average "utilization" of each node (how much of the time it's being used), the average queue length at each node, and so forth. This helps you find system bottlenecks for any given configuration.
Best of all, the math that produces these statistics is straightforward enough that, with a few approximations, it works even for very large systems. This is what your off-the-shelf software packages will handle. You can vary the design of the system, and the software will rapidly tell you how the change affected the system "hot spots".
For small systems and coarse approximations (exponential/memoryless probability distributions), you can even work out a lot of this by hand.
In this context, I'd probably declare the compiling machines to be nodes, and use existing task data to come up with a (back of the envelope) probability distribution for task lengths on the various machines. Questions like "what's the point of diminishing returns for adding nodes?" and "what happens if I change the paths of task flow like *this*?" can be easily answered from there.
I'd be interested to know though, for anyone who has experience with FPGA, if the best FPGA tech would be capable of creating even a general purpose embedded CPUs like the Z80.
Sure, easily. Current top-of-the-line FPGAs let you synthesize designs with on the order of a million gates or so.
People have been writing papers about chips with reconfigurable parts for many years. The idea continues to show promise, but the practical problems with actually _using_ something like this are great, and the benefits aren't amazingly spectacular.
You can buy modules containing integrated processor cores and FPGA logic already from Altera and the other big FPGA companies.
The best I've come up with is a glorified spreadsheet that estimates total build time and lets me tweak #of machines and # of split-up jobs, and watch the bottom line change. Gross but I can't think of anything better.
Have you considered writing a script that tries to optimize this for you?
I've hacked together SA-based optimizers in Perl on occasion for similar tasks.
Whether this is effective for you depends on how much time you'd spend scanning solutions by other methods (a script like this takes anywhere from a couple of hours to a couple of days to write, depending on complexity).
This is the kind of job queueing theory was designed for. Pick up a textbook from your local university bookstore, if you're interested in the topic. This will let you fairly easily get estimates of how varying system parameters affect performance.
I'm afraid I don't know what commercial packages handle this, though. We used a high-level system simulation tool called "MAP", but it wasn't very intuitive to use. Better solutions certainly exist.
Some of us are actually *interested* in this...
on
Left-Handed Nuclei?
·
· Score: 2
What use is this? Talk about esoteric. If it helps us get closer to a Unified Theory, OK, I'm all for it. If it gets us closer to practical Fusion Power, I'm all for it. The article doesn't say what we can do with this knowledge.
Why does that make this any less interesting?
If you want the pedantic argument, then yes, this does bring us closer to fusion power by improving our understanding of nuclear forces and giving us new data points to test our models with, but that's secondary.
As I have tried to post twice, MIT Tech Review has an article regarding the ability to use an inkjet printer to print a semiconductor chip.
It is a very interesting read and even speaks to the possibility of this allowing open source cpu's in the future. Imagine, downloading and printing the latest version of your cpu before upgrading to the n.n kernel it is targeted at:)
The problem with this technology is that even if you can shrink an inkjet printer head to the point where you're laying down 0.18-micron dots, you'll have one heck of a time keeping the environment clean enough for your fabbed chip to work. This is one of the main reasons why semiconductor fabs are so expensive (though other factors definitely contribute).
If you're printing at anything other than deep submicron linewidth... your chips will be useless. Maximum operating frequency, to a rough approximation, goes up as the inverse square of the linewidth. Make the linewidth 100 times wider, and your chip will run about 10000 times slower. You're not going to be playing quake on an inkjet-printed chip any time soon.
This technology is extremely useful for making things like active-matrix displays and cheap "smart" devices, but that's about it.
Now, the silver lining. You _can_ fab moderately complex chips using Field Programmable Gate Arrays. These have been around for a long time, and are frequently used for prototyping. You'll get something a tenth the complexity and a fifth the speed of a real chip, but that's still enough for many applications (program yourself a sound card with nifty new features, or emulate an older gaming system or computer in hardware). This will also give you a training tool for gearing up for the real thing (true IC design and fabrication).
Fabbing ICs is impractical for individuals, but possible for organizations. It'll cost you about $500k or so once you have a finished, debugged design to produce a few hundred thousand chips (a couple of wafer runs; the first one or two runs will be buggy alpha silicon which you test and revise).
I remember, years ago, during the (seeming) height of the US military's interest in rail guns (and Popular Science, etc., etc...) a small group of college students with a more efficient answer...
it was a COIL Gun.
Really the same basic idea as a rail gun, but they 'wrapped' the rails around the payload to get more efficient use of the electromotive force -- more 'bang for your watt,' so to speak.
Actually, the operating principle of the version I've heard of was quite different. Railguns use the "motor principle" that you learned about in high school. Coilguns use Lenz's Law repulsion between coils and a conducting projectile (which you probably also learned about in high school:)).
That, and it looked more like a gun barrel. It was so much cooler looking!
I thought of a way to up the coolness factor:
The Gauss Nerf (tm).
Drew up schematics a year or so ago. I'll get around to building it Really Soon Now, honest...
(It would fire giant Nerf darts with 50g aluminum cylinders in them fast enough to be entertaining. The challenge is to keep it slow enough not to break windows.)
If I remember right (It's been few years since I worked on this), for higher rates of speed it's impossible to use a coilgun. Reason? It's less efficient. The coilgun might impart energy to the projectile better, but the coilgun wastes more energy getting to the projectile. As a result, at higher speeds, a coilgun will basically melt itself.
Nothing that I know of about coilguns would cause a fundamental limit to projectile velocity, and I've done the calculations fairly recently.
The only requirement is that your coil field alternate many times while the projectile is within interaction range of it. While this causes frequency to go up with projectile velocity for a fixed coil size, you can just use a larger projectile and bigger coils spaced farther apart to build a gun that can handle higher speeds at lower frequencies.
Railguns are horrible. I've done the calculations for those, too. You need truly, truly silly currents to generate a useful amount of force, which means that your rails will degrade rapidly and that spot-welding of the projectile will be a big problem. You'll also have the very difficult task of figuring out a way to keep your projectile in good, conducting contact with the rails while sliding along at a few km/sec. The only even remotely practical approach to this I've seen is to send current through a plasma arc behind the projectile instead of the projectile itself, but that'll degrade the rails even more quickly.
Coilguns are much nicer to deal with electrically, and tend to have much higher accelerations (thus making the gun much more compact).
As for inefficiency... I can't see where this comes from, either (perhaps you could post a link?). As long as the projectile occupies most of the area inside the solenoid, and you're operating at frequencies high enough to make inductive and capacitive effects dominate resistive ones, and you're operating at frequencies low enough not to radiate power into the environment, most of your energy should go to the projectile.
Finally, even an inefficient gun - rail or coil - wouldn't have much of a heating problem if active cooling was used. Even a very fast projectile has relatively little energy invested in it. Even if you waste as much energy as you send into the projectile (or more), your gun only heats up by a few tens of degrees per shot, at most (for orbital-velocity slugs).
Really, this is nothing special. Seriously, I came up with a primitive, if completely non-effective, idea for the same thing in a high school science project. Essentially, it'd just be a series of solonoids powered up and down in order so as to propel a "bullet" forward through a barrel.
The operating principles for a true coilgun are a bit different from your standard nailgun. A coilgun of the kind you seem to be describing works on ferromagnetic projectiles, using more or less DC effects. Apply a field to a coil in front of the projectile, and let it pull the projectile along.
Among other things, barrel friction from the dragged projectile is a problem here.
The coilgun designs from this university group use the Lenz's Law repulsion between a conducting projectile and an _alternating_ magnetic field. The projectile doesn't touch the gun barrel, which gets rid of a lot of the problems that railguns have.
Slashdot Mirror
Time is not required to be all that different from a spatial dimension. Some theories describe perception of time merely as a consequence of increasing entropy, which is itself a consequence of an expanding universe.
While entropy does indeed determine the direction in which time appears (to us) to "flow", timelike dimensions _are_ physically distinct from spacelike dimensions. There's a - sign instead of a + sign in front of them in one of the SR equations, which has important consequences.
A more detailed explanation is left to someone with a better background than I have.
There are those out there who claim that cell phones cause brain/eye cancer.
In the immortal words of Ebeneezum the Wizard:
"There are also those who claim that if you stick your fingers in your nose and blow, you'll increase your intelligence."
The larger, better-controlled studies on cancer vs. EMF have all come out negative.
Would there be a credible "space defense" by putting up an impenetrable shield of jagged space junk? We'd seal ourselves up on the Earth for thousands of years, but we'd be safe from the aggressive alien menace our space probes discovered out in orbit around Jupiter.
:). Those wouldn't mind a debris field.
An interesting idea, but it probably wouldn't work.
Firstly, if you have enough debris in orbit to harm anything that simply passes through briefly, then you have enough debris that it will collide with itself quite often. These perturbations will cause a lot of it to fall back to Earth, and the rest of it to clump together into large masses, ending when collisions become infrequent again (making the shield useless).
Secondly, aliens would probably just drop rocks on us if they didn't like us
It would be very effective at killing our own satellites, though.
When you can manipulate the atom, there is no point having huge unwieldy craft several metres long - why not just build something the size of a blade of grass?
Because your grassblade starship won't have enough power to send a signal back to earth to report its findings.
This is the main factor that provides a final lower limit on the size/mass of space probes, be they in-system or interstellar. An in-system one that stays inside the orbit of Mars can get away with being big but light, as it can draw power from the sun. For the outer solar system or for deep space, it'll have to carry a radiothermal power source large enough to power a microwave beam that outshines background noise and instrument noise when seen from Earth.
The electronics for the transmitter aren't going to be small or light either.
While I agree that space debris is a big problem for objects that have to be in space for long periods, I think you're overstating some of the hazards.
Then, there's the danger of a chain reaction. One satellite or rocket fragmenting from a collision, generating enough debris that those fragments will, in turn, hit other objects, and so on.
This would only happen if a very large chunk struck a satellite, which is extremely unlikely (size distribution is going to be a 1/x type of deal). A fleck striking a satellite might kick up ejecta from the hole it leaves, but these secondary flecks will (for the most part) be smaller than the original impacting object. Yes, you'll get more dust, but you won't get many more shuttle-window-puncturing pieces.
Some pathological substances (like paint) may flake off more readily when disturbed, but this is a small fraction of the total mass out there (and paint is vulnerable to abrasion from dust, and so will eventually disintegrate into more dust instead of staying in big flecks).
With many satellites with their own fuel systems, etc, to keep them correctly positioned, you'd better hope that there are fail-safes installed. With space becoming ever-more crowded, we don't need rogue satellites playing astro-pinball.
Space - even the relatively small volume called low earth orbit - is big. Really, *really* big. Even with a few tens of thousands of satellites up there, you'd have to *actively* *try* to hit something to have a reasonable chance of colliding with another satellite any time soon. Debris is a problem because instead of one big chunk of metal flying through space you have a thousand little flecks of paint. *This* does have a chance of striking something (eventually - and that's the key word).
Essentially, Earth would become isolated by an impenetrable barrier of it's own making.
Not a chance. If you're only in low orbit for a short time (like, say, less than a decade), you can go through just about any debris field imaginable without worry. Again, even LEO is *really* *big*, and we haven't really put that much matter up there.
Debris is only a problem if you're planning to stay in the debris zone for years or decades. This makes it a threat to satellites, and to the ISS, and to the shuttle. It's not a threat to space probes, Moon or Mars missions, satellites in higher orbits, or anything else that isn't sticking around in the debris zone. While still significant, and definitely worth doing something about, this hardly qualifies as an "impenetrable barrier".
You still have a very viable, and mroe efficient anyway coal plant working, and now, you add some bacteria and mirrors, and you get some raw material back, as well as cleaner emissions. There is no efficiency loss, you are just adding free sunlight.
The "loss" is the effort, resources, and sheer space required to build and maintain the several *square kilometres* of mirrors that this would require. My argument is that if you're going to this much trouble and expense, you might as well build a photoelectric or photothermal power plant instead of a coal-and-mirrors plant (less effort for the same amount of power).
This is *not* a "free addition" to an existing plant. The cost of the addition will be comparable to the cost of the plant itself.
They're using SUNLIGHT! You know, the BIG BALL OF INCANDESCENT GAS THAT BURNS BRIGHTLY! It ain't goin' anywhere for awhile, and it's esentially FREE!
Sunlight doesn't magically route itself to the smokestack. The proposed project would use mirrors to divert it.
Enough sunlight has to come into the stack to convert all of the plant's oxidized carbon back into non-oxidized carbon. This represents about a third of the energy throughput of a fossil fuel plant, even if it's burning something rich in hydrogen.
Because bacteria have pretty lousy energy conversion efficiency, you'd probably be better off just building an equivalent area of solar panels instead of your mirrors and coal plant to produce power. You'll need to use at least this much area in mirrors already. This is what the original poster was talking about.
Coal is not carbon. It is a hydrocarbon. Those carbon-hydrogen bonds contain a lot of energy. The bacteria use light and the CO2 to create carbon (not a hydrocarbon). So basically you're converting CO2 gas and light via bacteria to C (soot) and O2 and keeping the carbon out of the atmosphere.
Actually, coal is largely carbon, if I recall correctly. Natural gas, oil and tar are hydrocarbons.
Either way, a fossil fuel plant burns its fuel fairly completely. A hydrocarbon will give you CO2 and water out. There are no CH bonds for the bacteria to draw energy from (which would still require oxidation).
Fossil fuel plants will produce soot, but not very much of it compared to the amount of fuel that they process. Soot is, after all, fuel that can still be burned.
I think that asteroids are one of the coolest things we can study: they are much more useful for raw materials than bodies like the moon, since they have the energy bonus of being out of the Earth's gravity well.
Actually, the moon's almost completely out of the Earth's gravity well. The main energy cost for exporting lunar material is getting the material out of the _moon's_ gravity well, and this is pretty low (especially since lunar vacuum lets you build mass drivers and the like easily).
It would be quite difficult to ship material from most asteriods (the ones in the belt) to Earth's location, because the great difference in GPE (Gravitational Potential Energy) from their different orbital radii about the _sun_. It could certainly be done; it's just probably more of a pain than using lunar material.
For supplying Earth's surface, we're always better mining material from the crust. No expensive shuffling about required at all.
Earth orbit is probably best supplied from the moon, though it'll be easier to ship stuff to higher orbits than lower (again, due to GPE).
Still, it's nice to have direct confirmation that some asteroids in the neighbourhood are made of mineable materials. This will make it much easier to build bases on _them_ (or to transform them into gaggles of space stations).
The hardware folks like open, certified specs [PCI, AGP, USB, etc.] that they can conform to. Any company with a few talented chip engineers could make a card that outperforms the GeForce 2's, make it plug into any AGP board, and compete.
While to some extent that's true, in practice you'd get your arse sued off until you could prove in court that you really *weren't* violating any of nVidia's implementation patents (or anyone else's). There were a few sabre-rattling sessions last year in this vein.
There are only a few straightforward approaches to building any given part of a graphics pipeline. Just about all of these are patented (usually preemptively) by the big graphics card companies. It's not as bad as the software patent arena, but it's still not nice.
If you have lots of money, you can hold out long enough that the big companies will offer to cross-licence technology with you. Otherwise, you'd better pray that they don't consider you a threat.
Perhaps it's not quite this bad, but you'd have to do quite a bit of patent research to avoid stepping on anyone's toes.
Lastly, a nit-pick re. AGP, PCI, and USB. For some of these, you have to pay licensing fees to get the specification manual. For all, if I understand correctly, you have to pay licensing fees to build any hardware that talks to them. The standards bodies are money-driven too.
In practice, the cost will be low compared to the cost of the rest of your card, but it's still there.
Every model is incomplete. "The suggests that the Standard Model is incomplete" -- Every model is finite and can not explain complete reality, which is infinitely complex. New and better models will always be invented. Hopefully they will come closer and closer to the limit (as in asymptote) - reality.
You are making a big assumption here - that reality is infinitely complex.
The universe may (or may not) be infinite in _size_, but that has no bearing on the complexity of the laws that govern it.
Behavior of the universe may look complicated, but again, this may very well be just complicated consequences of simple laws.
I see no reason to believe that the fundamental laws governing the universe wouldn't be very simple. Complexity is usually a sign that we've missed something fundamental going on.
By writing a driver for POVray and given enough processingpower could I use beowulf-cluster as my graphics card? And play nicely rendered counterstrike? ..and and get more girls?
Yes, no (unless you like playing at 5 beautiful frames per second), and only if they're geeks, respectively.
The guy has a point, a tesselated mesh isn't a nurb :). And how would you calculate rendering in nurbs? JFYI 3D programs converts subpatch/nurbs to polygons before rendering. The more detail you want, the more it will "add polygons (normally triangles)" to mimic the nurb curve.
As you point out, a NURB is usually _implemented_ as a tesselated mesh (though not a flat one, so we may just be disagreeing over the definition of "tesselated mesh").
For implementation, you'd either let the graphics card indiscriminately assume that all triangles are really curved surfaces, and interpolate and tesselate surfaces with normals and corner vertices matching the original triangle's corner vertices and normals, or define a GL extension for such curved patches (possibly specified by NURBS parameters, possibly not).
The first approach gives you benefits for all models, though it can cause nasty artifacts on models that aren't constructed nicely, and the second approach makes all of your models look fine, but requires that the programmer know about the extension to take advantage of it.
Implement the translation (if any) in GLUT, and your Playstation III programmers don't even have to know about it. Distribute a modified GLUT library with your SDK that probes for this feature and uses it to accelerate GLUT's NURBS, and you might even get game designers using this in other games (paving the way for a PC graphics card based on this or a similar chip).
I doubt Sony's actually _doing_ this, but that's one of the things I'd use a high poly-rate chip for if I was writing the firmware and SDK for it.
think the real push should start moving away from higher polygon rates and more towards greater visualization enhancements for each polygon. We're already dealing with cool things such as environmental bump mapping. I'm still waiting for the fully featured ray-tracing engine. I'd be perfectly happy with a scene that was only 30fps, 800x600, average number of polygons if I could just feel the glimmer of living light.
If you have decent calculation engines on-chip, you can use a silly polygon throughput to emulate nicer features that might be difficult to implement directly. Tesselate large polygons to make NURBS surfaces. Add multiple semitransparent "halos" for fancy lighting effects. Use various sneaky tricks to emulate volume effects like smoke and Ye Canonical Plasma Field. Etc.
You can do all of these in the main CPU, but it bogs down the CPU like crazy and saturates your system bus (sending all of those triangles to the chip). If you can get the chip to do it for you, then it'll look almost as good as real curved surfaces/lighting/etc, without hogging system resources (just rendering resources).
While a true hardware implementation of nifty features would be more efficient, the brute force approach lets you use mainly well-understood designs, and lets you patch bugs in firmware instead of needing a new chip revision.
No idea what Sony's actually going to do.
I've just finished reading the article. A few thoughts spring to mind:
First of all, this sounds like the Emotion Engine hype all over again. It might be an amazing chip, but it'll probably just be "decent" when it finally gets here.
Secondly, don't expect to see this in quantity until 0.15/0.13 micron fabs get here. Remember the Emotion Engine. Fabbing a chip that big is a royal pain. It'll get much easier when finer linewidths shrink the die size.
Thirdly, CMOS fabrication processes can be optimized for good quality DRAM, or for good quality logic. Not both (without throwing lots of money at it). The two types of circuit have contradictory requirements for transistor characteristics. In practice, this has meant that DRAM-plus-core chips have either had slow cores or bulky, slow, hot DRAM.
The only saving grace is that most of the chip area will be DRAM. This means that most of it will be tolerant of manufacturing faults (you usually have more DRAM rows than you need, and cut out the faulty ones before packaging). This is the only thing that will let them fab a chip this size at all.
The chip should provide interesting perspective when it arrives (much as the Emotion Engine did), but I don't expect it to take the world by storm.
Do you have any sample code or resources you could point to?
:).
A search for "genetic algorithm"+"simulated annealing" gives mixed results.
I once wrote a brief description of both for a friend. I'll email it to you.
There are definitely points in the spreadsheet where it stops being a good idea to buy more new machines and instead becomes a better idea to add more RAM to your existing machines. So the GA solution would somehow need to take into account the number and type of machines available at a given time T in order to optimize what should happen at time T+1.
That's all in how you decide to specify the system state vector and evaluate costs.
SA and GA approaches represent "solutions" to the task as long strings of numbers (vectors). How you translate a vector to a real system configuration is up to you; the GA or SA, on the other hand, just needs the vector, and doesn't care how its interpreted.
One approach is to just have two numbers, specifying the number of machines and the RAM per machine. Another approach is to use variable-length vectors and have one (speed,RAM) pair per entry. A myriad of other approaches are possible. You just have to have a black-box function that can evaluate how well the configuration specified by a given vector would perform. Both GA and SA approaches work by perturbing state vectors in various ways, trying to get a system with a better "performance" number. That's all they do.
The re-use of existing equipment can be taken into account when generating the "performance" number. A system that's more expensive could be deemed to "perform" worse (this isn't just compilation speed - it's an arbitrary figure of merit that you define). This would give better "performance" for systems that re-used existing hardware, and would place an upper bound on how much new hardware you could buy while still improving "performance".
This is an interesting idea. Right now this particular model is embedded in a pretty large scalability spreadsheet, but I could probably extract the key variables and formulas. What's less clear to me is how to model this over time under a GA approach.
For any GA or SA-based solution, you only need to come up with two things: a way of representing a system configuration as a vector, and a way of figuring out how "good" the solution represented by a given vector is. Plug these in, and watch it go
hmmm.. interesting....! Which model are we talkin about here?
CAVEAT: Bear in mind that I've only taken one systems course, so my terminology and descriptions may be a bit off, and I won't know about the more advanced techniques...
The idea is to represent your system as a series of processing nodes with task queues, and to see what happens as you send tasks through the system. Based on the length of time spent at each node for the different classes of tasks you're sending around (specified as a probability distribution), you get the average "utilization" of each node (how much of the time it's being used), the average queue length at each node, and so forth. This helps you find system bottlenecks for any given configuration.
Best of all, the math that produces these statistics is straightforward enough that, with a few approximations, it works even for very large systems. This is what your off-the-shelf software packages will handle. You can vary the design of the system, and the software will rapidly tell you how the change affected the system "hot spots".
For small systems and coarse approximations (exponential/memoryless probability distributions), you can even work out a lot of this by hand.
In this context, I'd probably declare the compiling machines to be nodes, and use existing task data to come up with a (back of the envelope) probability distribution for task lengths on the various machines. Questions like "what's the point of diminishing returns for adding nodes?" and "what happens if I change the paths of task flow like *this*?" can be easily answered from there.
I'd be interested to know though, for anyone who has experience with FPGA, if the best FPGA tech would be capable of creating even a general purpose embedded CPUs like the Z80.
Sure, easily. Current top-of-the-line FPGAs let you synthesize designs with on the order of a million gates or so.
People have been writing papers about chips with reconfigurable parts for many years. The idea continues to show promise, but the practical problems with actually _using_ something like this are great, and the benefits aren't amazingly spectacular.
You can buy modules containing integrated processor cores and FPGA logic already from Altera and the other big FPGA companies.
The best I've come up with is a glorified spreadsheet that estimates total build time and lets me tweak #of machines and # of split-up jobs, and watch the bottom line change. Gross but I can't think of anything better.
Have you considered writing a script that tries to optimize this for you?
I've hacked together SA-based optimizers in Perl on occasion for similar tasks.
Whether this is effective for you depends on how much time you'd spend scanning solutions by other methods (a script like this takes anywhere from a couple of hours to a couple of days to write, depending on complexity).
This is the kind of job queueing theory was designed for. Pick up a textbook from your local university bookstore, if you're interested in the topic. This will let you fairly easily get estimates of how varying system parameters affect performance.
I'm afraid I don't know what commercial packages handle this, though. We used a high-level system simulation tool called "MAP", but it wasn't very intuitive to use. Better solutions certainly exist.
What use is this? Talk about esoteric. If it helps us get closer to a Unified Theory, OK, I'm all for it. If it gets us closer to practical Fusion Power, I'm all for it. The article doesn't say what we can do with this knowledge.
Why does that make this any less interesting?
If you want the pedantic argument, then yes, this does bring us closer to fusion power by improving our understanding of nuclear forces and giving us new data points to test our models with, but that's secondary.
As I have tried to post twice, MIT Tech Review has an article regarding the ability to use an inkjet printer to print a semiconductor chip.
:)
It is a very interesting read and even speaks to the possibility of this allowing open source cpu's in the future. Imagine, downloading and printing the latest version of your cpu before upgrading to the n.n kernel it is targeted at
The problem with this technology is that even if you can shrink an inkjet printer head to the point where you're laying down 0.18-micron dots, you'll have one heck of a time keeping the environment clean enough for your fabbed chip to work. This is one of the main reasons why semiconductor fabs are so expensive (though other factors definitely contribute).
If you're printing at anything other than deep submicron linewidth... your chips will be useless. Maximum operating frequency, to a rough approximation, goes up as the inverse square of the linewidth. Make the linewidth 100 times wider, and your chip will run about 10000 times slower. You're not going to be playing quake on an inkjet-printed chip any time soon.
This technology is extremely useful for making things like active-matrix displays and cheap "smart" devices, but that's about it.
Now, the silver lining. You _can_ fab moderately complex chips using Field Programmable Gate Arrays. These have been around for a long time, and are frequently used for prototyping. You'll get something a tenth the complexity and a fifth the speed of a real chip, but that's still enough for many applications (program yourself a sound card with nifty new features, or emulate an older gaming system or computer in hardware). This will also give you a training tool for gearing up for the real thing (true IC design and fabrication).
Fabbing ICs is impractical for individuals, but possible for organizations. It'll cost you about $500k or so once you have a finished, debugged design to produce a few hundred thousand chips (a couple of wafer runs; the first one or two runs will be buggy alpha silicon which you test and revise).
I remember, years ago, during the (seeming) height of the US military's interest in rail guns (and Popular Science, etc., etc...) a small group of college students with a more efficient answer...
:)).
it was a COIL Gun.
Really the same basic idea as a rail gun, but they 'wrapped' the rails around the payload to get more efficient use of the electromotive force -- more 'bang for your watt,' so to speak.
Actually, the operating principle of the version I've heard of was quite different. Railguns use the "motor principle" that you learned about in high school. Coilguns use Lenz's Law repulsion between coils and a conducting projectile (which you probably also learned about in high school
That, and it looked more like a gun barrel. It was so much cooler looking!
I thought of a way to up the coolness factor:
The Gauss Nerf (tm).
Drew up schematics a year or so ago. I'll get around to building it Really Soon Now, honest...
(It would fire giant Nerf darts with 50g aluminum cylinders in them fast enough to be entertaining. The challenge is to keep it slow enough not to break windows.)
If I remember right (It's been few years since I worked on this), for higher rates of speed it's impossible to use a coilgun. Reason? It's less efficient. The coilgun might impart energy to the projectile better, but the coilgun wastes more energy getting to the projectile. As a result, at higher speeds, a coilgun will basically melt itself.
Nothing that I know of about coilguns would cause a fundamental limit to projectile velocity, and I've done the calculations fairly recently.
The only requirement is that your coil field alternate many times while the projectile is within interaction range of it. While this causes frequency to go up with projectile velocity for a fixed coil size, you can just use a larger projectile and bigger coils spaced farther apart to build a gun that can handle higher speeds at lower frequencies.
Railguns are horrible. I've done the calculations for those, too. You need truly, truly silly currents to generate a useful amount of force, which means that your rails will degrade rapidly and that spot-welding of the projectile will be a big problem. You'll also have the very difficult task of figuring out a way to keep your projectile in good, conducting contact with the rails while sliding along at a few km/sec. The only even remotely practical approach to this I've seen is to send current through a plasma arc behind the projectile instead of the projectile itself, but that'll degrade the rails even more quickly.
Coilguns are much nicer to deal with electrically, and tend to have much higher accelerations (thus making the gun much more compact).
As for inefficiency... I can't see where this comes from, either (perhaps you could post a link?). As long as the projectile occupies most of the area inside the solenoid, and you're operating at frequencies high enough to make inductive and capacitive effects dominate resistive ones, and you're operating at frequencies low enough not to radiate power into the environment, most of your energy should go to the projectile.
Finally, even an inefficient gun - rail or coil - wouldn't have much of a heating problem if active cooling was used. Even a very fast projectile has relatively little energy invested in it. Even if you waste as much energy as you send into the projectile (or more), your gun only heats up by a few tens of degrees per shot, at most (for orbital-velocity slugs).
Really, this is nothing special. Seriously, I came up with a primitive, if completely non-effective, idea for the same thing in a high school science project. Essentially, it'd just be a series of solonoids powered up and down in order so as to propel a "bullet" forward through a barrel.
The operating principles for a true coilgun are a bit different from your standard nailgun. A coilgun of the kind you seem to be describing works on ferromagnetic projectiles, using more or less DC effects. Apply a field to a coil in front of the projectile, and let it pull the projectile along.
Among other things, barrel friction from the dragged projectile is a problem here.
The coilgun designs from this university group use the Lenz's Law repulsion between a conducting projectile and an _alternating_ magnetic field. The projectile doesn't touch the gun barrel, which gets rid of a lot of the problems that railguns have.