From jpsum00@mik.uky.edu Sat Oct 8 11:21:27 1994 Path: saips.cv.nrao.edu!hearst.acc.Virginia.EDU!darwin.sura.net!howland.reston.ans.net!europa.eng.gtefsd.com!MathWorks.Com!news.duke.edu!news-feed-1.peachnet.edu!ukma!mik.uky.edu!jpsum00 From: Joey Sum Newsgroups: comp.compression Subject: Re: binhex Date: 6 Oct 94 01:27:32 GMT Organization: University of Kentucky, Dept. of Math Sciences Lines: 18 Message-ID: References: <1994Oct5.123718.29975@cu23.crl.aecl.ca> NNTP-Posting-Host: nx54.mik.uky.edu In <1994Oct5.123718.29975@cu23.crl.aecl.ca> root@cu48.crl.aecl.ca writes: >Need BinHex 4.0 compatible IBM PC executable to unpack some .hqx files I found >on the net. Does anyone know where I can get such??? Sure, ftp to oak.oakland.edu in pub/msdos/mac Hope you remembered to turn MacBinary on when ftp'ing. Joey NOTE: This list was created on Wed Oct 5 11:58:45 EDT 1994 Directory SimTel/msdos/mac/ Filename Type Length Date Description ============================================== binhex13.zip B 45638 930530 Encode/decode a Macintosh BinHex 4.0 file xbin23.zip B 34636 910121 Decode a Macintosh BinHex file From bauernoe@scs.carleton.ca Sat Oct 8 15:31:51 1994 Newsgroups: comp.compression Path: saips.cv.nrao.edu!hearst.acc.Virginia.EDU!darwin.sura.net!haven.umd.edu!ames!hookup!yeshua.marcam.com!MathWorks.Com!news.duke.edu!news-feed-1.peachnet.edu!news.Gsu.EDU!gatech!howland.reston.ans.net!cs.utexas.edu!utnut!nott!cunews!bauernoe From: bauernoe@scs.carleton.ca (Frank Bauernoeppel) Subject: Re: Question: How to choose bit strings in arithmetic compression Message-ID: Sender: news@cunews.carleton.ca (News Administrator) Organization: Carleton University References: <37286q$bla@crl5.crl.com> Date: Fri, 7 Oct 1994 14:09:17 GMT Lines: 56 In article <37286q$bla@crl5.crl.com>, Spencer Low wrote: >DOYLE PATRICK (doylep@ecf.toronto.edu) wrote: >> I read the FAQ for this section, and I was wondering if someone >> could clarify this: in arithmetic compression, how, exactly, are the >> bit strings assigned to the symbol sequences? I understand that >> each symbol sequence will cover a range (within the interval [0, 1]) >> which is proportional to its probability. I just don't see how one >> gets from there to the bit string. > >Several weeks ago I was looking for sample compression code and several >nice newsgroup watchers posted a reference to _The Data Compression Book_ >by Mark Nelson. This book is really good and definitely worth it for >$39.95 with disks. It explains how arithmetic coding works (order 0-N). > >Cool. > >Spencer Lets try with a short explanation (before he buys a book): 1. theoretical point of view ---------------------------- Let [a,b] be the interval you have finally obtained. You may choose any number between a and b to represent your message and send the first say k binary digits. You have to send as many bits as are necessary to distinguish the interval from all others. The decoder reads the digits and can find the interval by the same process of subdivision. The message length should be transmitted separately. Some people include a special EOF code, but this is very errorprone. Note that if the interval is large, you are guaranteed to find a number with a short binary representation (approx. log |b-a| bit). 2. not so theoretical point of view ----------------------------------- There are problems when compressing on-line because you do not know the final interval in advance. You cannot even send the first digit if you are near 1/2 with your current interval. There are methods to avoid such effects in the literature... There are more issues (roundig, avoiding integer overflow,..) 3. practical point of view -------------------------- Get the lds_11.zip package (garbo.uwasa.fi) and take a deeper look at the source of lzari.c Greetings Frank --- Frank Bauernoeppel, Carleton Univ., Ottawa bauernoe@scs.carleton.ca -- bauernoe@scs.carleton.ca --- Frank Bauernoeppel From nevries@aip.nl Mon Oct 10 12:01:58 1994 Path: saips.cv.nrao.edu!hearst.acc.Virginia.EDU!concert!inxs.ncren.net!taco.cc.ncsu.edu!lll-winken.llnl.gov!sol.ctr.columbia.edu!howland.reston.ans.net!EU.net!sun4nl!aipnl!nevries From: nevries@aip.nl (Nico de Vries [AIP-NL]) Newsgroups: comp.compression Subject: Re: On-the-fly compression Distribution: world Message-ID: <781747173snx@aip.nl> References: <378q3o$rga@hermes.is.co.za> Date: Sun, 09 Oct 94 23:59:33 GMT Organization: AIP-NL (Ad Infinitum Programs) Lines: 33 kentron@apollo.is.co.za writes in article <378q3o$rga@hermes.is.co.za>: > > Hello, I would like to know if anyone knows of existing source code to > perform on-line data-compression; not the usual have-a-file-and-compress-it > but something that would read continuously the serial input and produce > compressed output. If we are using the "dictionary" methods then we can have > a sample of similar data as the one we are going to compress on-line, > build a dictionary and then use this dictionary for the real on-line > application. May not be optimal, but won't be far from it. A LZ engine combined with dynamic Huffman or arithmetic coding reasonably fits your description and has compression close to that of the LZ with static Huffman which is common nowadays. The maximum match length of the LZ engine woudl determine the amount of characters the output of the decompressor could be behind the input stream of the compressor. If the decompressor should not lag behing the input of the compressor at all, dynamic Huffman compression, arithmetic compression or higher order arithmetic compression can be used. In case higher order arithmetic compression is used, the compression will be beter than that of LZ + static Huffman, but much slower. > Thanks. > > George Uphall Take care, Nico de Vries. -- nevries@aip.nl [AIP-NL, UltraCompressor II development]