The main fan site for Star Control has, for as long as I can remember, been The Pages of Now and Forever. It's got all sorts of Star Control related stuff (information, extracted music, fan art, and various other stuff). It's a good place to find information and news about Star Control (all three of them), and meet other fans. (Sadly, the SC community is not what it was five years ago, but it still exists. Slightly Offtopic: anyone here remember Guillaume's Star Contol message board?).
I'm not a developer of this, but I'm on the developer email list and I've been following CVS and discussions.
Chris Nelson is the main person responsable for the port; Fred and Paul (known among SC fans as "The Creators") are not very involved wit the port. It's a port of the 3do version, not the PC version - meaning that there's speech, and the 3do music (the pc music can be enabled with a commandline switch, though). That also means that the wonderful ending of the PC version is not implemented yet, but it probably will be. It's currently alpha, and there are quite a few bugs - it's actually impossible to win due to collision-detection issues, but I've gotten extremely close to the end. There is also a project underway to create new versions of the music; some of the original authors of the music are involved. The developers don't plan on making any major changes to the game (this should come as a relief): this release will focus on fixing all of the bugs, but otherwise staying as true to the original games as possible. The main ways in which they are straying from the real game is by integrating the 3do and PC versions a bit; the same story, and most of the same graphics, will be used. The name, "The Ur-Quan Masters", has to be used instead of "Star Control" due to trademark issues.
The title screen is fan-created, and there's a music remix project (some of the original musicians are doing the remixes... the Ilwrath music is already up at the Pages of Now and Forever). I'm pretty sure they'd accept quite a bit of fan-created stuff, as long as it's good enough. The developers are *Happy Campers*, after all:)
Someone (Lorenz, a meteorologist) once made a computer program to simulate the weather system (it was not intended to be too close to the real weather, but just a simplified model). One time, after running a simulation, he decided that he wanted to run it for a little longer. Instead of completely restarting the simulation, he just entered in the numbers from the printout.
To his suprise, it started doing completely different things than it did before. It turned out that the printout rounded the numbers. Only a few digits were missing, but that was enough.
What's the moral? Even if you know every detail about how a system works, you can't always predict it; the accuracy of the measurements matters. It's the same with the real weather: The biggest problem is knowing the situation we are in now; I once read that even if we had sensors in every square foot of the atmosphere, we would not be able to predict more than a few weeks. Not because of our model, but because even that isn't accurate enough.
By the way, even much simpler systems have this sort of behaviour. For example, take the function f(x)=3.8*x*(1-x). There's a value of x such that f(x)=f(f(x))=f(f(f(x))) and so on, meaning that if we iterate the function, this value of x is a fixed point. If we do it on a calculator, we find that it jumps away from this value after a few hundred iterations, just because of rounding error! Think about it... being within about 10^-10 (it depends on the particular calculator, of course) isn't enough!
You should take a look at The Demon Haunted World by Carl Sagan; specifically, the chapter titled "The dragon in the garage" (or somthing similar). It addresses this kind of issue very well.
We don't have to force a specific move, as long as for any move that they make, we can revert the board to a "winning position" in our turn (where a winning position is one in which it is possible to force a win. Obviously, if every possible move the opponent makes puts you in a situation where a win can be forced, then the current position is also a winning position). At the beginning of the game, either one player will be in a winning position, or it's always possible to force a tie (as it is in tic-tac-toe).
A winning strategy is not "play this, then play that, and then that"; rather, it is "play this; if your opponent does this, do that, if they do something else, do something else, etc." Of course, a tree of moves like this, for a game as complex as chess, is big enough that I can quite safely state that chess will never be solved, unless some new laws of physics are found.
Re:JPEG does have a lossless mode
on
JPEG2000 Coming Soon
·
· Score: 5, Interesting
I'll give a really quick, basic explanation.
The lifting algorithm (one way of computing the wavelet transform; actually, the simplest to understand and one of the fastest) works by splitting the original signal into two (in the case of a 1d signal) subsignals. One of these is the "trend" signal. It's sort of a compact version of the original one. Using only this signal, the original signal can be reconsturcted pretty well, but not perfectly. That's where the other signal, the "detail" signal, comes in. It contains the information needed to reconstruct the original signal perfectly. If the trend signal is a good prediction of the original signal, the detail signal will be very small, and can be compressed well.
But, there's no need to stop there. The whole process can be applied to the trend signal again, and even to the detail signal if it's necessary.
I'll give a more concrete example, the Haar wavelet transform. In this case, the trend signal is simply the averages of the original signal. So, if we start with
1,3,4,5
The trend signal would be
2,4.5.
If we were to reconstruct the signal with only this information, we'd get
2,2,4.5,4.5,
which is not too bad. The detail signal would contain the information needed to get from this to the original signal; differences between pairs of consecutive terms will work (Note that these pairs shouldn't overlap; that would just be redundant. Therefore, the detail signal, as well as the trend signal, are each half as long as the original one). So, the detail signal in this case is
2,1.
It's easy to see that if the original signal is constant, the detail signal will be all zeros. It's possible to construct different ways of making the trend and detail signals such that the detail signal will be zero if the original signal is linear, for example.
Vorbis (the sound codec; keep in mind that ogg is just the container format!) currently only uses the DCT, the same transform used in current JPEGs as well as MP3s. However, according to their FAQ, wavelets will be supported in the future (I'm too lazy to find the link; sorry!).
Ogg Tarkin (the video codec) will be using wavelets from the beginning, though.
TeX does this when it's run interactively. If it comes across an error, it tries to fix it; it then dispays the message on the screen, and gives the user several options (they can accept what TeX did, type in a replacement, quit, edit the original file, etc.) It then generates a log file for the user to fix the errors in the original source file.
Each bit that you add roughly doubles the amount of time it takes to crack. 2048-bit encryption, although slow, is possible.
What this means is that, assuming that a 1024-bit key can be factored in 1 second, it would take roughly 570044753571256946895391042233962688235025678254 15 606695024759372695\ 54661513856010042759935388366 819543382606540822975 572640467047641318\ 57219835840434659197037569423 594829671728507799344 387665269701556798\ 84895284385512012411993557037 643680409952827613949 299430678049923879\ 77103579392323212688873973370 years to crack 2048 bit encryption. I'm not all that worried.
Quantum computing and quantum encryption are two different things. Quantum encryption technically would not even need a computer at all... as long as you have some way of transmitting and receiving photons, and some way to detect them, etc., pen and paper would be enough (though very impractical!)
It does detect if someone is eavesdropping, but it detects it as the key is generated, not when you send the message. Your post implies that you send the message, and can detect if anyone eavesdrops... this is not the case. Two parties use these quantum effects to generate random numbers... they can detect if someone is eavesdropping on this; if someone is, they don't have to use that key (even if someone does try to eavesdrop, it won't work, by the way). Once they have this key, they can use it in One-Time-Pad encryption, which is also uncrackable (see a text on information theory for an explanation about why OTPs are uncrackable).
No, you don't need separate languages... I never said it was the only way. However, I don't think that using separate languages would be a huge obstacle to debugging.
Actually, I think you could argue that it would make debugging easier. The program is proken down into parts, each doing a certain task. If one part has a bug, you only need to debug that specific part, rather than wading through masses of code that aren't related.
It's true that any one person will probably not look at the code for a program, but, chances are there will be someone else who will look at the code instead. Of course, one shoudn't trust that someone else will for very important things; however, you can be far more certain that an open-source program is free of backdoors than a closed-source program. Furthermore, knowing that the code will be seen by anyone else who wants to look is enough motivation for most people to not include backdoors at all.
Will the required plug-on also block all screenshot utilities? If not, exactly who is it intended to stop?
Or, will it stop people from using a pencil, writing it down, and retyping it? As long as people can read it, we can copy it- even if it's without a computer.
You can prove that certain systems are unbreakable, under certain conditions. For example, one time pads, as long as they are generated using true random numbers, and that each pad is used only once, are provably unbreakable. However, the difficulty in distributing the pads means that it's not too useful.
Slashdot Mirror
The main fan site for Star Control has, for as long as I can remember, been The Pages of Now and Forever. It's got all sorts of Star Control related stuff (information, extracted music, fan art, and various other stuff). It's a good place to find information and news about Star Control (all three of them), and meet other fans. (Sadly, the SC community is not what it was five years ago, but it still exists. Slightly Offtopic: anyone here remember Guillaume's Star Contol message board?).
Networking is not a top priority; they are trying to get the bugs fixed right now. Timewarp is a nice melee clone with networking support, though.
Chris Nelson is the main person responsable for the port; Fred and Paul (known among SC fans as "The Creators") are not very involved wit the port. It's a port of the 3do version, not the PC version - meaning that there's speech, and the 3do music (the pc music can be enabled with a commandline switch, though). That also means that the wonderful ending of the PC version is not implemented yet, but it probably will be. It's currently alpha, and there are quite a few bugs - it's actually impossible to win due to collision-detection issues, but I've gotten extremely close to the end. There is also a project underway to create new versions of the music; some of the original authors of the music are involved. The developers don't plan on making any major changes to the game (this should come as a relief): this release will focus on fixing all of the bugs, but otherwise staying as true to the original games as possible. The main ways in which they are straying from the real game is by integrating the 3do and PC versions a bit; the same story, and most of the same graphics, will be used. The name, "The Ur-Quan Masters", has to be used instead of "Star Control" due to trademark issues.
So, download it and *enjoy the sauce*!
The title screen is fan-created, and there's a music remix project (some of the original musicians are doing the remixes... the Ilwrath music is already up at the Pages of Now and Forever). I'm pretty sure they'd accept quite a bit of fan-created stuff, as long as it's good enough. The developers are *Happy Campers*, after all :)
To his suprise, it started doing completely different things than it did before. It turned out that the printout rounded the numbers. Only a few digits were missing, but that was enough.
What's the moral? Even if you know every detail about how a system works, you can't always predict it; the accuracy of the measurements matters. It's the same with the real weather: The biggest problem is knowing the situation we are in now; I once read that even if we had sensors in every square foot of the atmosphere, we would not be able to predict more than a few weeks. Not because of our model, but because even that isn't accurate enough.
By the way, even much simpler systems have this sort of behaviour. For example, take the function f(x)=3.8*x*(1-x). There's a value of x such that f(x)=f(f(x))=f(f(f(x))) and so on, meaning that if we iterate the function, this value of x is a fixed point. If we do it on a calculator, we find that it jumps away from this value after a few hundred iterations, just because of rounding error! Think about it... being within about 10^-10 (it depends on the particular calculator, of course) isn't enough!
You should take a look at The Demon Haunted World by Carl Sagan; specifically, the chapter titled "The dragon in the garage" (or somthing similar). It addresses this kind of issue very well.
A winning strategy is not "play this, then play that, and then that"; rather, it is "play this; if your opponent does this, do that, if they do something else, do something else, etc." Of course, a tree of moves like this, for a game as complex as chess, is big enough that I can quite safely state that chess will never be solved, unless some new laws of physics are found.
The lifting algorithm (one way of computing the wavelet transform; actually, the simplest to understand and one of the fastest) works by splitting the original signal into two (in the case of a 1d signal) subsignals. One of these is the "trend" signal. It's sort of a compact version of the original one. Using only this signal, the original signal can be reconsturcted pretty well, but not perfectly. That's where the other signal, the "detail" signal, comes in. It contains the information needed to reconstruct the original signal perfectly. If the trend signal is a good prediction of the original signal, the detail signal will be very small, and can be compressed well.
But, there's no need to stop there. The whole process can be applied to the trend signal again, and even to the detail signal if it's necessary.
I'll give a more concrete example, the Haar wavelet transform. In this case, the trend signal is simply the averages of the original signal. So, if we start with
1,3,4,5
The trend signal would be
2,4.5.
If we were to reconstruct the signal with only this information, we'd get
2,2,4.5,4.5,
which is not too bad. The detail signal would contain the information needed to get from this to the original signal; differences between pairs of consecutive terms will work (Note that these pairs shouldn't overlap; that would just be redundant. Therefore, the detail signal, as well as the trend signal, are each half as long as the original one). So, the detail signal in this case is
2,1.
It's easy to see that if the original signal is constant, the detail signal will be all zeros. It's possible to construct different ways of making the trend and detail signals such that the detail signal will be zero if the original signal is linear, for example.
A good paper about this (that explains it better than I do!) is Building Your Own Wavelets at Home
Ogg Tarkin (the video codec) will be using wavelets from the beginning, though.
TeX does this when it's run interactively. If it comes across an error, it tries to fix it; it then dispays the message on the screen, and gives the user several options (they can accept what TeX did, type in a replacement, quit, edit the original file, etc.) It then generates a log file for the user to fix the errors in the original source file.
This is what happens when I post when I'm too tired :) Thanks for the correction.
Each bit that you add roughly doubles the amount of time it takes to crack. 2048-bit encryption, although slow, is possible.
What this means is that, assuming that a 1024-bit key can be factored in 1 second, it would take roughly
57004475357125694689539104223396268823502567825
5466151385601004275993538836
5721983584043465919703756942
8489528438551201241199355703
7710357939232321268887397337
years to crack 2048 bit encryption. I'm not all that worried.
Quantum computing and quantum encryption are two different things. Quantum encryption technically would not even need a computer at all... as long as you have some way of transmitting and receiving photons, and some way to detect them, etc., pen and paper would be enough (though very impractical!)
It is uncrackable.
It does detect if someone is eavesdropping, but it detects it as the key is generated, not when you send the message. Your post implies that you send the message, and can detect if anyone eavesdrops... this is not the case. Two parties use these quantum effects to generate random numbers... they can detect if someone is eavesdropping on this; if someone is, they don't have to use that key (even if someone does try to eavesdrop, it won't work, by the way). Once they have this key, they can use it in One-Time-Pad encryption, which is also uncrackable (see a text on information theory for an explanation about why OTPs are uncrackable).
No, you don't need separate languages... I never said it was the only way. However, I don't think that using separate languages would be a huge obstacle to debugging.
Actually, I think you could argue that it would make debugging easier. The program is proken down into parts, each doing a certain task. If one part has a bug, you only need to debug that specific part, rather than wading through masses of code that aren't related.
2=1? That's nothing:
S = 1+2+4+8+16+32...
We're adding up an infinite number of positive numbers... this is infinite. But...
S = 1+2*(1+2+4+8+16...)
S = 1*2S
S = -1
So, infinity=-1!
Windows 3.1 actually came with such a program (recorder.exe), but, for some reason, it's not included with any later version.
It's true that any one person will probably not look at the code for a program, but, chances are there will be someone else who will look at the code instead. Of course, one shoudn't trust that someone else will for very important things; however, you can be far more certain that an open-source program is free of backdoors than a closed-source program. Furthermore, knowing that the code will be seen by anyone else who wants to look is enough motivation for most people to not include backdoors at all.
-----
MP3 has various patent troubles... you're probably best going with Ogg Vorbis: no patent problems, and the quality is improving every day.
-----
Of course, one could simply take a photo of it or something like that.
-----
... when someone could simply use a camera.
-----
Or, will it stop people from using a pencil, writing it down, and retyping it? As long as people can read it, we can copy it- even if it's without a computer.
-----
Yes... one such program is vsound. I've sucessfully used it to save a realaudio stream.
-----
You can prove that certain systems are unbreakable, under certain conditions. For example, one time pads, as long as they are generated using true random numbers, and that each pad is used only once, are provably unbreakable. However, the difficulty in distributing the pads means that it's not too useful.
-----