home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / patents / 984 next >
Encoding:
Text File  |  1992-07-25  |  1.3 KB  |  38 lines
  1. Newsgroups: comp.patents
  2. Path: sparky!uunet!munnari.oz.au!metro!basser.cs.su.oz.au!news
  3. From: md85-epi@byse.nada.kth.se (Urban Koistinen)
  4. Subject: [REQUEST] Replacement for compress
  5. Organization: Royal Institute of Technology, Stockholm, Sweden
  6. Date: Mon, 20 Jul 1992 16:06:30 GMT
  7. Approved: patents@cs.su.oz.au
  8. Message-ID: <1992Jul25.025107.5666@cs.su.oz.au>
  9. Sender: usenet@kth.se (Usenet)
  10. Nntp-Posting-Host: byse.nada.kth.se
  11. Lines: 25
  12.  
  13. In the GNU bulletin I see that a replacement for compress
  14. is wanted.  I have studied some data compression techniques,
  15. mostly variants of lz and huffman + some aritmetic coding.
  16. I have even written a program that compress better than
  17. compress, although it is too slow to be of much use.
  18. (It even compressed files compressed by compress some 1-3%)
  19.  
  20. .....
  21.  
  22. Speed, compression ratio, non-patented, how good must it be?
  23.  
  24. Is a program with about the same capabilities as compress,
  25. but without any known (to me) patents good enough?
  26.  
  27. I think a variation on huffman coding could be both fast
  28. and good enough, but how many variations on huffman coding
  29. are patented?
  30.  
  31. Urban Koistinen - md85-epi@nada.kth.se
  32. Current writer of GNU Chess 5.0 - it will be great!
  33. -- 
  34. Urban Koistinen - md85-epi@nada.kth.se
  35.  
  36. [mod- I was under the impression that Huffman coding was not patents,
  37. but dont quote me on this...]
  38.