While water *can* be a problem in oil, once you heat the oil past 212F for any length of time, it's *gone*.
Except that the oil is in constant use. If it isn't, then it's oxidizing. Our oil got about one pass through a filter machine before it was completely replaced. Other restaurants may be uncool enough to leave oil sitting for long periods of time, but those tend to be the same ones with tons of carbon floating on top (yuck).
Then again, if you're frying at 212F, I don't want to eat in that restaurant.
I'm not even sure if that's hot enough to clarify the oil...
Remember the three magic words to making high speed 3D graphics work: "Cheat like hell" I'd actually done some research into this area not so long ago (most of which I can't remember) and I found that about 95% of calculations can be stored in lookup tables, or calculated once for all rays. I don't remember all the details of my evil plan (I really need to start writing this stuff down) but I had pivoted the calculations in such a way as to make multiple, pipeline friendly passes.
The first stage or two got most of the predictable calculations out of the way, Most of these were length calculations for all objects within the bounding area. These calculations were then reused in the next step where the rays were actually cast. Since most of the info had been precalculated at an O(objects) performance, the number of computations for the O(rays) operation was reduced. I think I left myself with a multiplication or two, plus a square root from a lookup table. Obviously the algorithm assumed that the number of spatial objects within the bounding area was significantly less than the number of rays being cast. (A fair assumption in raytracing.)
In the end, the point was to not only precalculate as much as possible, but to also avoid any unnecessary jumps in the code. By making the entire algorithm as linear as possible, I planned to make full use of a super-deep pipeline like those present in GPU and DSP chips. The performance results of such a pipeline would put a modern Pentium IV to shame. In the end, I gave up for want of a programmable graphics card. Cg was brand new, and my current NVidia GeForce 2 wasn't programmable enough for experimentation.
Antialiasing is difficult, but not insurmountable. I don't know if my algorithm would have been fast enough to allow a 4x antialias pass, but I'm not sure it's relevant. If a raytracing standard were deployed to developers today, some games would take advantage of it. These games would then drive the development of better hardware designs for raytracing. Even if the idea flopped, the only risk would be in writing a new set of drivers for a GPU.
The ice that is pervasive throughout the nuggets and fries melts during a deep fry and gets trapped under the surface. This dilutes the oil and reduces the overall quality. As the oil cools and hardens, the water remains trapped inside the oil.
A common acronym for remembering the enemies of oil is SWAtCH, or Salt, Water, Air, Carbon, and Heat.
In fact, with per-pixel shading, modern GPUs practically *are* raytracers.
Which is basically my problem with current cards. Programming them has become exceedingly complex because they stick to a polygon/raster model instead of simply declaring rays outright.
Maybe; or maybe you cancel your service with them and take your phone somewhere else.
And pay the penalty for breaking your contract. That penalty covers the provider's cost for the phone.
Finally, in terms of what it makes sense to run on the Sun hardware - the Linux kernel has a boatload of functionality not found in Solaris.
Really? Like what? Linux is a decent OS on Intel hardware. But when it comes to SPARC hardware, Solaris can still scale higher, use more memory, run more threads, and support more processors than Linux can currently even hope to touch. Solaris has this advantage because the hardware and the OS were built in tandem. Now if all you've ever used was Solaris x86, you might be tempted to think that Linux is better. But if you've watched a Sparc Solaris machine kick out half a million transactions per second without even breaking a sweat, you'll quickly change your mind on what you want in your server room.
went into a KFC about a decade ago - at the height of the California Raisin's meteoric rise to fame, and KFC was giving away Raisin dolls. Guess that must have been more than 10 years.
I'm pretty sure that was Hardee's, not KFC. I still have a bunch of those stupid raisins somewhere. Hardee's did have chicken wings, so that may be adding to your confusion.
Given your description of restaurant oil, and how nasty it may be on a car's engine, I take it you never eat in those establishments.
Eat? Hell, I used to work in one of those establishments as a teenager. The quality of the oil is just fine for food as long as it's regularly filtered and changed. The problem with reusing it for bio-diesel is that the stuff in the grease bin is the left-over crap that needs to be disposed of. Vegetable oil is great as clear, freshly pressed stuff. I just wouldn't count on the old stuff as being of much use.
I'll grant you that I haven't spent too much time investigating all the new shader languages. However, I have poked at Cg, and it simply wasn't general purpose enough to meet the needs of a high performance raytracer. For maximum performance, a general purpose, real-time raytracing engine would need to be able to reprogram and reuse all of the card's pipelines, not just the vertex shader.
claims biodiesel has almost the same amount of energy as petroleum-based diesel, but cleans an engine's fuel injectors and cuts down on the number of required oil changes.
Have these people seen the crap-for-oil that comes out of most restaurants? That stuff is fully oxidized, saturated with carbon, mixed with salt, and diluted by water! How anyone could expect it to clean anything is beyond me.
First, Why? Most people don't even make movies that are raytraced.
Because current methods are getting too complex. The shear number of details in writing a modern 3D engine is daunting, even to an experienced 3D coder. A raytracer would allow you to hit a big reset button and go back to times that were simpler. As a bonus, quality could eventually be taken much farther than today's polygon/shader methods.
And, photon mapping and similar techniques are much more sophisticated than raw raytracing.
Raw raytracing is rarely done as raw raytracing. Texture engines such as bump mapping, photon mapping, highlighting, reflection, etc. are often applied. Hell, raytracing invented most of these engines. The difference is that many of these features can be planned for by an artist rather than a coder. A few clicks in their design tool, and the artist replicates what used to take a coder weeks of work. This streamlines the process and reduces the time it takes to get the product out the door.
But in order to make this 'marketing trick' viable, the software provider must ensure that it is not possible to replace their software with an alternative. To do this requires Trusted (as in supervised) Computing - a DRM'd BIOS that is out of the user's control for example.
You're being ridiculous. You still pay your cell phone provider for service, even if you hack your phone, don't you? And you'll still pay Sun for the software, even if you load something else on the hardware. That being said, the deals I've seen so far are all Sun gear. While you could load Linux on there, Solaris just makes sense.
Call me when NVidia and ATI open up their specs so I can finally code that real time raytracing engine I've been dreaming of. Otherwise, you're just tweaking OpenGL or DirectX until the cows come home.
Actually, I'm a bit surprised that the big names haven't started looking at raytracing. Sure, it has a reputation for being slow, but graphics technology has grown by leaps and bounds. Combined with about 5 billion caching and approximation tricks, and the fact that ray tracing is a highly parallel operation, I'm thinking that we should already have games that are raytraced.
Don't fret too much. By shunting the price of the hardware into the software, Sun is pulling a quick marketing trick to make you think that the hardware is becoming cheap. The reality is that you're still paying the same costs for the hardware and software combo, you're just "feeling good" about it.
Geronimo, you're third, after JBoss and Jonas. No big news, just a project which, after virtually one year of over-hype, becomes serious at last:)
Yes and no. JoNaS was originally something of a quicky "proof of concept" container. I'm not sure what's happened to it since, but it didn't used to be a realistic choice for any serious deployments.
JBoss has always been entangled in a lot of B.S. politics and would appear to have been intentionally obfuscated to help bolster their support model. I think that Rickard (the guy who did most of the original work) really wanted to create the cleanest and most powerful server possible. He resigned quite a long time ago, and has been pestered by (and pestering) JBoss ever since.
Where does this leave Geronimo? Well, this makes it the first Open Source J2EE server that can be used as a basis for other projects, as well as legally bundled with J2EE applications. This spells a huge boon for both the common developer and the large corporation.
A sufficiently powerful light source will be able to overload the amplifier, with some luck taking it out permanently.
As I said here, modern Night Vision gear contains circuitry to prevent overloads like the one you're describing. All you'd do is make the employees mad, and possibly get yourself thrown out.
Remember, no one uses Generation 0 gear anymore. As a result, the amplification is an active process that can be controlled via an upper limit on the amplification voltage.
Most modern night vision gear contains circuitry to protect against bright flashes of light (a previously effective method for disabling night vision). Leaving a bunch of IR transmitters around would merely result in them getting confiscated, and possibly your ass getting permanently thrown out.
A much better suggestion is the use of a fibre-optic lens that would be hooked into a recorder under your coat. The optics could then be attached to something inconspicuous (like a lapel pin). Of course, that seems like a lot of work to go through just to record a movie for your "warez" buds.
So, if the goggles intensify the light then wear all black, use a camcorder that is black and isn't showing any light. then they can't see it.
Good luck finding "true-black" stealth paint. Most black plastics reflect so much light as to actually produce specular highlights. Not to mention emissions for camera auto-focusing and preview screen. Assuming you found a way around all of that, the fact that you're holding something up to the screen would tend to give you away. On a night scope, you'd probably stick out like a sore thumb.
It won't help. Most Night Vision Goggles are of the Image Intensifier type. These work by amplifying very small amounts of light. Infrared is more useful in tracking living creatures by their heat emissions.
Here's attempt #2. Safari ate my previous version.:-(
I'm not sure what you mean. You're right that the speed of light (c) is invariant, but relativistic mass is not (it is dependent upon velocity).
I see what you mean. You're correct, the mass does change as the object accelerates. However, both E=mc2 and KE=(mv2)/2 define the energy for the rest mass (or current mass) of an object. It is very difficult to know what the rest mass of an object really is, because we don't know what fraction of c we are really traveling at any given time. If we accelerate or slow down, we only have the reference stars and planets to define our motion. Light continues to exceed our own speed by 300,000 km per second, thus confounding our attempts to measure our speed. Only a third party observer (e.g. a particle accelerator operator) would need to account for relativistic mass differences.
I think this is accurate, which is perhaps part of why I don't understand your previous derivations for "Total Energy in a System = mv2" and "E=mc2"?
I'll try to explain this better. We start with the equation KE=(mv2)/2. But where does the '/2' come from? The answer is in Newtonian physics, "every action has an opposite and equal reaction". A perfect example of this is a rocket. The exhaust must travel at a much higher velocity than the rocket, so that a smaller amount of particles can impart a large amount of energy on a larger rocket. Or in other words:
Mr = rocket maass Vr = rocket velocity Me = exhaust mass Ve = exhaust velocity
(Mr * Vr)/2 = (Me * Ve)/2
Thus the total energy in the situation (minus any calculations for existing energy) is:
E = mv2
Now what if you noticed that a given mass always had a velocity of light speed? Since that's exactly what happens in 4D space, you could then replace 'v' with a constant:
E = mc2
I'm still confounded by time stopping at c even though light goes at c and interacts with our frame of reference; i.e. there is a sequence (implying time) to the existence of light no matter how dilated time may be in its frame of reference. Perhaps light itself is just a special case? I guess more study is simply required of me.:)
It makes more sense once you realize that the forth dimension is just another dimension of space. There is no "before" and "after", merely every point that every piece of matter will ever cross. For example, think of a photon reflecting off a mirror. We think of it "approaching the mirror", then "striking the mirror", then "deflected from the mirror". But in 4D space, there is only a line that angles toward the mirror, then away. This line describes where the photon was, is, and will be.
What you consider "before" and "after", is actually a concept known as "causality". Causality is the theory that the 4th dimension is built like a tower. i.e. Every "slice" of space is dependent on the previous "slice". Thus, it ends up looking like the Universe is a lot like a computer simulation, where you can run it through and have a static set of data describing every moment. If you run it through again, you get the same results.
This raises quite a few questions, however. Could an intelligent mind capable of changing the universe exist in such a design, or are they merely part of the "program" and therefore must exist? Einstein believed the later. He stated, "I do not believe in a God who plays dice with the Universe." To which Neils Bohr replied, "Who are we to tell God how to run his Universe?"
You see, the emergence of Quantum Physics threw a monkey wrench in Einstein's beautiful, but static universe. Suddenly, nothing was static, but rather governed by chaos and chance. Some physicists, such as Dr. Hawkings, believe that this shows that Einstein's belief of an intelligently designed universe is faulty. What Dr. Hawkings, Einstein, and many "pre-destinationists" fail to realize, is that the Biblical God claimed
Grr.... Slashdot just doesn't like ASCII Art! One last try here:
0----> *****> ****/ ***/ **/ */ 0
Ignore the stars. Those are simply there to line up the characters properly. As you can see, someone from overhead would see two lines that look exactly the same. But from our sideways vantage point, we can see that the distances are quite different.
Do you think anyone obtaining his services wants a good, impartial report? Well, a good one probably, but definitely not an impartial one.
Perhaps in a field other than computers. He made the mistake of putting his name on it instead of the name of his institute. Any attempts to peddle his services in the tech industry will lead right back to his poor handling of this case. i.e. His credibility is shot.
Actually, the extrapolation procedure doesn't work too bad. It's just a matter of connecting the dots. I have a book from 20+ years ago about the future of video games. Some of the claims were:
Games could allow more than two players. Perhaps even enough to play a full game of soccer or football! (The picture showed a "dome" with controls in a ring around it.)
Games will be able to be played over great distances! (The picture showed a chess board with a wireless antenna on it.)
Games will be so much more realistic! (Shows a handheld game with a full scene of a motor bike jumping a dirt ramp.)
None of these predictions were wrong per say. Rather, the author failed to connect the dots and follow the the most likely path of games. Why have an arcade machine with 15 control sets when you can simply hook machines together over long distances? Why have a chess board with an antenna when you can play the same thing on your super-realistic, Hi-Res, 3D screen?
The future of computer technology has always been known. It's simply been a matter of developing the power to do it. The only failure of the visionaries was in their lack of understanding market conditions and forces. They thought of each technology in a vacuum and didn't put them together as actually happened.
Slashdot Mirror
While water *can* be a problem in oil, once you heat the oil past 212F for any length of time, it's *gone*.
Except that the oil is in constant use. If it isn't, then it's oxidizing. Our oil got about one pass through a filter machine before it was completely replaced. Other restaurants may be uncool enough to leave oil sitting for long periods of time, but those tend to be the same ones with tons of carbon floating on top (yuck).
Then again, if you're frying at 212F, I don't want to eat in that restaurant.
I'm not even sure if that's hot enough to clarify the oil...
Remember the three magic words to making high speed 3D graphics work: "Cheat like hell" I'd actually done some research into this area not so long ago (most of which I can't remember) and I found that about 95% of calculations can be stored in lookup tables, or calculated once for all rays. I don't remember all the details of my evil plan (I really need to start writing this stuff down) but I had pivoted the calculations in such a way as to make multiple, pipeline friendly passes.
The first stage or two got most of the predictable calculations out of the way, Most of these were length calculations for all objects within the bounding area. These calculations were then reused in the next step where the rays were actually cast. Since most of the info had been precalculated at an O(objects) performance, the number of computations for the O(rays) operation was reduced. I think I left myself with a multiplication or two, plus a square root from a lookup table. Obviously the algorithm assumed that the number of spatial objects within the bounding area was significantly less than the number of rays being cast. (A fair assumption in raytracing.)
In the end, the point was to not only precalculate as much as possible, but to also avoid any unnecessary jumps in the code. By making the entire algorithm as linear as possible, I planned to make full use of a super-deep pipeline like those present in GPU and DSP chips. The performance results of such a pipeline would put a modern Pentium IV to shame. In the end, I gave up for want of a programmable graphics card. Cg was brand new, and my current NVidia GeForce 2 wasn't programmable enough for experimentation.
Antialiasing is difficult, but not insurmountable. I don't know if my algorithm would have been fast enough to allow a 4x antialias pass, but I'm not sure it's relevant. If a raytracing standard were deployed to developers today, some games would take advantage of it. These games would then drive the development of better hardware designs for raytracing. Even if the idea flopped, the only risk would be in writing a new set of drivers for a GPU.
If all the money is made with software, hardware-only vendors (such as Intel) will be in serious trouble.
And where will the software vendors get their hardware from?
Intel is actually rather unique as most processor vendors are relative unknowns to consumers.
How the hell does one dilute oil with water?
The ice that is pervasive throughout the nuggets and fries melts during a deep fry and gets trapped under the surface. This dilutes the oil and reduces the overall quality. As the oil cools and hardens, the water remains trapped inside the oil.
A common acronym for remembering the enemies of oil is SWAtCH, or Salt, Water, Air, Carbon, and Heat.
In fact, with per-pixel shading, modern GPUs practically *are* raytracers.
Which is basically my problem with current cards. Programming them has become exceedingly complex because they stick to a polygon/raster model instead of simply declaring rays outright.
Maybe; or maybe you cancel your service with them and take your phone somewhere else.
And pay the penalty for breaking your contract. That penalty covers the provider's cost for the phone.
Finally, in terms of what it makes sense to run on the Sun hardware - the Linux kernel has a boatload of functionality not found in Solaris.
Really? Like what? Linux is a decent OS on Intel hardware. But when it comes to SPARC hardware, Solaris can still scale higher, use more memory, run more threads, and support more processors than Linux can currently even hope to touch. Solaris has this advantage because the hardware and the OS were built in tandem. Now if all you've ever used was Solaris x86, you might be tempted to think that Linux is better. But if you've watched a Sparc Solaris machine kick out half a million transactions per second without even breaking a sweat, you'll quickly change your mind on what you want in your server room.
went into a KFC about a decade ago - at the height of the California Raisin's meteoric rise to fame, and KFC was giving away Raisin dolls. Guess that must have been more than 10 years.
I'm pretty sure that was Hardee's, not KFC. I still have a bunch of those stupid raisins somewhere. Hardee's did have chicken wings, so that may be adding to your confusion.
Given your description of restaurant oil, and how nasty it may be on a car's engine, I take it you never eat in those establishments.
Eat? Hell, I used to work in one of those establishments as a teenager. The quality of the oil is just fine for food as long as it's regularly filtered and changed. The problem with reusing it for bio-diesel is that the stuff in the grease bin is the left-over crap that needs to be disposed of. Vegetable oil is great as clear, freshly pressed stuff. I just wouldn't count on the old stuff as being of much use.
I'll grant you that I haven't spent too much time investigating all the new shader languages. However, I have poked at Cg, and it simply wasn't general purpose enough to meet the needs of a high performance raytracer. For maximum performance, a general purpose, real-time raytracing engine would need to be able to reprogram and reuse all of the card's pipelines, not just the vertex shader.
claims biodiesel has almost the same amount of energy as petroleum-based diesel, but cleans an engine's fuel injectors and cuts down on the number of required oil changes.
Have these people seen the crap-for-oil that comes out of most restaurants? That stuff is fully oxidized, saturated with carbon, mixed with salt, and diluted by water! How anyone could expect it to clean anything is beyond me.
First, Why? Most people don't even make movies that are raytraced.
Because current methods are getting too complex. The shear number of details in writing a modern 3D engine is daunting, even to an experienced 3D coder. A raytracer would allow you to hit a big reset button and go back to times that were simpler. As a bonus, quality could eventually be taken much farther than today's polygon/shader methods.
And, photon mapping and similar techniques are much more sophisticated than raw raytracing.
Raw raytracing is rarely done as raw raytracing. Texture engines such as bump mapping, photon mapping, highlighting, reflection, etc. are often applied. Hell, raytracing invented most of these engines. The difference is that many of these features can be planned for by an artist rather than a coder. A few clicks in their design tool, and the artist replicates what used to take a coder weeks of work. This streamlines the process and reduces the time it takes to get the product out the door.
I have read. That's why I'm complaining.
But in order to make this 'marketing trick' viable, the software provider must ensure that it is not possible to replace their software with an alternative. To do this requires Trusted (as in supervised) Computing - a DRM'd BIOS that is out of the user's control for example.
You're being ridiculous. You still pay your cell phone provider for service, even if you hack your phone, don't you? And you'll still pay Sun for the software, even if you load something else on the hardware. That being said, the deals I've seen so far are all Sun gear. While you could load Linux on there, Solaris just makes sense.
Call me when NVidia and ATI open up their specs so I can finally code that real time raytracing engine I've been dreaming of. Otherwise, you're just tweaking OpenGL or DirectX until the cows come home.
Actually, I'm a bit surprised that the big names haven't started looking at raytracing. Sure, it has a reputation for being slow, but graphics technology has grown by leaps and bounds. Combined with about 5 billion caching and approximation tricks, and the fact that ray tracing is a highly parallel operation, I'm thinking that we should already have games that are raytraced.
Don't fret too much. By shunting the price of the hardware into the software, Sun is pulling a quick marketing trick to make you think that the hardware is becoming cheap. The reality is that you're still paying the same costs for the hardware and software combo, you're just "feeling good" about it.
Geronimo, you're third, after JBoss and Jonas. No big news, just a project which, after virtually one year of over-hype, becomes serious at last :)
Yes and no. JoNaS was originally something of a quicky "proof of concept" container. I'm not sure what's happened to it since, but it didn't used to be a realistic choice for any serious deployments.
JBoss has always been entangled in a lot of B.S. politics and would appear to have been intentionally obfuscated to help bolster their support model. I think that Rickard (the guy who did most of the original work) really wanted to create the cleanest and most powerful server possible. He resigned quite a long time ago, and has been pestered by (and pestering) JBoss ever since.
Where does this leave Geronimo? Well, this makes it the first Open Source J2EE server that can be used as a basis for other projects, as well as legally bundled with J2EE applications. This spells a huge boon for both the common developer and the large corporation.
A sufficiently powerful light source will be able to overload the amplifier, with some luck taking it out permanently.
As I said here, modern Night Vision gear contains circuitry to prevent overloads like the one you're describing. All you'd do is make the employees mad, and possibly get yourself thrown out.
Remember, no one uses Generation 0 gear anymore. As a result, the amplification is an active process that can be controlled via an upper limit on the amplification voltage.
Most modern night vision gear contains circuitry to protect against bright flashes of light (a previously effective method for disabling night vision). Leaving a bunch of IR transmitters around would merely result in them getting confiscated, and possibly your ass getting permanently thrown out.
A much better suggestion is the use of a fibre-optic lens that would be hooked into a recorder under your coat. The optics could then be attached to something inconspicuous (like a lapel pin). Of course, that seems like a lot of work to go through just to record a movie for your "warez" buds.
So, if the goggles intensify the light then wear all black, use a camcorder that is black and isn't showing any light. then they can't see it.
Good luck finding "true-black" stealth paint. Most black plastics reflect so much light as to actually produce specular highlights. Not to mention emissions for camera auto-focusing and preview screen. Assuming you found a way around all of that, the fact that you're holding something up to the screen would tend to give you away. On a night scope, you'd probably stick out like a sore thumb.
It won't help. Most Night Vision Goggles are of the Image Intensifier type. These work by amplifying very small amounts of light. Infrared is more useful in tracking living creatures by their heat emissions.
Here's attempt #2. Safari ate my previous version. :-(
:)
I'm not sure what you mean. You're right that the speed of light (c) is invariant, but relativistic mass is not (it is dependent upon velocity).
I see what you mean. You're correct, the mass does change as the object accelerates. However, both E=mc2 and KE=(mv2)/2 define the energy for the rest mass (or current mass) of an object. It is very difficult to know what the rest mass of an object really is, because we don't know what fraction of c we are really traveling at any given time. If we accelerate or slow down, we only have the reference stars and planets to define our motion. Light continues to exceed our own speed by 300,000 km per second, thus confounding our attempts to measure our speed. Only a third party observer (e.g. a particle accelerator operator) would need to account for relativistic mass differences.
I think this is accurate, which is perhaps part of why I don't understand your previous derivations for "Total Energy in a System = mv2" and "E=mc2"?
I'll try to explain this better. We start with the equation KE=(mv2)/2. But where does the '/2' come from? The answer is in Newtonian physics, "every action has an opposite and equal reaction". A perfect example of this is a rocket. The exhaust must travel at a much higher velocity than the rocket, so that a smaller amount of particles can impart a large amount of energy on a larger rocket. Or in other words:
Mr = rocket maass
Vr = rocket velocity
Me = exhaust mass
Ve = exhaust velocity
(Mr * Vr)/2 = (Me * Ve)/2
Thus the total energy in the situation (minus any calculations for existing energy) is:
E = mv2
Now what if you noticed that a given mass always had a velocity of light speed? Since that's exactly what happens in 4D space, you could then replace 'v' with a constant:
E = mc2
I'm still confounded by time stopping at c even though light goes at c and interacts with our frame of reference; i.e. there is a sequence (implying time) to the existence of light no matter how dilated time may be in its frame of reference. Perhaps light itself is just a special case? I guess more study is simply required of me.
It makes more sense once you realize that the forth dimension is just another dimension of space. There is no "before" and "after", merely every point that every piece of matter will ever cross. For example, think of a photon reflecting off a mirror. We think of it "approaching the mirror", then "striking the mirror", then "deflected from the mirror". But in 4D space, there is only a line that angles toward the mirror, then away. This line describes where the photon was, is, and will be.
What you consider "before" and "after", is actually a concept known as "causality". Causality is the theory that the 4th dimension is built like a tower. i.e. Every "slice" of space is dependent on the previous "slice". Thus, it ends up looking like the Universe is a lot like a computer simulation, where you can run it through and have a static set of data describing every moment. If you run it through again, you get the same results.
This raises quite a few questions, however. Could an intelligent mind capable of changing the universe exist in such a design, or are they merely part of the "program" and therefore must exist? Einstein believed the later. He stated, "I do not believe in a God who plays dice with the Universe." To which Neils Bohr replied, "Who are we to tell God how to run his Universe?"
You see, the emergence of Quantum Physics threw a monkey wrench in Einstein's beautiful, but static universe. Suddenly, nothing was static, but rather governed by chaos and chance. Some physicists, such as Dr. Hawkings, believe that this shows that Einstein's belief of an intelligently designed universe is faulty. What Dr. Hawkings, Einstein, and many "pre-destinationists" fail to realize, is that the Biblical God claimed
Grr.... Slashdot just doesn't like ASCII Art! One last try here:
0---->
*****>
****/
***/
**/
*/
0
Ignore the stars. Those are simply there to line up the characters properly. As you can see, someone from overhead would see two lines that look exactly the same. But from our sideways vantage point, we can see that the distances are quite different.
You're repeating what I said. The book wasn't wrong. It was simply off on how those technologies would be combined.
Do you think anyone obtaining his services wants a good, impartial report? Well, a good one probably, but definitely not an impartial one.
Perhaps in a field other than computers. He made the mistake of putting his name on it instead of the name of his institute. Any attempts to peddle his services in the tech industry will lead right back to his poor handling of this case. i.e. His credibility is shot.
None of these predictions were wrong per say. Rather, the author failed to connect the dots and follow the the most likely path of games. Why have an arcade machine with 15 control sets when you can simply hook machines together over long distances? Why have a chess board with an antenna when you can play the same thing on your super-realistic, Hi-Res, 3D screen?
The future of computer technology has always been known. It's simply been a matter of developing the power to do it. The only failure of the visionaries was in their lack of understanding market conditions and forces. They thought of each technology in a vacuum and didn't put them together as actually happened.