It's too easy to hide you used Elcomsoft's software : you just install a pirated version of acrobat, open the pirated ebook, and then print it through the virtual printer provided by acrobat. And you've got the advantage of reducing the file size, by just choosing a lower output resolution.
Soon it will be legal : under the P2P Prevention Act or whatever it is called, media pimps, be it RIAA, MPAA or others, have the right to DOS attack P2P network. Downloading 100,000 files from a P2P network IS a DOS attack, you obviously aren't going to read them all.
Where all numbers are in binary:
decompress(x) = { (the infinite binary encode of pi) if x == 1
what gunzip would do if x != 1 }
Perfectly permissible since "1" isn't a legit gunzip file.
compress(x) = { 1 if x == (the infinite binary encoding of pi)
what gzip would do if x != pi }
What will gzip-the-decompressor do if it encounters a 1 in the middle of the message ? Was the 1 generated by a "Pi" in the source, or is it part of a non-pi-containing source, that happens to compress to something else than "00000000000000000....".
What will gzip-the-compressor do when it encounters the following as a source : "generic-genreic-pi-pi" ? Which 1s came from gzip-the-generic-compressor ? Which 1s came from "pi" ?
My idea is that the c compression algorithm would be beat by a perl compression.
And what is that supposed to mean, anyhow? Algorithms exist independently of their implementation in a given language!
Even just the same algorithm can be coded purely differently in c an in pl. I expect the c version to be longer bytewise (it's english), shorter once compressed (must have approximately the same entropy per char as english) and faster (it always is). I expect the pl version to be shorter (It's like written chinese--to me anyway), longer once compressed (it's nothing but s or @s or &s) and slower (yes I now it got better). As for the BF version, it will be much longer (go forward by one, go fwd by one, inc 1, inc 1), much shorter once compressed (only 5 chars --> low entropy, many repeats --> RLE). Yes, I forgot to point out, nothing forbis us to add a generic entropy encoder in the codec system.
For your choice of binary encodings of real numbers that makes sense in this domain.
I never chose binary encoding, I barely quantified my encoding in binary, because that's what's been done sonce 1948. I speak nowhere of binary encoding, I only count in bits. But if you realy want a suggestion, just leave the digits the way they are. I do suppose if you take zillions of decimals, you do take the care to store everything as a huge binary number (that's what electronic computers are good at). Decimal, be it BCD or ASCII, would be too much a overhead (BCD is throwing away 0.68bits per decimal-hey, see, a decimal doesn't look BINARY to me, I used the term thoroughly in my parent post-, ASCII is throwing away 4.68bits per char). Don't even think about huffmann, distribution is uniform, huffmann is not good at that
You, Sir, despite your low member number, would get an F- for information theory at the university I was tought and now teach.
There is nothing that compresses to one bit. There is such thing as a most efficient way of encoding any message. Counted in bits. and no, not just one bit. One bit would just contain enough information to say "Pi" or "Not Pi". "Not Pi" would according to my intuition not be an acceptable answer, you also have to say "What kind of 'Not Pi'". And that takes bits. You forgot that your algorithm is supposed to possibly generate all possible messages, or else it's "not fair".
Pi would not compress at all, given it's an infinitely long number. (To be precise, it's length would be reduced from inf to inf/(alphabet entropy) which is still inf, although a "smaller" inf). If you are content with a finite number of digits, its length would be reduced by about a little more than three bits per decimal (because log2(10)=3.???) with any decent entropy encoder. You could try to reduce this further by taking two decimal digits at once, but unfortunately it would not work, as not only are Pi's digits uniformly distributed from 0 to 9, pairs of digits are also distributed uniformly from 0-99, so you would remain with 6.???? bits (log2(100)) per decimal digits pair.
Another approach you might take, if you want infinite precision (silly on a finite machine), or more generally random precision, is to write a code in a predetermined programming language, in this case a series developement, or whatever the number thorists use nowadays to calculate pi, and decide that the "decompression algorithm" is a compiler (that is perfectly legal, as any finite message can be passed that way, eg "#include <iostream> int main(){cout << "The message";}").
My idea is that the c compression algorithm would be beat by a perl compression. Maybe try in BrainFuck, it might beat perl, but BF sucks at multiplications.
Anyway, the most optimal compression for pi is probably saying "Pi" by itself. Any decent geek knows at least one way to calculate that/ find it on project gutenberg/whatever. But don't ever think that you could compress it to two bytes or less : you gotta be sure that I will not understand "the string of decimal digits a.k.a. Pi, do write it in numbers when decompressing", not just "mu turned over", "Pi the string" or "Private investigator". This certainty takes bytes.
Another example is : "you cannot encode '3 4 8 15 3.141592653 78 54' as '3 4 8 15 pi 78 54', because that would increase the number of symbols in the alphabet, and all the other symbols would have to contain more bits as a result, so the compressed message length would suffer- hope there are a lot of 'pi' in the compresed message".
I must leave now, gotta go bowling with friends. Start your flames, I can see blatant holes in my reasonments. Hope you get the point. Mailing a link to the message to my signal theory professor (formally one of my bosses), so I will suffer if I told bullshit.
CFCs are not the cause for global warming, they're the cause for the hole in the ozone layer.
On the other hand, producing the sound waves will cost some electricity, the production of which is still mainly a main CO2 producer. So my idea is it will enhance the global warming, if anything.
Actually a question that always struck me is : what computers did the soviets use ? These people had a comparable space program, and yet I have never heard of the computers they were using. I tried a while ago to make some google searches (yes, I do know in soviet russia google searches YOU), but the only thing I found was a pay per view IEEE article. Does anyone know a good website on the matter ?
Apparently, the w3c validator is not even allowed to have an opinion on the matter.
Actually, if you go beyond that 403 error and save the page, and submit the page to the w3c validator, you'll get hundreds of errors. And not only are there errors, there's also lots of redundancy in the style defs : no use of stylesheets, sirree. If they were to implement CSS usage, I think their bandwidth would easily be reduced by half (stylesheets and images are static and can be cached anyway).
Why do they stick at such poor quality anyway ? Compatibility ? My ass ! Everyone has a computer with IE6+ installed nowadays. The others are either not giving a fuck (lynx does not handle style anyway), either having a browser that supports the lowest common denominator (newer html tags are just ignored by well designed older browsers). And if you're still running Mosaic, you definitely do not give a fuck about how the fucking page looks like.
I think the only good side of the story is that people are now more concerned about open source software, since *M$* software is pretty damn expensive now
No, they'll do as everyone else, they'll make illegal copies. It's a myth that only the Chinese do, and I am almost certain it's also a myth USians mostly don't.
A genitive is written this way in English : Prince's book
Also, you probably meant : "Formerly". According to the guys at Phoenix the BIOS makers, the browser can NOT "formally" be called Phoenix, although informally it will remain so for a while.
Slashdot Mirror
It's too easy to hide you used Elcomsoft's software : you just install a pirated version of acrobat, open the pirated ebook, and then print it through the virtual printer provided by acrobat. And you've got the advantage of reducing the file size, by just choosing a lower output resolution.
Soon it will be legal : under the P2P Prevention Act or whatever it is called, media pimps, be it RIAA, MPAA or others, have the right to DOS attack P2P network. Downloading 100,000 files from a P2P network IS a DOS attack, you obviously aren't going to read them all.
What will gzip-the-compressor do when it encounters the following as a source : "generic-genreic-pi-pi" ? Which 1s came from gzip-the-generic-compressor ? Which 1s came from "pi" ? Even just the same algorithm can be coded purely differently in c an in pl. I expect the c version to be longer bytewise (it's english), shorter once compressed (must have approximately the same entropy per char as english) and faster (it always is). I expect the pl version to be shorter (It's like written chinese--to me anyway), longer once compressed (it's nothing but s or @s or &s) and slower (yes I now it got better). As for the BF version, it will be much longer (go forward by one, go fwd by one, inc 1, inc 1), much shorter once compressed (only 5 chars --> low entropy, many repeats --> RLE). Yes, I forgot to point out, nothing forbis us to add a generic entropy encoder in the codec system.
I never chose binary encoding, I barely quantified my encoding in binary, because that's what's been done sonce 1948. I speak nowhere of binary encoding, I only count in bits. But if you realy want a suggestion, just leave the digits the way they are. I do suppose if you take zillions of decimals, you do take the care to store everything as a huge binary number (that's what electronic computers are good at). Decimal, be it BCD or ASCII, would be too much a overhead (BCD is throwing away 0.68bits per decimal-hey, see, a decimal doesn't look BINARY to me, I used the term thoroughly in my parent post-, ASCII is throwing away 4.68bits per char). Don't even think about huffmann, distribution is uniform, huffmann is not good at that
isn't 355/113 by any chance just a partial sum of the taylor series that converges to pi ? No wonder it's so close...
3145926/1000000 is more precise and easier to understand
You, Sir, despite your low member number, would get an F- for information theory at the university I was tought and now teach.
There is nothing that compresses to one bit. There is such thing as a most efficient way of encoding any message. Counted in bits. and no, not just one bit. One bit would just contain enough information to say "Pi" or "Not Pi". "Not Pi" would according to my intuition not be an acceptable answer, you also have to say "What kind of 'Not Pi'". And that takes bits. You forgot that your algorithm is supposed to possibly generate all possible messages, or else it's "not fair".
Pi would not compress at all, given it's an infinitely long number. (To be precise, it's length would be reduced from inf to inf/(alphabet entropy) which is still inf, although a "smaller" inf). If you are content with a finite number of digits, its length would be reduced by about a little more than three bits per decimal (because log2(10)=3.???) with any decent entropy encoder. You could try to reduce this further by taking two decimal digits at once, but unfortunately it would not work, as not only are Pi's digits uniformly distributed from 0 to 9, pairs of digits are also distributed uniformly from 0-99, so you would remain with 6.???? bits (log2(100)) per decimal digits pair.
Another approach you might take, if you want infinite precision (silly on a finite machine), or more generally random precision, is to write a code in a predetermined programming language, in this case a series developement, or whatever the number thorists use nowadays to calculate pi, and decide that the "decompression algorithm" is a compiler (that is perfectly legal, as any finite message can be passed that way, eg "#include <iostream> int main(){cout << "The message";}").
My idea is that the c compression algorithm would be beat by a perl compression. Maybe try in BrainFuck, it might beat perl, but BF sucks at multiplications.
Anyway, the most optimal compression for pi is probably saying "Pi" by itself. Any decent geek knows at least one way to calculate that/ find it on project gutenberg/whatever. But don't ever think that you could compress it to two bytes or less : you gotta be sure that I will not understand "the string of decimal digits a.k.a. Pi, do write it in numbers when decompressing", not just "mu turned over", "Pi the string" or "Private investigator". This certainty takes bytes.
Another example is : "you cannot encode '3 4 8 15 3.141592653 78 54' as '3 4 8 15 pi 78 54', because that would increase the number of symbols in the alphabet, and all the other symbols would have to contain more bits as a result, so the compressed message length would suffer- hope there are a lot of 'pi' in the compresed message".
I must leave now, gotta go bowling with friends. Start your flames, I can see blatant holes in my reasonments. Hope you get the point. Mailing a link to the message to my signal theory professor (formally one of my bosses), so I will suffer if I told bullshit.
Gateway ships YOU with preinstalled DRM Red Army Choir music files.
It could be worse : you could be telling me damn lies about your benchmarks.
Reconfigurable High-Res Network Camera watch YOU
CFCs are not the cause for global warming, they're the cause for the hole in the ozone layer.
On the other hand, producing the sound waves will cost some electricity, the production of which is still mainly a main CO2 producer. So my idea is it will enhance the global warming, if anything.
Actually a question that always struck me is : what computers did the soviets use ? These people had a comparable space program, and yet I have never heard of the computers they were using. I tried a while ago to make some google searches (yes, I do know in soviet russia google searches YOU), but the only thing I found was a pay per view IEEE article. Does anyone know a good website on the matter ?
Refrigerators cool YOU
Next, I would have to PAY for my bonzi buddy !
Why do they stick at such poor quality anyway ? Compatibility ? My ass ! Everyone has a computer with IE6+ installed nowadays. The others are either not giving a fuck (lynx does not handle style anyway), either having a browser that supports the lowest common denominator (newer html tags are just ignored by well designed older browsers). And if you're still running Mosaic, you definitely do not give a fuck about how the fucking page looks like.
What do you think of slashdot's poor implementation of conform code ? Apparently, the w3c validator is not even allowed to have an opinion on the matter.
Yorkshire accent, what's that anyway, are you barking like a dog or something ?
Yes but are you black or white ?
My economy prediction is that comscore will soon file a chapter 11.
Next time don't vote for a communist ! Are you still allowed to play anything besides Tetris anyway ? Tetris will run just fine on your SMS3.
Last time I checked a 4.7 GB DVD can easily hold two hours films. So a 1TB HD gives you about 400 hours DVD quality video.
Phoenix, AZ has been called that way for decades before even the concept of a BIOS was born.
Why should this 3 million citizens city have to change name because of a stupid company that has only name recognition among nerds anyway ?
And what should they call it instead ? Arizona City ?
Ridiculous.