That approach... "description-based" compression, if you will, has merit.
And for non-realtime compression, it might even work. The trick is finding a description (or descriptions) of the data (which might have been generated in a truly random manner) that's 1% or less of the size of the data, and then transmitting that.
That could take an AWFULLY long time, though.
It would never suffice for real-time compression, though -- you can't assign a description to random data as it's coming in, because there's literally no way to describe what's coming next; you can only describe it after the fact.
Description-based compression probably gives great results for some data, IF you either have lots of horsepower or don't mind waiting. I'm not sure anyone out there has come up with a "Generic" algorithm for it, though; it's easy to give examples of where it yields great results but I've yet to see a general-use algorithm.
Ahh, but the collection of all bitstreams of length 100 isn't a very likely random set, is it?
A data set of equal length is more likely to have one of the 100-bit sequences in it twice than it is to have each one exactly once.
This is just another way of proving that the random case is NOT the worst case; at least, if we accept their claim that they can do 100:1 on random data, and we have your proof that the worst case MUST be less than 100:1, then it follows that the worst case is non-random data.
Worst case for any lossless compression scheme is 1:1 (or worse, rest assured), as you've demonstrated.
I disagree with "random data" being defined as "any data whatsover".
I think "random data" means data generated in such a way that there is no predictibility in the sequence of symbols in the data generated, nothing more.
It's not very interesting to say what a compression (or sorting, etc.) algorith can do over the long run -- you generally want to characterize the performance against "ideal" data, "average" data, and "worst-case" data. The exact nature of EACH of those three IS and must be dependent on the nature of the algorithm itself. However, A set of data that is generated from some sort of random (or pseudorandom) source is often a valid "average" case.
But, if you're talking about random 3-character sequences, "the" is as likely to be the result as any other, such as "and", "but", "thx", and so on.
Such sequences WILL occur in a truly random data stream, if the stream is long enough. Or, I should say, as the stream length increases, the probability that a given sequence WON'T occur approaches zero. The chance that a given sequence will appear twice anywhere within it, approaches zero. And so on.
Of course, achieving better than 1:1 compression with truly random data is hard, because while you get compression by finding repeated sequences, you lose some to overhead (you have to track what the repeated sequence is AND where each instance of it is located), and you still have to find a way to efficiently store the rest of the stream.
Existing compression schemes have to balance compression/decompression speed vs. compression ratio -- most offer options to adjust, in fact.
I suspect their technique takes an enormous amount of time to achieve a very high ratio -- but I'm still skeptical as to the nature of their "practically" random data.
I've already pointed out the potential oversight in this argument, but noone seems to have noticed it.
Everyone seems to be assuming that "random data" is the WORST case, and that thus the compression ratio will be _at least_ 100:1 for any data, if it's 100:1 for "random" data.
This is not necessarily the case. Think about an algorithm like quicksort. Average case, about nLog(n) (Average case would include quicksort on a random set). Worse case, however, is n^2 (For a reverse-sorted set, IIRC).
So the result of the compression pass against the 1000-element data is NOT necessarily subject to the same or even ANY compression via the same algorithm(s).
Think about it -- in even "truly" random data, there WILL be multiple instances of any given sequence, if the data is large enough. It's the 1000 monkeys/1000 typewriters/Works of Shakespeare thing.
Such a stream is therefore compressible by most algorithms. But, given ANY compression algorithm, you can design a set of data that can NOT be compressed at all using that algorithm -- in fact, that would be the ideal output of the algorithm to begin with.
A sequence like "AKJABKEAF" might be very compressible (characters appear more than once). But "ABCDEFGHIJK" might have zero compression under the same method (since every character is unique).
"Random" is not "worst-case" performance, at least it's certainly not guaranteed to be.
No...the compressed data is almost certainly NOT random, so it couldn't be compressed the same way. It's also highly unlikely any other compression scheme could reduce it either.
I'm very, very skeptical of 100:1 claims on "random" data -- it must either be large enough that even being random, there are lots of repeated sequences, or the test data is rigged.
Or, of course, it could all be a big pile of BS designed to encourage some funding/publicity.
Um, I may be wrong here, but how many of these impacts are supposed to come from extra-solar-system objects?
It was my understanding that they're generally comets and asteroids, which are all from within our solar system.
Other solar systems, even if close in interstellar terms, would rather too far away to be sending objects at us (with the possible exception of Little Green Men, of course).
Well, I didn't check your math; but inpact mass and velocity would be reduced by the atmosphere, at least somewhat.
Also, depending on the composition, the asteroid might disintegrate into smaller fragments -- this would also reduce the impact energy to some extent as the atmosphere would then break down each fragment better than it would the whole.
Regardless, it would make Fat Man and Little Boy look like roman candles by comparison, I think...
Aside from the already stated reasons (evactuation), it would also help to start identifying WHAT we need to be able to deal with, while we're working on being able to deal with it.
Plus, sometimes knowing exactly what needs to be done helps us find a way to do it -- necessity being the mother of ingenuity, and all that.
What I'm saying is that this scenario is only believeable if you believe that the AI is WILLFULLY trying to provoke me by entering my territory while claiming (by being at 'polite' diplomacy wise) to be friendly. That's what Belgium 1940 was, clearly.
But I strongly doubt the AI is capable of that level of behavior. I rather believe that the AI simply ignores borders, and when someone complains, decides based on relative strength whether or not to comply or declare war.
Peacetime reality does NOT necessarily agree with that. Countries generally respect each others borders unless they're willing to go to war with a lot more than just the country they're trespassing in.
Each small wonder's description in the "Civlopedia" describes what conditions must be met before you can build it, IIRC.
The thing that took me a while to figure out was using the build queue -- I'm not sure if it's documented or not, but you hold down shift while clicking on items to queue rather than switch to them. You can save and load queues too, though I'm not sure I'd bother unless I was doing a ton of late game colonization (yeah, right, like that happens).
I'm running Win2k on an Athlon 1.4, 384 megs ram, geforce3, and I had no problems even with 4+ hours of continuous play. I even had ICQ, AIM, genome@home, and other things running in the background.
My gf's machine seemed to run things smoother when she turned background music off; you might try that if you haven't (I'm guessing you have, though).
I've also heard mention of configuring your monitor type to be other than "default monitor", but that's speculative, not informative.
I think we're seeing what happens when a game's testing is either internal or closed beta, without a larger-scale or even open beta to get more hardware tested against...
The enemy forces in my territory were NOT there to attack, at least not me. They may have been moving to attack someone else, and through my territory was the most direct way, but that DOES NOT mean they should just do so and not expect me to get upset (as you yourself said in regards to them getting mad at me for entering THEIR territory). They should obtain a right of passage agreement (which the game has), or go around.
In short, they were NOT in my territory to attack ME. Their relations were "polite", but when I asked them to leave, they went straight to war. Now, while someone might try to argue that this was a planned attack waiting for an excuse, I'm not buying it.
I did notice they buildup before attacking, and that's an improvement. I wouldn't call that anything to jump up and down about, though -- it's long overdue in strategy games, so it's an "at last" feature more than a "wow" for me.
Agreed. However, while some of the countries that did this MIGHT have had an advantage (one had a clear advantage), several were doing this, and at least two of them were no more than even -- one had declared war earlier and had a mudhole stomped in them, courtesy of my glorius Greek Hoplites of Doom.
It may well be that they'd do it, and withdraw if I demanded they do so, if they thought I had a superior military.
But this gets to another issue -- relative strength doesn't seem to be measured well. This may simply be a question of not weighting by rank enough. When those superior forces attacked one of my cities, my Elite Hoplite killed easily a half dozen or more of their Warriors one by one. It took 4 or 5 turns for them to wear him down.
So, while the GOAL might be to model the real-world phenomenon of "might makes right", I'm not convinced that the game model captures this well enough. Israel might be a tiny country, with a small (though large proportionally) army, but their reputation as an elite military gives their enemies pause. Civ3 could do better in accounting for RANK of your units, not just numbers (and possibly type, if they even have that!).
I've played Civ3 a couple nights now since I got my copy. I knew going in that it was 'evolutionary not revolutionary', and that's definitely true.
But (and this is NOT a flame, just honest criticism), it's not even all that evolutionary. Most of the "new" features as compared to Civ2 were in SMAC (Sid Meier's Alpha Centauri) -- the borders, most of the enhanced dipolomacy options, and so on.
The AI -- I'm sorry, but if this is supposed to be new and improved, I'm not seeing it. Enemy empires will send forces willy-nilly into my borders (and I'm talking 10 or a dozen at a time). If I demand that they leave, they declare war. If I send so much as a _single_ unit into THEIR borders for a SINGLE turn, they immediately demand that I withdraw or they declare war. This kind of behavior is just too unrealistic, IMHO.
So, all an all, I'm not very impressed. It IS a much needed update to the series, but it feels a lot more like a status-quo release riding on Sid's reputation for sales, than an honest attempt to make a solid follow-on to this legendary game title. I'm much more interested in Master of Orion 3 (www.moo3.com), which while still a few months away, is daring to be Revolutionary in a time of Evolutionary games.
Although the post I replied to seemed to be TRYING to provoke an argument rather than asking a serious question (which is why I mentioned flame-bait), I answered his question with my 2 cents' worth.
Having said that, I'm not fat or greasy, I _do_ have a life (I don't sit around working up one-line wisecracks to/. posts ALL DAY unlike some others, apparently), and I can't write in runes, speak Elvish, nor do I have the trilogy memorized. Thank you, drive through.
I'll give you credit for living up to the name, Anonymous Coward, though:)
If you _read_ the Ring Trilogy (I have to actually wonder), you'd know that circumstances suggested any OVERT action relating to the ring would likely meet overwhelming opposition from Sauron and his forces. Frodo and the companions represented the ultimate in a covert operation, in many ways (though Gandalf just by being Gandalf draws attention).
It's a classic strategy (in fiction anyway) -- do what the enemy least expects, which often also involves doing something the Enemy thinks you'd be either stupid or suicidal to even try.
Elrond and Gandalf (and others) understood Sauron's psyche enough (scary thought) to realize that he'd never expect them to _destroy_ the Ring, but to use it against him in their own rise to power (as several parties suggested or pondered at various points).
Anyway, that's probably just going to touch off a flame war or a oft-repeated debate, so it'll be my last posted thoughts on the subject (hopefully).
Personally, I can't imagine any software engineering problem that couldn't be solved with either a CLI-based or a GUI-based tool.
However, _debugging_ code generally seems easier when you have an interactive GUI debugger...compare VC++'s interactive debugger against dbx, for example. Even ddd on top of dbx usually adds a lot compared to just dbx.
So I submit that developing isn't necessarily "better" with a GUI -- some people DO think in code, and the gui doesn't really help unless you're doing GUI layout or the like. But having a GUI front-end to an interactive debugger makes testing and integration a LOT easier, IMHO.
However, compared to the likes of Microsoft, you have to admit that the virus companies stay at the top of their game, quality and response-wise. Of course, since they might be liable for being anything less (it's a lot easier to see a gross negligence charge against the Virus protection than against the OS or the Office Suite, as bass-ackwards as it seems), they have to stay on top of the threat.
NC State has a site license for the Norton Antivirus, as well.
I think making a copy of one of the better anti-virus programs freely available is about as far as a school should and could go.
As someone else pointed out, you can't make it a requirement because there are a fair number of non-Windows machines out there. And it's a darn sight better than nothing. At the end of the day, you'll never be perfect, because there are too many idiots with computers (reminds me of idiots with cars, in that respect). But just doing a site license of Norton or McAfee will get you 90% protected with about 75% of the student body, which is about the best you can hope for.
Yeah, that's it. McAllister and a few others have worked on it (aren't Bitzer and some of his grad students working on it too?). There's at least one more, younger, prof working on it too, but I can't remember his name off hand.
Slashdot Mirror
That approach ... "description-based" compression, if you will, has merit.
And for non-realtime compression, it might even work. The trick is finding a description (or descriptions) of the data (which might have been generated in a truly random manner) that's 1% or less of the size of the data, and then transmitting that.
That could take an AWFULLY long time, though.
It would never suffice for real-time compression, though -- you can't assign a description to random data as it's coming in, because there's literally no way to describe what's coming next; you can only describe it after the fact.
Description-based compression probably gives great results for some data, IF you either have lots of horsepower or don't mind waiting. I'm not sure anyone out there has come up with a "Generic" algorithm for it, though; it's easy to give examples of where it yields great results but I've yet to see a general-use algorithm.
Xentax
Ahh, but the collection of all bitstreams of length 100 isn't a very likely random set, is it?
A data set of equal length is more likely to have one of the 100-bit sequences in it twice than it is to have each one exactly once.
This is just another way of proving that the random case is NOT the worst case; at least, if we accept their claim that they can do 100:1 on random data, and we have your proof that the worst case MUST be less than 100:1, then it follows that the worst case is non-random data.
Worst case for any lossless compression scheme is 1:1 (or worse, rest assured), as you've demonstrated.
Xentax
I disagree with "random data" being defined as "any data whatsover".
I think "random data" means data generated in such a way that there is no predictibility in the sequence of symbols in the data generated, nothing more.
It's not very interesting to say what a compression (or sorting, etc.) algorith can do over the long run -- you generally want to characterize the performance against "ideal" data, "average" data, and "worst-case" data. The exact nature of EACH of those three IS and must be dependent on the nature of the algorithm itself. However, A set of data that is generated from some sort of random (or pseudorandom) source is often a valid "average" case.
Xentax
No...I'm not comparing probability of occurence.
But, if you're talking about random 3-character sequences, "the" is as likely to be the result as any other, such as "and", "but", "thx", and so on.
Such sequences WILL occur in a truly random data stream, if the stream is long enough. Or, I should say, as the stream length increases, the probability that a given sequence WON'T occur approaches zero. The chance that a given sequence will appear twice anywhere within it, approaches zero. And so on.
Of course, achieving better than 1:1 compression with truly random data is hard, because while you get compression by finding repeated sequences, you lose some to overhead (you have to track what the repeated sequence is AND where each instance of it is located), and you still have to find a way to efficiently store the rest of the stream.
Existing compression schemes have to balance compression/decompression speed vs. compression ratio -- most offer options to adjust, in fact.
I suspect their technique takes an enormous amount of time to achieve a very high ratio -- but I'm still skeptical as to the nature of their "practically" random data.
I've already pointed out the potential oversight in this argument, but noone seems to have noticed it.
Everyone seems to be assuming that "random data" is the WORST case, and that thus the compression ratio will be _at least_ 100:1 for any data, if it's 100:1 for "random" data.
This is not necessarily the case. Think about an algorithm like quicksort. Average case, about nLog(n) (Average case would include quicksort on a random set). Worse case, however, is n^2 (For a reverse-sorted set, IIRC).
So the result of the compression pass against the 1000-element data is NOT necessarily subject to the same or even ANY compression via the same algorithm(s).
Think about it -- in even "truly" random data, there WILL be multiple instances of any given sequence, if the data is large enough. It's the 1000 monkeys/1000 typewriters/Works of Shakespeare thing.
Such a stream is therefore compressible by most algorithms. But, given ANY compression algorithm, you can design a set of data that can NOT be compressed at all using that algorithm -- in fact, that would be the ideal output of the algorithm to begin with.
A sequence like "AKJABKEAF" might be very compressible (characters appear more than once). But "ABCDEFGHIJK" might have zero compression under the same method (since every character is unique).
"Random" is not "worst-case" performance, at least it's certainly not guaranteed to be.
Xentax
No...the compressed data is almost certainly NOT random, so it couldn't be compressed the same way. It's also highly unlikely any other compression scheme could reduce it either.
I'm very, very skeptical of 100:1 claims on "random" data -- it must either be large enough that even being random, there are lots of repeated sequences, or the test data is rigged.
Or, of course, it could all be a big pile of BS designed to encourage some funding/publicity.
Xentax
Um, I may be wrong here, but how many of these impacts are supposed to come from extra-solar-system objects?
It was my understanding that they're generally comets and asteroids, which are all from within our solar system.
Other solar systems, even if close in interstellar terms, would rather too far away to be sending objects at us (with the possible exception of Little Green Men, of course).
Xentax
Well, I didn't check your math; but inpact mass and velocity would be reduced by the atmosphere, at least somewhat.
Also, depending on the composition, the asteroid might disintegrate into smaller fragments -- this would also reduce the impact energy to some extent as the atmosphere would then break down each fragment better than it would the whole.
Regardless, it would make Fat Man and Little Boy look like roman candles by comparison, I think...
Aside from the already stated reasons (evactuation), it would also help to start identifying WHAT we need to be able to deal with, while we're working on being able to deal with it.
Plus, sometimes knowing exactly what needs to be done helps us find a way to do it -- necessity being the mother of ingenuity, and all that.
Xentax
What I'm saying is that this scenario is only believeable if you believe that the AI is WILLFULLY trying to provoke me by entering my territory while claiming (by being at 'polite' diplomacy wise) to be friendly. That's what Belgium 1940 was, clearly.
But I strongly doubt the AI is capable of that level of behavior. I rather believe that the AI simply ignores borders, and when someone complains, decides based on relative strength whether or not to comply or declare war.
Peacetime reality does NOT necessarily agree with that. Countries generally respect each others borders unless they're willing to go to war with a lot more than just the country they're trespassing in.
Xentax
Each small wonder's description in the "Civlopedia" describes what conditions must be met before you can build it, IIRC.
The thing that took me a while to figure out was using the build queue -- I'm not sure if it's documented or not, but you hold down shift while clicking on items to queue rather than switch to them. You can save and load queues too, though I'm not sure I'd bother unless I was doing a ton of late game colonization (yeah, right, like that happens).
Xentax
Stability seems to be very hit-or-miss.
I'm running Win2k on an Athlon 1.4, 384 megs ram, geforce3, and I had no problems even with 4+ hours of continuous play. I even had ICQ, AIM, genome@home, and other things running in the background.
My gf's machine seemed to run things smoother when she turned background music off; you might try that if you haven't (I'm guessing you have, though).
I've also heard mention of configuring your monitor type to be other than "default monitor", but that's speculative, not informative.
I think we're seeing what happens when a game's testing is either internal or closed beta, without a larger-scale or even open beta to get more hardware tested against...
Xentax
Maybe I wasn't thorough enough.
The enemy forces in my territory were NOT there to attack, at least not me. They may have been moving to attack someone else, and through my territory was the most direct way, but that DOES NOT mean they should just do so and not expect me to get upset (as you yourself said in regards to them getting mad at me for entering THEIR territory). They should obtain a right of passage agreement (which the game has), or go around.
In short, they were NOT in my territory to attack ME. Their relations were "polite", but when I asked them to leave, they went straight to war. Now, while someone might try to argue that this was a planned attack waiting for an excuse, I'm not buying it.
I did notice they buildup before attacking, and that's an improvement. I wouldn't call that anything to jump up and down about, though -- it's long overdue in strategy games, so it's an "at last" feature more than a "wow" for me.
Agreed. However, while some of the countries that did this MIGHT have had an advantage (one had a clear advantage), several were doing this, and at least two of them were no more than even -- one had declared war earlier and had a mudhole stomped in them, courtesy of my glorius Greek Hoplites of Doom.
It may well be that they'd do it, and withdraw if I demanded they do so, if they thought I had a superior military.
But this gets to another issue -- relative strength doesn't seem to be measured well. This may simply be a question of not weighting by rank enough. When those superior forces attacked one of my cities, my Elite Hoplite killed easily a half dozen or more of their Warriors one by one. It took 4 or 5 turns for them to wear him down.
So, while the GOAL might be to model the real-world phenomenon of "might makes right", I'm not convinced that the game model captures this well enough. Israel might be a tiny country, with a small (though large proportionally) army, but their reputation as an elite military gives their enemies pause. Civ3 could do better in accounting for RANK of your units, not just numbers (and possibly type, if they even have that!).
Xentax
I've played Civ3 a couple nights now since I got my copy. I knew going in that it was 'evolutionary not revolutionary', and that's definitely true.
But (and this is NOT a flame, just honest criticism), it's not even all that evolutionary. Most of the "new" features as compared to Civ2 were in SMAC (Sid Meier's Alpha Centauri) -- the borders, most of the enhanced dipolomacy options, and so on.
The AI -- I'm sorry, but if this is supposed to be new and improved, I'm not seeing it. Enemy empires will send forces willy-nilly into my borders (and I'm talking 10 or a dozen at a time). If I demand that they leave, they declare war. If I send so much as a _single_ unit into THEIR borders for a SINGLE turn, they immediately demand that I withdraw or they declare war. This kind of behavior is just too unrealistic, IMHO.
So, all an all, I'm not very impressed. It IS a much needed update to the series, but it feels a lot more like a status-quo release riding on Sid's reputation for sales, than an honest attempt to make a solid follow-on to this legendary game title. I'm much more interested in Master of Orion 3 (www.moo3.com), which while still a few months away, is daring to be Revolutionary in a time of Evolutionary games.
Xentax
Ahh, gotta love the peanut gallery, as usual.
/. posts ALL DAY unlike some others, apparently), and I can't write in runes, speak Elvish, nor do I have the trilogy memorized. Thank you, drive through.
:)
First, I was far from personally offended.
Although the post I replied to seemed to be TRYING to provoke an argument rather than asking a serious question (which is why I mentioned flame-bait), I answered his question with my 2 cents' worth.
Having said that, I'm not fat or greasy, I _do_ have a life (I don't sit around working up one-line wisecracks to
I'll give you credit for living up to the name, Anonymous Coward, though
Hmm, can we say "flamebait"?
If you _read_ the Ring Trilogy (I have to actually wonder), you'd know that circumstances suggested any OVERT action relating to the ring would likely meet overwhelming opposition from Sauron and his forces. Frodo and the companions represented the ultimate in a covert operation, in many ways (though Gandalf just by being Gandalf draws attention).
It's a classic strategy (in fiction anyway) -- do what the enemy least expects, which often also involves doing something the Enemy thinks you'd be either stupid or suicidal to even try.
Elrond and Gandalf (and others) understood Sauron's psyche enough (scary thought) to realize that he'd never expect them to _destroy_ the Ring, but to use it against him in their own rise to power (as several parties suggested or pondered at various points).
Anyway, that's probably just going to touch off a flame war or a oft-repeated debate, so it'll be my last posted thoughts on the subject (hopefully).
I think you're just lucky. I've gotten a capacity-related error message every time I've tried, as apparently nearly everyone else has.
This link is bogus; the folder is empty...
This is a shorter version of the trailer I saw on the WB last night.
Does anyone have a mirror of the FULL trailer (oxymoron, I know)?
Personally, I can't imagine any software engineering problem that couldn't be solved with either a CLI-based or a GUI-based tool.
However, _debugging_ code generally seems easier when you have an interactive GUI debugger...compare VC++'s interactive debugger against dbx, for example. Even ddd on top of dbx usually adds a lot compared to just dbx.
So I submit that developing isn't necessarily "better" with a GUI -- some people DO think in code, and the gui doesn't really help unless you're doing GUI layout or the like. But having a GUI front-end to an interactive debugger makes testing and integration a LOT easier, IMHO.
A valid point.
However, compared to the likes of Microsoft, you have to admit that the virus companies stay at the top of their game, quality and response-wise. Of course, since they might be liable for being anything less (it's a lot easier to see a gross negligence charge against the Virus protection than against the OS or the Office Suite, as bass-ackwards as it seems), they have to stay on top of the threat.
Xentax
NC State has a site license for the Norton Antivirus, as well.
I think making a copy of one of the better anti-virus programs freely available is about as far as a school should and could go.
As someone else pointed out, you can't make it a requirement because there are a fair number of non-Windows machines out there. And it's a darn sight better than nothing. At the end of the day, you'll never be perfect, because there are too many idiots with computers (reminds me of idiots with cars, in that respect). But just doing a site license of Norton or McAfee will get you 90% protected with about 75% of the student body, which is about the best you can hope for.
Xentax
Yeah, that's it. McAllister and a few others have worked on it (aren't Bitzer and some of his grad students working on it too?). There's at least one more, younger, prof working on it too, but I can't remember his name off hand.
There's software out there (some of it was invented at my alma mater, N.C. State) which can generate CGI-lip movements from recorded speech.
Converting the stock image to fit the appropriate face ought to be a relatively easy task up front, then the engine does the work from there.
I can't recall the name of NCSU's particular software off-hand, but someone else on here might know...