Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!newsreader4.netcologne.de!news.netcologne.de!nx02.iad01.newshosting.com!newshosting.com!69.16.185.11.MISMATCH!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post01.iad.highwinds-media.com!newsfe05.iad.POSTED!aa923de6!not-for-mail Newsgroups: comp.compression From: stan Subject: Re: I have a small toy program... References: <1ae3367a-f07c-46bd-b521-65b3df34225f@q17g2000yqh.googlegroups.com> <0a83ccd1-410d-4d7f-a986-221d1d5e278f@k28g2000yqn.googlegroups.com> <18f1c133-0f05-4ced-b174-a1714d952452@p42g2000vbt.googlegroups.com> User-Agent: slrn/0.9.8.1pl1 (Linux) Message-ID: <93mhu8-olk.ln1@invalid.net> Lines: 58 X-Complaints-To: abuse@teranews.com NNTP-Posting-Date: Wed, 18 Jan 2012 02:10:04 UTC Organization: TeraNews.com Date: Tue, 17 Jan 2012 21:07:05 -0500 Xref: x330-a1.tempe.blueboxinc.net comp.compression:778 jules Gilbert wrote: > > I had intended to offer a small (70x byte .C program,) to interested > parties. The program compresses RAD input, and yes it uses zlib as > the compression engine. A program that may not be perfect in one or > two ways but you know, when I see large files crunched down to a few > hundred bytes I don't think it matters much. To use the term "compression" you must be able to decompress, otherwise you are simply shrinking data into a small mess. As long as you never decompress you can easily shrink any file into 1 bit in a single pass. > You and others who post here are used to thinking about compression as > a single step, because you see compression as something that can occur > once, assuming your using a modern, quality tool. Like zlib. You have repeatedly refused to make any real effort to understand any position other than your own. The above statement is a point of evidence. To be very clear, the number of steps in your process is in no way relevant to the validity of your claims. > The difference my methods provide is an escape from this "one-time > only" model. I have a method for representing a random buffer very > succinctly and losslessly recreating it. THIS is your repeated bogus claim, and your idea of preprocessing the data has been considered and studied thoroughly by some pretty smart people. > but I acknowledge that the problem was difficult and that as most > people look at the problem, it is indeed unsolvable -- because no > one, no one, violates natural laws. The problem, your claim, is not "difficult" it is one of those natural laws. The problem seems to be that while nobody violates these laws they are apparently beyond the grasp of some people. People who fail to understand frequently find apparent loopholes to get around the problem only to discover when the rubber hits the road that their loophole is in fact a pothole. > My program is real, Your claim is real, there is no evidence the program is real and you have yet to actually claim you can reverse the process. > The bad news is that my program operates on fixed-sized blocks of > data. I'm afraid the bad news isn't really that limited. > And before a bunch of you decided to interfere, Strange you seem to define refusal as interference. You came and made the same claims as before and got the same response, to expect otherwise is at best unwise.