HDTenEightyP/NetNews huggingface dataset:
From: rolf@dna.lth.se (Rolf Karlsson)
Subject: Chair in Computer Science at Lund University
Organization: Dept of Computer Science, Lund University, Sweden
Date: Fri, 14 Aug 1992 12:24:34 GMT

	Lund Institute of Technology - Lund University - Sweden

		CHAIR IN COMPUTER SCIENCE

Candidates should have a distinguished record of original research in
Computer Science and proven teaching and leadership abilities. Current
research interests of staff include algorithm theory, programming
environments, artificial intelligence, and distributed systems, but
researchers in all areas of computer science are invited to apply.
The holder of an existing chair at the department conducts research
in algorithm theory. This position should be seen as a complement.

The School of Electrical Engineering and Computer Sciences at the
Lund Institute of Technology covers a wide and dynamic area of teaching
and research, with strong industrial connections. The teaching and
research activities can be divided into three main areas; electronics,
telecommunications and computer sciences. The school has 50 faculty
members, of which 10 hold chairs.

The Institute of Technology was founded in 1961 and constitutes the
Technical Faculty of Lund University, which was founded somewhat earlier,
in 1666. Lund lies 30 km east of Copenhagen, but in Sweden.

An application should include the following:

 * A brief description of scientific and pedagogical activities (one copy)
 * CV and a list of publications (one copy)
 * Publications (four copies, arranged in four separate packages)

Applications should be received by Lund University, Registrar, Box 117,
S-221 00 Lund, Sweden, quoting the reference number 6195, no later than
September 9, 1992.

Details concerning the nature of the position can be obtained from the
Faculty Dean, Professor Rolf Johannesson, School of Electrical Engineering
and Computer Sciences, Box 118, S-221 00 Lund, Sweden, Tel. +46 46 107517,
Fax +46 46 104714. Details regarding applications can be obtained from the
Personnel Director, Staffan Svensson, LTHs kansli, Box 118, S-221 00 Lund,
Sweden, Fax +46 46 104531.

Newsgroups: comp.ai
From: short@nssdcs.gsfc.nasa.gov (Nick Short (IDM))
Subject: public domain STRIPS planner available
Keywords: STRIPS, Planning
Organization: NASA Goddard Space Flight Center, Greenbelt, Maryland
Date: Thu, 13 Aug 1992 19:41:57 GMT

For anyone interested in planning,  our group implemented
both a classical and extended version of STRIPS in Common Lisp.  
We are making it available via anonymous ftp at

         sauquoit.gsfc.nasa.gov

The code is well documented and includes several example
files.

If you have any questions, comments, bug reports, hate mail
please send email to:

   idm-users@chelmsford.gsfc.nasa.gov
             (128.183.101.29)


Hey, your tax dollars at work,

Nick Short
IDM
NASA/GSFC


-- 

--------------------
Nick Short
Intelligent Data Management Project
Code 934
NASA/GSFC
Newsgroups: comp.ai
From: robm@ecr.mu.OZ.AU (Robert_Paul MUELLER)
Subject: Turing test
Organization: Dept. Of Engineering Computer Resources, Uni. Of Melbourne
Date: Thu, 13 Aug 1992 05:03:30 GMT


I while back (last year some time), I read an article in I think it
was Scientific American regarding an annual Turing test in which 10
judges would be put in front of 10 terminals and they had to decide
whether the person/thing at the other end was a person or a thing (ie
computer). The article mentioned that the performance of the programs
had been quite good. I am wondering if any of these programs are
generally available or anything else of that type.

Any help would be appreciated.

Please reply directly to me because I don't normally read this newsgroup.


/--------------------------------------------------------------------\
| Robert Mueller - robm@ecr.mu.oz.au  |   First year Sci/Eng student |
| Ask me about Desktop Utilities 3.3! |   University of Melbourne    |
\--------------------------------------------------------------------/
Newsgroups: comp.ai,comp.ai.shells
From: synchem@sbcs.sunysb.edu (Synchem proj acct)
Subject: public domain/freely available rule-based expert systems?
Organization: State University of New York at Stony Brook
Date: Thu, 20 Aug 1992 12:04:26 GMT


As part of my research, I'd like to obtain a number of rule-based
expert systems as test cases.  They should preferrably be coded
using CLIPS.  But OPS5 is OK, too.  If you know of any, I'd appreciate
your information.  Thanks for any pointers.

- Chyouhwa
From: sjameson@atl.ge.com (Stephen M Jameson)
Newsgroups: comp.ai
Subject: Re: Kolmogorov complexity
Date: 13 Aug 92 13:01:32 GMT
Organization: General Electric Advanced Technology Labs

In article <1992Aug11.020517.18834@kronos.arc.nasa.gov> wray@kronos.arc.nasa.gov (Wray Buntine) writes:

> >   I hope someone will follow up with some indication of whether anyone
> >   has actually cared about the constant factors.
> 
> The constant factor is all important because in practice we only have small
> sample sizes.  People who gloss over it usually have no experience at 
> competitive implementation (implementing an algorithm that *outperforms* 
> the *existing* competitors).
> 

I attended undergraduate school at Johns Hopkins and graduate school at U of
Maryland.  The CS cirriculum at Hopkins was quite theoretical, while the basic
graduate cirriculum at UofM was eminently practical, and I had a couple of
lessons in putting asymptotic complexity into perspective.  In my first
graduate course at UofM, we were discussing various data structures/algorithms
and reasons why one might prefer them and the professor indicated that option A
was better because option B required 2 extra bytes per structure for an
additional pointer or something like that.  My initial reaction was "who cares,
it's a constant factor," but the professor was not impressed.

In the second course, we were discussing a one point an algorithm which
required finding the mean of a set of numbers.  He pointed out that there is a
worst-case O(n) algorithm known for doing this, but "only an idiot would use
it" because it is horrendous to implement, and the one he suggested was far
simpler, and gave O(n) performance except in pathological cases.  I gulped,
having learned about the worst-case O(n) at Hopkins and having spent over a
week implementing and debugging it for a program I wrote on a summer job.

--
Steve Jameson                           General Electric Aerospace 
sjameson@atl.ge.com                     Advanced Technology Laboratories
                                        Moorestown, New Jersey              
****************************************************************************
**  . . . but I do not love the sword for its sharpness, nor the arrow    **
**  for its swiftness, nor the warrior for his glory.  I love only that   **
**  which they defend . . .                                               **
**    -- Faramir, "The Two Towers"                                        **
****************************************************************************
Newsgroups: comp.ai
From: eiverson@nmsu.edu (Eric Iverson)
Subject: Solving the 8 puzzle through hill climbing
Organization: Computing Research Lab
Distribution: comp
Date: Tue, 18 Aug 1992 08:06:23 GMT


Below is a brief series of steps to solve one configuration of the 8
puzzle.  I am looking for a fitness function such that each successive
step would be judged to be more fit than its predecessor, thus enabling
hill climbing.  I realize that hill climbing is not the best way to
solve the 8 puzzle, but that's what I want to do.  (No, this isn't
homework.  It's a question in Rich's textbook that I just happen to be
rereading.)  Any suggestions would be appreciated.

[1,2,3]
[8,5,6]
[4,7,*]

[1,2,3]
[8,5,*]
[4,7,6]

[1,2,3]
[8,*,5]
[4,7,6]

[1,2,3]
[*,8,5]
[4,7,6]

[1,2,3]
[4,8,5]
[*,7,6]

[1,2,3]
[4,8,5]
[7,*,6]

[1,2,3]
[4,*,5]
[7,8,6]

[1,2,3]
[4,5,*]
[7,8,6]

[1,2,3]
[4,5,6]
[7,8,*]

--
------------------------------------------------------------------------
Eric Iverson				Internet: eiverson@nmsu.edu
Computing Research Lab
Box 30001/3CRL				Life is something to do when
New Mexico State University		you can't get to sleep.
Las Cruces, NM 88003-0001			-Fran Lebowitz
VOICE: (505) 646-5711	
FAX:   (505) 646-6218
Newsgroups: comp.ai
From: kumar@syd.dit.CSIRO.AU (V.R.Kumar)
Subject: E-Mail address
Organization: CSIRO Division of Info Tech, Sydney, Australia
Date: Fri, 14 Aug 92 03:16:02 GMT

Can I have the e-mail address of Dept. of Mech. Engg.
of the University of Glasgow , UK ?

Thanks,

Kumar

kumar@syd.dit.csiro.au

-- 
 V.R.Kumar (Ramkumar Venkatachalam)                                 
 CSIRO, Division of Information Technology                         
 P.O.Box:1599, Macquarie Centre, North Ryde, NSW 2113, AUSTRALIA
From: miuvdd@lure.latrobe.edu.au
Newsgroups: comp.ai
Subject: FAQ Please!
Date: 17 Aug 92 04:12:18 GMT
Organization: VAX Cluster, Computer Centre, La Trobe University

Hi, I'm new to this newgroup (and the net for that matter! :)
I would appreciate it if someone could tell me if there is
a FAQ for this newsgroup, and how I might get my hands on a
copy.

Thanks

Morgana
miuvdd@lure.latrobe.edu.au
From: mackd@Sol28.essex.ac.uk (Mack D P)
Newsgroups: comp.ai
Subject: Conative Logics
Keywords: conative desires goals
Date: 18 Aug 92 16:30:03 GMT
Reply-To: mackd@essex.ac.uk (Mack D P)
Organization: University of Essex, Colchester, UK

Is anyone aware of any work (probably in philosophical logic) that
has been done concerning conative logics (logics of desire and goals)?
I am aware of some discussion of goals by Cohen, Levesque et al., but
nothing else.  I am particularly interested in anything which talks about
desires.

Thanks,

  Daniel
From: kmodiri@cs.ruu.nl (Kambiz Modiri)
Subject: kamer gezocht
Date: Tue, 18 Aug 1992 09:26:04 GMT
Organization: Utrecht University, Dept. of Computer Science

twede jaars informatica zoekt een kamer in Utrecht

 Tel : 033-728157
   
Newsgroups: comp.compression
From: fox@rei.com (Fuzzy Fox)
Subject: Re: Executables compressors
Date: Wed, 19 Aug 1992 15:44:49 GMT
Organization: Recognition Equipment, Inc.

bho@ocf.berkeley.edu (Bing Ho) writes:

>In a recent comment, Mr. de Vries (I apologize if the spelling is wrong!)
>mentioned that diet, pklite, or lzexe does better than stacker (and by
>extrapolation, super stor) on large executables.

>Now that I have read this, I am contemplating compressing some of those
>really largeexecutables that I have.

This may be a moot question, since really large executables tend to have
overlays built in, making it difficult (if not impossible) to compress
them and still allow them to execute.

So far, my favorite compress-any-EXE solution is a file called X.COM,
which keeps your EXE's in a .ZIP file, and uncompresses them when you
ask, with a command like "X <command> <parameters>".

-- 
#ifdef TRUE         | Fuzzy Fox                  fuzzy@netcom.com
#define  TRUE   0   | a.k.a. David DeSimone      an207@cleveland.freenet.edu
#define  FALSE  1   |
#endif              |         How's my posting?  Call 1-800-ALT-FLAME
Newsgroups: comp.compression
From: ST21519@VM.CC.LATECH.EDU
Subject: LHA (2.11) usage?
Organization: LOUISIANA TECH UNIVERSITY
Date: Thu, 20 Aug 92 20:27:52 CST

I'm trying to get LHA to read a file which is a list of files to be added to
an archive.  I've tried random command lines after my best educated guess did
not work.  I did not locate an example in the docs, but relied on the command
line help.  Here is my scenerio:
 
somefile.lst = the file with the list of filenames (with paths)
somefile.lzh = archive name desired
 
lha a /@somefile.lst somefile.lzh
 
What am I missing here?
 
Confused and grateful for any help...
Newsgroups: comp.compression
From: swesterback@tnclus.tele.nokia.fi
Subject: Modem transmition data compression?
Organization: Nokia Telecommunications.
Date: Mon, 17 Aug 1992 14:21:10 GMT

Hi, experts...

I would like some opinions about which type of simple/fast/not_too_effective
algorithm i should use to compress information transfered over a modem!

I have two cases:
1. A normal telephone modem and 8 bit code
2. A radio communications modem (7 bit code, 32...127) with reserved code
   sequences (at least "+?"=change over).

The information will be transfered, i.e. one row (80 char) at a time but 
possibly it is possibly to send every character/word separately or will 
that lower the compression?

And remember that i have very little knowledge about compression (i have
read about LZW :) ). Please reply by mail--i can post a summary here later.
Thanks!

-Sten-
 
============================================================================
B.Sc. Sten Westerback         Telephone: +358+0 +5115871(work) +740049(home)
Address: Mets{purontie  9 B19, SF-00630 Helsinki, FINLAND  Time zone: EET
Test the utility at WSMR-SIMTEL20.Army.mil::pd1:<msdos.dirutl>swxd303d.zip
NB! I am working, but not speaking for Nokia Telecommunications!
============================================================================
Newsgroups: comp.compression
From: dlwood@mothra.cns.syr.edu (David L Wood)
Subject: Re: Compression technique mentioned in PCW
Keywords: snake oil, something for nothing
Organization: Syracuse University, Syracuse, NY
Date: Wed, 19 Aug 92 01:00:28 EDT

In article <1992Aug18.155518@sees.bangor.ac.uk> mather@sees.bangor.ac.uk (Paul Mather) writes:

[ bit deleted ]
>Sounds like hot air?  (Yes, IMHO.:)
Yes.

>... the decimal fraction was compressed by
>determining two numbers, a and b, such that a/b = N.  To transmit the
>original file, one need only transmit a and b.  Decompression would
>involve calculating a/b and enumerating the result.

Well, If N = a/b. then a= b*N.  You also know that N < 1 meaning that
a < b.  If you factored out of N the value of the power of ten (negative)
that makes it a mantissa then you have a factoring problem.  The point
of this now is to find out all the factors of N and a sufficiently small
value for a.  For some cases, sure this MAY produce fewer bytes than the
original N.

You could try and try to brute force calculate a/b to approximate N
(I did this earlier today, eventually deciding on a technique which
always hopped between just over, and just under the real value of N,
which is a linear approach, in most cases.) --- or, since the values of
a and b that you get as a result are more easily calculated as factors,
then you're better off throwing this out and choosing a tree priented approach.

If this is at all similar to arithmetic encoding (which I have no books on :()
then it seems that you would have to 'tag' those groups of bytes that no
a/b combination could be found for.

If this isn't clear, think of the a/b combination for 0.127.  only 127/1000
will produce that decimal.  127 is a prime, no factors, no savings.

--
+-----------------------------+-----------------------------------------+
| dlwood@mailbox.syr.edu      | Gigs and gigs of NiCad memory, bummer.. |
| Cybernaut, with a thought.  | Why buy the leading brand; 90% hate it. |
+-----------------------------+-----------------------------------------+
Newsgroups: comp.compression
From: markh@csd4.csd.uwm.edu (Hunk)
Subject: Re: random access with .Z files
Organization: Computing Services Division, University of Wisconsin - Milwaukee
Distribution: comp
Date: Sat, 22 Aug 1992 05:08:58 GMT

In article <ROBERT.92Aug18172331@n051.saskg.semicon.sony.co.jp> robert@n051.saskg.semicon.sony.co.jp (Robert Veltman) writes:
>
>Is it possible to read a compressed file (LZW I think in the case of
>UNIX compress) and extract the dictionary information in order to be
>able to do random fseeks in the compressed file and decode from that
>point on?

The compressed file is the dictionary.  It's not stored seperately, it's
the whole thing!

However, I can think of a way that gets you close to random access.  Compress
blocks at a time, reinitializing the compression between blocks, and store
pointers to the compressed blocks in the file header.
Newsgroups: comp.compression
From: joeo@cbnewsi.cb.att.com (joseph.m.orost)
Subject: PKZIP TROJAN HORSE
Organization: Echo Logic
Date: Thu, 13 Aug 1992 11:07:15 GMT
Summary: erases all your files

I read this today in the Bell Labs E-News:

>>> PKZIP TROJAN HORSE -- A Trojan Horse in bogus versions of PKZIP
archiving software released to bulletin board systems has been discovered.
PCs running PC-DOS or MS-DOS are vulnerable to attempts to erase all the
files on the hard disk.

I don't have any more information.
Newsgroups: comp.compression
From: fox@rei2.uucp (Fuzzy Fox)
Subject: Re: DELETE PROTECTION AND FILE FIX UNDER ON-THE-FLY COMPRESSION
Date: Mon, 10 Aug 1992 19:07:57 GMT
Organization: REI

i12@cs-acad-lan.Lakeheadu.Ca writes:

> [...How does STACKER and similar software work with undelete utilities
>  and the like?...]

Device drivers like Stacker generally create a large file on your hard
disk, and then manage it as if it were another hard disk.  This means
duplicating the operations of the hard disk down to the sector level,
which means that programs like UnErase, DiskEdit, and EraseProtect (from
Norton) work flawlessly.  The programs work by compressing only the
individual sectors on the disk, without regard to which file they belong
to.  This yield lesser compression than common file archivers, but it
gives the needed compatibility.

To sum up:  The work great.

-- 
#ifdef TRUE         | Fuzzy Fox                  fuzzy@netcom.com
#define  TRUE   0   | a.k.a. David DeSimone      an207@cleveland.freenet.edu
#define  FALSE  1   |
#endif              |         How's my posting?  Call 1-800-ALT-FLAME
From: ian@unipalm.co.uk (Ian Phillipps)
Subject: Re: What is QIP format?
Organization: Unipalm Ltd., 216 Cambridge Science Park, Cambridge CB4 4WA, UK
Date: Thu, 13 Aug 1992 13:18:53 GMT

mikem@travis.csd.harris.com (Mike McCole) writes:

>I have what I'm sure is a compressed file that has a file extention 
>of .qip.  Any pointers on what it is compressed with and how it can
>be decompressed will be greatly appreciated. 

It's from Quarterdeck, and is used to compress DV/X distribution and
font files.  Use QUNPACK, which will be in your /DVX directory, to
uncompress.  QUNPACK -h gives help.

If you haven't bought a Quarterdeck product, you probably shouldn't have
that file :-)

Ian
-- 
Ian Phillipps, Unipalm Ltd, 216 Science Park,		Phone +44 223 420002
Milton Road, Cambridge, CB4 4WA, England.		Phax  +44 223 426868
	The road to hell is paved with melting snowballs - Larry Wall
Newsgroups: comp.compression
From: mather@sees.bangor.ac.uk (Paul Mather)
Subject: Compression technique mentioned in PCW
Organization: Centre for Applied Obfuscation.
Keywords: snake oil, something for nothing
Date: Tue, 18 Aug 1992 14:55:18 GMT
X-Posted-From: sol.sees.bangor.ac.uk
X-Posted-Through: sol.ctr.columbia.edu

A friend showed me a letter in a recent issue (Sep 1992) of Personal
Computer World magazine.  The letter was a comment on the article
PCW had written on "spectacular" data compression.  It had focussed
(somewhat sarcastically) on W.E.B.'s claimed 16:1 method, and, more
reasonably on Iterated Systems efforts.

Anyway, the thrust of the letter was not about those but was to
outline a method which seemed to illustrate that it was possible
to compress data outside the laws of information theory (and
other such W.E.B.-like claims), and indeed to multiply compress
the compressor's output.

Sounds like hot air?  (Yes, IMHO.:)

Well, the method the person outlined was the familiar one of representing
the bytes of a data stream as a decimal fraction N, where N is between 0
and 1.  A similar scheme was mentioned here during the WEB flame wars,
where compression was achieved by marking this number on a rod.  Decompression
involved precisely measuring the marked length and enumerating it. :-)

However, in the compression scheme mentioned in the letter, instead of
using a stout piece of oak :-), the decimal fraction was compressed by
determining two numbers, a and b, such that a/b = N.  To transmit the
original file, one need only transmit a and b.  Decompression would
involve calculating a/b and enumerating the result.

A further modification was suggested to the algorithm whereby the
file is partitioned into arbitrary sized chunks and each chunk treated
as a decimal number between 0 and 1 as before.  This would be done
in order to keep down the precision of the fractions (N's) to more
manageable limits and compression would involve finding a's and b's for
each chunk.  (The author of the letter suggested that this list of
a's and b's could be further compressed using the same technique.)

When my friend asked me what I thought of the proposed method, my gut
reaction was to say that finding the values of a and b sounded pretty
intractable to me.  It also occurred to me that it was likely that for
some N the enumeration of the integers a and b could be longer than N
itself but my number theory is very rusty so I didn't speculate on that
to my friend. :-)

Anyway, I just thought I'd mention it.

Cheers,

Paul.
-- 
e-mail: p.mather@sees.bangor.ac.uk

If your mailer can't reach me, I'm obviously not worth talking to.
From: nevries@accucx.cc.ruu.nl (Nico E de Vries)
Newsgroups: comp.compression
Subject: Re: DELETE PROTECTION AND FILE FIX UNDER ON-THE-FLY COMPRESSION
Date: 13 Aug 92 12:05:24 GMT
Organization: Academic Computer Centre Utrecht

In <169b62INNemt@agate.berkeley.edu> bho@ocf.berkeley.edu (Bing Ho) writes:

>I find it interesting that somebody would use pklite or diet or lzexe
>on a stacked drive, since stacker does about as well.  Furthermore,

For larger .EXE .SYS .COM files diet etc do better. Anyone using Clipper
will be very glad about that :-).

>I have found that archive programs actually store a higher density
>of information (when storing larger numbers of files)than stacker alone
>because of the ever-present cluster allocation problem.  Stacker helps
>somewhat by the 8k clusters, but there are still limitations.

This is not the main reason. The main reason archivers etc do better than
Stacker is the speed vs ratio limit. Stacker is faster than most
archivers but therefore has a worse compression ratio. Also notice there
are compressors even slower than ARJ with more compression. The limit
seems to be the Ashford compressor taking hours for an file at about
30% more compression than ARJ (see comp.compression FAQ for more info). 


Nico E. de Vries
_ _
O O  USENET nevries@cc.ruu.nl  FIDO 2:281/708.1  COMPUSERVE "soon" ???? 
 o   This text reflects MY opinions, not that of my employer BITECH.      
\_/  This text is supplied 'AS IS', no waranties of any kind apply.      
     Don't waste your time on complaining about my hopeless typostyle.

"I would admit my mistakes, if I had any ..."  (Bumper Sticker)
From: edhall@rand.org (Ed Hall)
Newsgroups: comp.compression
Subject: Re: random access with .Z files
Date: 21 Aug 92 21:40:59 GMT
Distribution: comp
Organization: RAND Corporation.

In article <93_n36j.kemnitz@netcom.com> kemnitz@netcom.com (Greg Kemnitz) writes:
>In article <ROBERT.92Aug18172331@n051.saskg.semicon.sony.co.jp> robert@n051.saskg.semicon.sony.co.jp (Robert Veltman) writes:
>=
>=Is it possible to read a compressed file (LZW I think in the case of
>=UNIX compress) and extract the dictionary information in order to be
>=able to do random fseeks in the compressed file and decode from that
>=point on?  
>
>zcat something.Z | do anything you want here

You've GOT to be kidding!  You can't seek on a pipe.  Even if you could,
you've effectively uncompressed the entire file before performing your
first random access.  This would defeat the purpose of the original request.

		-Ed Hall
		edhall@rand.org
Newsgroups: comp.compression,comp.theory