You probably would have to pay fees, but not because of the exchange from device to device. Rather, you'd probably have to pay for access to the Internet endpoints. Your packet would probably contain a device identifier that a provider would be able to use in tracking your usage and provide security for their endpoints. It would probably be difficult to stop someone from faking an ID, however...
As I understand it, Bluetooth merely allows for devices to find one another. It does nothing to promote exchange between devices that are not directly connected via bluetooth.
i.e. Getting my cell phone to communicate with my PDA will work, but sending an SMS message to someone two miles away won't.
That's not to say that Bluetooth isn't a good option for creating such a network.
Oddly enough, I see that as only a minor problem. In a typical city, people are close enough that Bluetooth connections would be sufficient. Here are a few of the problems I see:
1. The various networking theories still apply. Thus the network will introduce more and more latency as it grows, and the bandwidth used to keep the network up to date will eventually cause problems. This is a very similar problem to the one of GNUTella, which eventually experienced a network collapse.
2. Routing is a difficult issue to handle. Do you spam every packet to every nearby device until it makes it through? The overhead in this approach would be extraordinary. Thus a more intelligent algo must be used. Perhaps the nearest Internet connection point could provide some form of network organization from its vantage point?
3. Power, the antagonist of every electronic device. Phones currently spend a minor amount of power maintaining an established connection. What would happen to a device's power supply if it were suddenly required to handle all sorts of packet communications and network updates?
Those are a few on my thoughts, anyway.
BTW, it seems I'm an enemy of yours. What did I ever do to deserve that?
...in the possibilities of a dynamic WiFi network built out of electronic devices in close proximity. It would present a great number of engineering difficulties, but the payoff would be complete internet coverage anywhere in the world.... Well, at least anywhere there's other people present to relay the packets.
Hmm... I think there'd need to be a way of identifying open Internet points. Phones, laptops, etc. near these points would then need to broadcast their access. When a device receives a packet, it should know enough to accept or reject the route based on its current network uplinks. Bandwidth could present a problem, especially since a ton of small packet messages would be necessary to identify the current status of a given device.
Anyone know of research that's currently being done in this area?
Really? I've never tried plugging it into my Mac (I've got a tiny, portable optical mouse), but I thought that it worked fine out of the box. At the very least, my MS Optical mouse works fine under FreeBSD. If those guys can get it right, why can't the Linux guys do it?
My journal has the full details, but the problem is that it occasionally locks up after a period of use. The scary part is that the problem is well known, but no one has done anything about it. In fact, most people who complain about the problem are silently ignored.
Part of what I was trying to illustrate (in my albeit quite verbose response:) ) is that this equation is incorrect -- or, at the very least, it is not the Energy equation and it is not the Momentum equation, so where does it come from?
It's kinetic energy for both the action and the reaction. I'll have to ponder it a bit and see if I can't find a better way to prove it. I'm still convinced, however, that the E=mc2 equation is actually E=mv2.
"Light speed" is a measurement of distance over time (299,792,458 m/s). i.e. every second, light travels a certain number of meters. So I'm wondering, when an object is at rest in our frame of reference, where are the meters that the object is traversing every second?
Keep in mind that light "speed" is the one constant in all frames of reference. It is the maximum attainable velocity because it is the vector length imparted on all matter. By "accelerating" we're really only changing the direction of our four dimensional vector. Light makes a pretty good measuring stick, because its vector is limited to 3 dimensions instead of four. Thus we can "see" what the length of our vector is across all four dimensions.
By definition, they are all orthogonal dimensions so movement along one does not affect the other, though I do not see how that illustrates why we can't go backwards in time if it is just another dimension.
Exactly. Movement across one dimension does not effect the other. When you "accelerate", you merely "push" your vector in another direction. However, you are not modifying your fourth dimensional vector length at all. You are merely making yourself travel farther along the three dimensions for the same distance traveled along the fourth dimension. That's why time "dilates". You haven't actually "slowed", but instead you're covering more 3 dimensional distance in the same four dimensional distance.
Try this experiment. Grab a sheet of graph paper. Draw two lines of equal length. One points away from the center X,Y axis at 20-30 degrees. The second line points away at 85 degrees. Pretend that Y is the dimension of "time" and that X is the dimension of "space". You'll note that the first line has covered more time while the second line has covered more distance.
Now consider that the second line is a line with X velocity imparted by a rocket. Normally this would lengthen the vector as well as increase its angle. However, our universe appears to have an upper boundary of light speed. Thus the vectors remain equal in length. Now, you can thrust in the X direction till the cows come home, but you're never going to be able to impart enough thrust to get an angle of 90 degrees or higher. If you want to change directions along the Y axis, you have to thrust along the Y axis. But does anyone know how to apply opposite thrust along the Y axis? I don't. Einstein even speculated that such matter would be incapable of interacting with matter flowing in our direction.
Does that make a little more sense?
But that scenario seems almost deterministic; i.e. some input stimuli forces you to have a particular thought.
Not entirely. It just creates various feedback loops that branch off in a probabilistic fashion. For example, let's say that I think there's a monster in the hallway. I have two decisions:
1. Go light the hallway and see if there's a monster. 2. Stay in bed and hope there isn't.
Now there's a high probability of both decisions being made. Both decisions probably are made in different universes, but we'll assume that factors that define my "will" decide one over the other.
Now there is a probability of a monster being in the hallway. How probable it is depends on various factors. Let's assign a high probability to our monster in the hallway. If I make decision number 1, then a monster probably will materialize in my hallway when I check. This could be very bad for me. On the other hand, if I stay in bed, it's quite possib
Could this by any chance have anything to do with the Dark Energy "antigravity" effect that the universe appears to be experiencing? One would think that the black holes would actually help things collapse, but if they're at the outer fringes, might they be pulling things outward?
Hmm... probably a stupid question, but it never hurts to ask.
the bandwidth between an agp card and the cpu has even less bandwidth, and the amount of memory on graphics cards is usually well below system ram, making the process nto really seem like the best way to do things currently...
The necessary geometry and graphics for RayTracing works out to pretty much the same cost as polygon stuff (sometimes even smaller). Given that today's cards have 64-128MB of RAM, the memory on the card is not the issue. The bandwidth can be an issue, but no more than today's graphics. It takes a significant amount of AGP bandwidth to pump the textures and polygons to the card in the first place. Then the memory bandwidth on the card has to be enough to feed 2-16 GPU pipelines.
The GPU is very similar to a DSP chips in that it has very deep pipelines. A single jump instruction could result in a flush of one or more pipelines, thus stalling the processor. As a result, jump instructions are avoided at all costs. There has been some difficulty in modifying traditional ray tracing algorithms to avoid jump instructions. However, I (and many other graphics wizards) have been over the algorithms and it does appear that streaming ray tracer should be possible.
And learn what a stream processor is, so maybe you can understand why the mathematics actually are general purpose enough to meet those needs.
It's not about whether the GPU can do the math or not. It's about whether the GPU is programmed to do the math for raytracing or not. Many RayTracing engines have twisted OpenGL a bit to get their ray tracing operations done. Which is fine since it gives them a performance boost. But this boost is insignificant compared to what could be achieved with dedicated GPU drivers. Ever notice how games tend to get slightly faster and better every time you install a new set of NVidia drivers? This is due to NVidia optimizing the GL code. The GPU hasn't changed, nor has its onboard memory. Merely the algorithms to produce the graphics have changed.
They're using pixel shaders to do ray-triangle intersections, i.e. all of the card's pipelines. Do your homework, before you start criticizing the work of an entire industry.
Because, you know, the pixel shaders are the ONLY programs running through the GPU. *sigh*
You know, you might try calming down and having an intelligent conversation here.
Now, if your point is that dog-slow rendering is "better" than fast rendering, then pick your fight elsewhere. But don't blame the GPU for being fast, especially since it is now just as capable of high-accuracy rendering and the full richness of a software raytracer!
What am I blaming the GPU for? I just want to reprogram it and make everyone's lives easier. Sure, the scene will need to be optimized by a coder who understands, but the artist should be capable of deciding what effects will work and which won't. Simply relying on the coder to create those effects AFTER modeling is done is an inefficient process at best. At worst, it makes the coder spend a lot of time on creating effects that are inherent in a Ray Tracing engine.
And even if polygons weren't the way to go, GPUs are definitely the way to go for all computer graphics (raytraced or not). End of story.
Again, I love the GPU. When did I EVER say that I wanted it to go away? I simply want to reprogram it for use as a Ray Tracer instead of a polygon rasterizer. The way I see it, those deep, parallel pipelines and texture units are EXACTLY what the RT Doctor ordered.
Yeash. If you're going to crucify me, at least do it for what I said, not what I didn't say.
I don't think your first KE equation is valid (note that I added the "^2" which was missing from your post). Perhaps you are confusing the vector "Law of Conservation of Momentum" with the scalar "Law of Conservation of Total Energy"?
That'll teach me to proof read. Sorry, I was still annoyed about my (much more complete) post getting eaten by a crash. Let me try to smooth that out:
In 4 dimensions all matter "travels" (although that's an incorrect term, it's really just a vector length) at light speed. Thus 'v = light speed'. We'll represent 'v' as the constant 'c'. Thus:
E = mc2
Perhaps that's not quite right. But I think I'm on to something there...
Application of the Law of Conservation of Momentum to the rocket problem would be:
MeVe + MrVr = 0
Squaring the velocities changes them from a vector (which may have a negative value) to a positive scalar value.
But as I think you indicate later, time behaves entirely differently from space. Time is a unique dimension, significantly different from each of the other 3 spatial dimensions.
No, it is not different. It just appears to be.
Even with the time dilation that is necessitated by assuming the invariance of the speed of light, time can only be compressed and expanded relative to another frame of reference; we cannot stop time or travel backwards through time (as far as we know).
Two points:
1. Space is also compressed at relativistic velocities. If you travel to Alpha Centauri in 10 days, you may at first believe that you've traveling faster than light speed. But if you then measure the distance between Earth and Alpha Centauri (using the only measuring stick you have at your disposal: light), you'll find that the distance has shrunk from 4 light years to a little more than 10 light days.
2. There's a good reason why we can't change our vector to a negative value for the dimension of time. Consider a two dimensional vector problem. Let's say we are on a space ship speeding along the X axis at 10 meters per second. Now let's say we turn our space ship sideways and start thrusting along the Y axis. How much thrust must be applied along the Y axis to negate and/or reverse my velocity along the X axis?
btw: Is "causal" different from "deterministic"? Can an "effect" precede a "cause" (i.e. a non-causal event), and yet the fact that both would occur be pre-determined?
Quantum Physics claims that there is no concept of "determinism". Rather, there is a probability of a deterministic event. Amazingly enough, the Universe is rigged so that the things we take as fact (I can't walk through a wall, particles don't get created or destroyed, actions produce reactions, etc.) have the highest probability of occurring. But there is still the possibility (however small) that I will simply fall through my chair, or that matter will suddenly come into existence. (See: The Uncertainty Principle)
In fact, these sorts of oddities *do* happen at a quantum level. Since there is a lot more particles at a quantum level, the probability is higher that something strange will happen. Quantum Tunneling is a perfect example of this. A quantum particle may exceed light speed for a short period of time, and thus completely "miss" anything between its current position, and its final position after it slows down. Apparently, this is achieved by "borrowing" energy from nearby matter, then paying it back a short time later.
Similarly, particles can simply go in and out of existence. And again, the trick is that the net number of particles in the universe remains constant despi
Yeah right, we are supposed to listen to somebody who has obviously never taken a chemistry class or eaten a salad with oil & vinegar dressing??
Are we supposed to listen to an AC with little understanding of the fluid dynamics of superheated liquids? The oil is hotter and more viscous than the water. As a result, the water gets trapped under the oil and begins to mix with the products of oil breakdown. Learn to think, dammit.
I learned Forth specifically so I could hack on my PowerMac 7500's OpenFirmware. It's too bad Apple's old OF implementations were a bit buggy, but the newer PowerMacs' OF is super.
If you think that's good, you should try Sun's OpenBoot on a SPARC machine some time. Not only does it have the powers you've come to expect from OpenFirmware, but it's got purdy scalable fonts, graphics, and iis far less buggy than Mac's OF. Besides, my Mac makes me squint, and I like pure white instead of off-white.;-)
OpenFirmware is a real standard, while Intel just wants us to believe it has an 'open architecture standard' and an 'SIG' instead of conforming to an already existing, real open standard.
Not to mention that it's much cooler. You've got to love how easy it is to tell a Solaris machine to boot from ANYTHING without even an OS on the system! Boot from network? Never have to touch the machine. Boot from USB? A two line command? CDROM? Same! Boot from next years wizzigig? Done.
It's also great for saving a system. Mislink the superblock? Write a Fortran program to fix it! Need a quick calcuation done while writing your program? Write a bit of Fortran to calculate it for you! Face it, OpenFirmware is simply cooler than anything on the Intel platform, present or future.
(BTW, keep an eye out for CmdrTaco. He always shows up with his OpenBoot troll ten hours after the story has been posted. Come on Taco! You've got to get moving!;-))
I had a go some time back. [snip] I was getting around 15 seconds/frame.
I never said it was easy.:-) You have to carefully limit your rays as much as possible. With extremely complex scenes, you may even have to render only some of the pixels for each frame. However, things get much better when you get to the GPU. Most of today's cards have at least two pipelines. Some even have 16! Now raytracing is a highly parallel operation, and GPUs tend to have very deep pipelines with excellent floating point support. Combine the two with a properly tuned ray tracer, and the results should be fantastic!
Oh, and I remember one more thing. I was planning to time limit a frame rendering as if it was a hard real time system. The rays would be cast in a wide pattern so that if time ran out, most of the scene would already exist. Pixels from the previous frame could plug the hole.
It certainly seems to be an active area.
Indeed. I myself have been trying to figure this out since the days of the original Pentium. It wasn't until about 2 years ago, however, that someone actually broke the barrier and built the first realtime ray tracer. It was pixelated as all get out, but it worked. Its most interesting feature was all the curved geometry that it was capable of. The graphics were so pretty that I would have liked to see a game despite its limitations.
I think that the future really is ray tracing. Time will tell.
That's not an issue of software, however, it's an issue of hardware. If you made linux run on that system, it would kick just as much ass, and possibly more.
Linux DOES run on UltraSparc. It just isn't architected for such a task. Sun has spent many years and many millions of dollars in research money making sure that Solaris is properly tuned for 4-64 processors. Solaris STILL has better thread handling than any other OS on the market (including Linux and 2000/XP).
Linux now runs on more and more "big iron" hardware and clearly it has what it takes, if people want to add support for particular platforms.
There's a difference between running and running well. It's a very important distinction to understand. Hardware fills half the gap, software fills the other. People with 20+ years of experience have made sure that both operate at peak efficiency for their target markets. Linux's target market is Intel PC hardware and it shows.
This isn't a criticism, merely a fact. If Linux were designed for Big Iron, it is doubtful that it would be much use on PC hardware (note how Solaris x86 is often called "Slow-laris"). Thus it makes the proper tradeoffs and targets the market it does best in.
Slashdot Mirror
Thanks for the info! :-)
You probably would have to pay fees, but not because of the exchange from device to device. Rather, you'd probably have to pay for access to the Internet endpoints. Your packet would probably contain a device identifier that a provider would be able to use in tracking your usage and provide security for their endpoints. It would probably be difficult to stop someone from faking an ID, however...
As I understand it, Bluetooth merely allows for devices to find one another. It does nothing to promote exchange between devices that are not directly connected via bluetooth.
i.e. Getting my cell phone to communicate with my PDA will work, but sending an SMS message to someone two miles away won't.
That's not to say that Bluetooth isn't a good option for creating such a network.
the biggest problem is signal strength/range.
Oddly enough, I see that as only a minor problem. In a typical city, people are close enough that Bluetooth connections would be sufficient. Here are a few of the problems I see:
1. The various networking theories still apply. Thus the network will introduce more and more latency as it grows, and the bandwidth used to keep the network up to date will eventually cause problems. This is a very similar problem to the one of GNUTella, which eventually experienced a network collapse.
2. Routing is a difficult issue to handle. Do you spam every packet to every nearby device until it makes it through? The overhead in this approach would be extraordinary. Thus a more intelligent algo must be used. Perhaps the nearest Internet connection point could provide some form of network organization from its vantage point?
3. Power, the antagonist of every electronic device. Phones currently spend a minor amount of power maintaining an established connection. What would happen to a device's power supply if it were suddenly required to handle all sorts of packet communications and network updates?
Those are a few on my thoughts, anyway.
BTW, it seems I'm an enemy of yours. What did I ever do to deserve that?
That's what I thought. Only Linux is lame enough to screw up MS Optical Mice. :-(
...in the possibilities of a dynamic WiFi network built out of electronic devices in close proximity. It would present a great number of engineering difficulties, but the payoff would be complete internet coverage anywhere in the world. ... Well, at least anywhere there's other people present to relay the packets.
Hmm... I think there'd need to be a way of identifying open Internet points. Phones, laptops, etc. near these points would then need to broadcast their access. When a device receives a packet, it should know enough to accept or reject the route based on its current network uplinks. Bandwidth could present a problem, especially since a ton of small packet messages would be necessary to identify the current status of a given device.
Anyone know of research that's currently being done in this area?
In OS X they require a mouse driver.
Really? I've never tried plugging it into my Mac (I've got a tiny, portable optical mouse), but I thought that it worked fine out of the box. At the very least, my MS Optical mouse works fine under FreeBSD. If those guys can get it right, why can't the Linux guys do it?
*sigh*
You mean, like this post? That was four years ago.
My journal has the full details, but the problem is that it occasionally locks up after a period of use. The scary part is that the problem is well known, but no one has done anything about it. In fact, most people who complain about the problem are silently ignored.
How about fixing USB 1.1 support in Linux first?
Agreed. And while they're at it, could they PLEASE fix Microsoft Optical Mice?
Part of what I was trying to illustrate (in my albeit quite verbose response :) ) is that this equation is incorrect -- or, at the very least, it is not the Energy equation and it is not the Momentum equation, so where does it come from?
It's kinetic energy for both the action and the reaction. I'll have to ponder it a bit and see if I can't find a better way to prove it. I'm still convinced, however, that the E=mc2 equation is actually E=mv2.
"Light speed" is a measurement of distance over time (299,792,458 m/s). i.e. every second, light travels a certain number of meters. So I'm wondering, when an object is at rest in our frame of reference, where are the meters that the object is traversing every second?
Keep in mind that light "speed" is the one constant in all frames of reference. It is the maximum attainable velocity because it is the vector length imparted on all matter. By "accelerating" we're really only changing the direction of our four dimensional vector. Light makes a pretty good measuring stick, because its vector is limited to 3 dimensions instead of four. Thus we can "see" what the length of our vector is across all four dimensions.
By definition, they are all orthogonal dimensions so movement along one does not affect the other, though I do not see how that illustrates why we can't go backwards in time if it is just another dimension.
Exactly. Movement across one dimension does not effect the other. When you "accelerate", you merely "push" your vector in another direction. However, you are not modifying your fourth dimensional vector length at all. You are merely making yourself travel farther along the three dimensions for the same distance traveled along the fourth dimension. That's why time "dilates". You haven't actually "slowed", but instead you're covering more 3 dimensional distance in the same four dimensional distance.
Try this experiment. Grab a sheet of graph paper. Draw two lines of equal length. One points away from the center X,Y axis at 20-30 degrees. The second line points away at 85 degrees. Pretend that Y is the dimension of "time" and that X is the dimension of "space". You'll note that the first line has covered more time while the second line has covered more distance.
Now consider that the second line is a line with X velocity imparted by a rocket. Normally this would lengthen the vector as well as increase its angle. However, our universe appears to have an upper boundary of light speed. Thus the vectors remain equal in length. Now, you can thrust in the X direction till the cows come home, but you're never going to be able to impart enough thrust to get an angle of 90 degrees or higher. If you want to change directions along the Y axis, you have to thrust along the Y axis. But does anyone know how to apply opposite thrust along the Y axis? I don't. Einstein even speculated that such matter would be incapable of interacting with matter flowing in our direction.
Does that make a little more sense?
But that scenario seems almost deterministic; i.e. some input stimuli forces you to have a particular thought.
Not entirely. It just creates various feedback loops that branch off in a probabilistic fashion. For example, let's say that I think there's a monster in the hallway. I have two decisions:
1. Go light the hallway and see if there's a monster.
2. Stay in bed and hope there isn't.
Now there's a high probability of both decisions being made. Both decisions probably are made in different universes, but we'll assume that factors that define my "will" decide one over the other.
Now there is a probability of a monster being in the hallway. How probable it is depends on various factors. Let's assign a high probability to our monster in the hallway. If I make decision number 1, then a monster probably will materialize in my hallway when I check. This could be very bad for me. On the other hand, if I stay in bed, it's quite possib
No, the ones detected were in the centre of galaxies...
:-)
Well, there goes that idea.
Could this by any chance have anything to do with the Dark Energy "antigravity" effect that the universe appears to be experiencing? One would think that the black holes would actually help things collapse, but if they're at the outer fringes, might they be pulling things outward?
Hmm... probably a stupid question, but it never hurts to ask.
the bandwidth between an agp card and the cpu has even less bandwidth, and the amount of memory on graphics cards is usually well below system ram, making the process nto really seem like the best way to do things currently...
The necessary geometry and graphics for RayTracing works out to pretty much the same cost as polygon stuff (sometimes even smaller). Given that today's cards have 64-128MB of RAM, the memory on the card is not the issue. The bandwidth can be an issue, but no more than today's graphics. It takes a significant amount of AGP bandwidth to pump the textures and polygons to the card in the first place. Then the memory bandwidth on the card has to be enough to feed 2-16 GPU pipelines.
The GPU is very similar to a DSP chips in that it has very deep pipelines. A single jump instruction could result in a flush of one or more pipelines, thus stalling the processor. As a result, jump instructions are avoided at all costs. There has been some difficulty in modifying traditional ray tracing algorithms to avoid jump instructions. However, I (and many other graphics wizards) have been over the algorithms and it does appear that streaming ray tracer should be possible.
Looks like I got one.
I believe is where you insert your tiresome, "So we meet again" routine. Yawn. Get some new material, will you? You're absolutely failing as a troll.
And learn what a stream processor is, so maybe you can understand why the mathematics actually are general purpose enough to meet those needs.
It's not about whether the GPU can do the math or not. It's about whether the GPU is programmed to do the math for raytracing or not. Many RayTracing engines have twisted OpenGL a bit to get their ray tracing operations done. Which is fine since it gives them a performance boost. But this boost is insignificant compared to what could be achieved with dedicated GPU drivers. Ever notice how games tend to get slightly faster and better every time you install a new set of NVidia drivers? This is due to NVidia optimizing the GL code. The GPU hasn't changed, nor has its onboard memory. Merely the algorithms to produce the graphics have changed.
They're using pixel shaders to do ray-triangle intersections, i.e. all of the card's pipelines. Do your homework, before you start criticizing the work of an entire industry.
Because, you know, the pixel shaders are the ONLY programs running through the GPU. *sigh*
You know, you might try calming down and having an intelligent conversation here.
Now, if your point is that dog-slow rendering is "better" than fast rendering, then pick your fight elsewhere. But don't blame the GPU for being fast, especially since it is now just as capable of high-accuracy rendering and the full richness of a software raytracer!
What am I blaming the GPU for? I just want to reprogram it and make everyone's lives easier. Sure, the scene will need to be optimized by a coder who understands, but the artist should be capable of deciding what effects will work and which won't. Simply relying on the coder to create those effects AFTER modeling is done is an inefficient process at best. At worst, it makes the coder spend a lot of time on creating effects that are inherent in a Ray Tracing engine.
And even if polygons weren't the way to go, GPUs are definitely the way to go for all computer graphics (raytraced or not). End of story.
Again, I love the GPU. When did I EVER say that I wanted it to go away? I simply want to reprogram it for use as a Ray Tracer instead of a polygon rasterizer. The way I see it, those deep, parallel pipelines and texture units are EXACTLY what the RT Doctor ordered.
Yeash. If you're going to crucify me, at least do it for what I said, not what I didn't say.
I don't think your first KE equation is valid (note that I added the "^2" which was missing from your post). Perhaps you are confusing the vector "Law of Conservation of Momentum" with the scalar "Law of Conservation of Total Energy"?
That'll teach me to proof read. Sorry, I was still annoyed about my (much more complete) post getting eaten by a crash. Let me try to smooth that out:
(Mr * Vr ^ 2)/2 = (Me * Ve ^ 2)/2
(Mr * Vr ^ 2) = (Me * Ve ^ 2)
KE = (mv2)/2
2 * KE = mv2
mv2 ~= (Mr * Vr ^ 2) ~= (Me * Ve ^ 2)
<--- Action Reaction --->
2 * KE = energy of action AND reaction
Total Energy = 2 * KE
E = mv2
In 4 dimensions all matter "travels" (although that's an incorrect term, it's really just a vector length) at light speed. Thus 'v = light speed'. We'll represent 'v' as the constant 'c'. Thus:
E = mc2
Perhaps that's not quite right. But I think I'm on to something there...
Application of the Law of Conservation of Momentum to the rocket problem would be:
MeVe + MrVr = 0
Squaring the velocities changes them from a vector (which may have a negative value) to a positive scalar value.
But as I think you indicate later, time behaves entirely differently from space. Time is a unique dimension, significantly different from each of the other 3 spatial dimensions.
No, it is not different. It just appears to be.
Even with the time dilation that is necessitated by assuming the invariance of the speed of light, time can only be compressed and expanded relative to another frame of reference; we cannot stop time or travel backwards through time (as far as we know).
Two points:
1. Space is also compressed at relativistic velocities. If you travel to Alpha Centauri in 10 days, you may at first believe that you've traveling faster than light speed. But if you then measure the distance between Earth and Alpha Centauri (using the only measuring stick you have at your disposal: light), you'll find that the distance has shrunk from 4 light years to a little more than 10 light days.
2. There's a good reason why we can't change our vector to a negative value for the dimension of time. Consider a two dimensional vector problem. Let's say we are on a space ship speeding along the X axis at 10 meters per second. Now let's say we turn our space ship sideways and start thrusting along the Y axis. How much thrust must be applied along the Y axis to negate and/or reverse my velocity along the X axis?
btw: Is "causal" different from "deterministic"? Can an "effect" precede a "cause" (i.e. a non-causal event), and yet the fact that both would occur be pre-determined?
Quantum Physics claims that there is no concept of "determinism". Rather, there is a probability of a deterministic event. Amazingly enough, the Universe is rigged so that the things we take as fact (I can't walk through a wall, particles don't get created or destroyed, actions produce reactions, etc.) have the highest probability of occurring. But there is still the possibility (however small) that I will simply fall through my chair, or that matter will suddenly come into existence. (See: The Uncertainty Principle)
In fact, these sorts of oddities *do* happen at a quantum level. Since there is a lot more particles at a quantum level, the probability is higher that something strange will happen. Quantum Tunneling is a perfect example of this. A quantum particle may exceed light speed for a short period of time, and thus completely "miss" anything between its current position, and its final position after it slows down. Apparently, this is achieved by "borrowing" energy from nearby matter, then paying it back a short time later.
Similarly, particles can simply go in and out of existence. And again, the trick is that the net number of particles in the universe remains constant despi
Yeah right, we are supposed to listen to somebody who has obviously never taken a chemistry class or eaten a salad with oil & vinegar dressing??
Are we supposed to listen to an AC with little understanding of the fluid dynamics of superheated liquids? The oil is hotter and more viscous than the water. As a result, the water gets trapped under the oil and begins to mix with the products of oil breakdown. Learn to think, dammit.
I learned Forth specifically so I could hack on my PowerMac 7500's OpenFirmware. It's too bad Apple's old OF implementations were a bit buggy, but the newer PowerMacs' OF is super.
;-)
If you think that's good, you should try Sun's OpenBoot on a SPARC machine some time. Not only does it have the powers you've come to expect from OpenFirmware, but it's got purdy scalable fonts, graphics, and iis far less buggy than Mac's OF. Besides, my Mac makes me squint, and I like pure white instead of off-white.
Doh! I misspoke, thanks for the correction. They both start with "Fort" and it's late at night. That's my excuse, and I'm sticking to it. ;-)
OpenFirmware is a real standard, while Intel just wants us to believe it has an 'open architecture standard' and an 'SIG' instead of conforming to an already existing, real open standard.
;-))
Not to mention that it's much cooler. You've got to love how easy it is to tell a Solaris machine to boot from ANYTHING without even an OS on the system! Boot from network? Never have to touch the machine. Boot from USB? A two line command? CDROM? Same! Boot from next years wizzigig? Done.
It's also great for saving a system. Mislink the superblock? Write a Fortran program to fix it! Need a quick calcuation done while writing your program? Write a bit of Fortran to calculate it for you! Face it, OpenFirmware is simply cooler than anything on the Intel platform, present or future.
(BTW, keep an eye out for CmdrTaco. He always shows up with his OpenBoot troll ten hours after the story has been posted. Come on Taco! You've got to get moving!
This video is also very interesting. It should be entitled, "how to make one's jaw drop". =D
Look here and I think you'll understand what's so cool about it. A hint: it's all about the geometry. :-)
I had a go some time back. [snip] I was getting around 15 seconds/frame.
:-) You have to carefully limit your rays as much as possible. With extremely complex scenes, you may even have to render only some of the pixels for each frame. However, things get much better when you get to the GPU. Most of today's cards have at least two pipelines. Some even have 16! Now raytracing is a highly parallel operation, and GPUs tend to have very deep pipelines with excellent floating point support. Combine the two with a properly tuned ray tracer, and the results should be fantastic!
I never said it was easy.
Oh, and I remember one more thing. I was planning to time limit a frame rendering as if it was a hard real time system. The rays would be cast in a wide pattern so that if time ran out, most of the scene would already exist. Pixels from the previous frame could plug the hole.
It certainly seems to be an active area.
Indeed. I myself have been trying to figure this out since the days of the original Pentium. It wasn't until about 2 years ago, however, that someone actually broke the barrier and built the first realtime ray tracer. It was pixelated as all get out, but it worked. Its most interesting feature was all the curved geometry that it was capable of. The graphics were so pretty that I would have liked to see a game despite its limitations.
I think that the future really is ray tracing. Time will tell.
That's not an issue of software, however, it's an issue of hardware. If you made linux run on that system, it would kick just as much ass, and possibly more.
Linux DOES run on UltraSparc. It just isn't architected for such a task. Sun has spent many years and many millions of dollars in research money making sure that Solaris is properly tuned for 4-64 processors. Solaris STILL has better thread handling than any other OS on the market (including Linux and 2000/XP).
Linux now runs on more and more "big iron" hardware and clearly it has what it takes, if people want to add support for particular platforms.
There's a difference between running and running well. It's a very important distinction to understand. Hardware fills half the gap, software fills the other. People with 20+ years of experience have made sure that both operate at peak efficiency for their target markets. Linux's target market is Intel PC hardware and it shows.
This isn't a criticism, merely a fact. If Linux were designed for Big Iron, it is doubtful that it would be much use on PC hardware (note how Solaris x86 is often called "Slow-laris"). Thus it makes the proper tradeoffs and targets the market it does best in.