64830

神经网络昆斯林的新闻组分类2006

XM3DY95D%,15]#04Q)1D]23DE!7U5302D*("`@('!R:6YT9B@B5F]T92!,86YD
XM;VX@3F]L;"!F;W(@4W5N;GEV86QE($-I='D@0V]U;F-I;"!S96%T(",Q+EQN
X:(BD["B-E;F1I9@H@("`@97AI="@P*3L*?0H`
X`
Xend
X---end---
X
X    Typically the build file should assume that the source is prog.c
X    and will compile into prog.  If an entry wins, we will rename
X    its source and binary to avoid filename collision.  By tradition,
X    we use the name of the entry's title, followed by an optional
X    digit in case of name conflicts.
X
X    If the above entry somehow won the 'least likely to win' award,
X    we would use chonglab.c and chonglab.
X
X    If your entry depends on, or requires that your build, source
X    and/or binary files be a particular name, please say so in the
X    ---remark--- section.  If this case applies, it would be be helpful
X    if you did one of the following:
X
X	* Tell us how to change the filename(s) in your entry.
X
X	* Have the build file make copies of the files.  For example:
X
X		cc prog.c -o special_name		need special binary
X
X	    or  rm -f special_src.c			need special source
X		cp prog.c special_src.c
X		cc special_src.c -o special_name
X
X	    or  rm -f special_build			need special build
X		tail +4 build > special_build
X		sh < special_build
X
X	* Assume that we will use the entry title.  Send us a version of 
X	  your build/program files that uses the name convention.  You 
X	  should uuencode these files in ---data--- sections.
X
X    If your entry needs to modify its source, info or binary files,
X    please say so in the ---remark--- section.  You should try to avoid
X    touching your original build, source and binary files.  You should
X    arrange to make copies of the files you intend to modify.  This
X    will allow people to re-generate your entry from scratch.
X
X    Remember that your entry may be built without a build file.  We
X    typically incorporate the build lines into a Makefile.  If the
X    build file must exist, say so in the ---remark--- section.
X
X    If your entry needs special info files, you should uuencode them
X    into ---info--- sections.  In the case of multiple info files,
X    use multiple ---info--- sections.  If no info files are needed,
X    then skip the ---info--- section.
X
X    Info files are intended to be input, or detailed information that
X    does not fit well into the ---remark--- section.  For example, an
X    entry that implements a compiler might want to provide some sample
X    programs for the user to compile.  An entry might want to include a
X    lengthy design document, that might not be appropriate for a
X    'hints' file.
X
X    Info files should be used only to supplement your entry.  For
X    example, info files may provide sample input or detailed
X    information about your entry.  Because they are supplemental,
X    the entry should not require them exist.
X
X    In some cases, your info files might be renamed to avoid name
X    conflicts.  If info files should not be renamed for some reason,
X    say so in the ---remark--- section.
X
X    Info files must uudecode into the current directory.  If they
X    absolutely must be renamed, or moved into a sub-directory, say
X    so in the ---remark--- section.
X
X    When submitting multiple entries, be sure that each entry has
X    a unique entry number from 0 to 7.  Your first entry should
X    have entry number 0.
X
X    With the exception of the header, all text outside of the entry
X    format may be ignored.  That is, don't place text outside of the
X    entry and expect the judges to see it.  (Our decoding tools aren't
X    AI progs!) If you need tell the the something, put it in the 
X    ---remark--- section, or send a Email to the judges at:
X
X	...!{apple,pyramid,sun,uunet}!hoptoad!judges	(not the address for
X	[e-mail]					 submitting entries)
X    
X    The date should be given with respect to UTC.  (Some systems refer 
X    to this as GMT or GMT0)  The format of the date should be that as 
X    returned by asctime() in the C locale.  An example of such a string is:
X
X	Thr Apr 01 00:47:00 1993
X
X    This format is similar to the output of the date(1) command.  The
X    string does not include the timezone name before the year.  On many 
X    systems, one of the following command will produce a similar string:
X
X	date -u "+%a %h %d %T 19%y"
X	date -u | sed -e 's/... \(19[0-9][0-9]\)$/\1/'
X	sh -c 'TZ=UTC date | sed -e "s/... \(19[0-9][0-9]\)$/\1/"'
X	sh -c 'TZ=GMT date | sed -e "s/... \(19[0-9][0-9]\)$/\1/"'
X	sh -c 'TZ=GMT0 date | sed -e "s/... \(19[0-9][0-9]\)$/\1/"'
X
X    You are allowed to update/fix/revise your entry.  To do so, set
X    the 'fix' line in the ---entry--- section to 'y' instead of 'n'.
X    Be sure that the resubmittion uses the same title and entry number
X    as well, as these are used to determine which entry is to be
X    replaced.
X
X
XJUDGING PROCESS:
X
X    Entries are judged by Larry Bassel and Landon Curt Noll.
X
X    Entries are unpacked into individual directories.  The Email message
X    is unpacked into individual files, each containing:
X
X	---entry--- section
X	all ---author--- sections
X	all ---info--- sections
X	---build--- section
X	---program--- section
X	any other text, including the Email message headers
X
X    Prior to judging, the 'any other text' file is scanned to be sure
X    it does not contain useful information (or in case the entry was
X    malformed and did not unpack correctly).  Information from the
X    ---author--- sections are not read until the judging process is
X    complete, and then only from entries that have won an award.
X
X    The above process helps keep us biased for/against any one particular
X    individual.  We are usually kept in the dark as much as you are
X    until the final awards are given.  We like the surprise of finding
X    out in the end, who won and where they were from.
X
X    We attempt to keep all entries anonymous, unless they win an award.
X    Because the main 'prize' of winning is being announced, we make all
X    attempts to send non-winners into oblivion.  We remove all non-winning
X    files, and shred all related paper.  By tradition, we do not even
X    reveal the number of entries that we received.  (for the curious,
X    we do indicate the volume of paper consumed when presenting the IOCCC
X    winners at talks)
X
X    After the Usenix announcement, we attempt to send Email to the
X    authors of the winning entries.  One reason we do this is to give
X    the authors a chance to comment on the way we have presented their
X    entry.  They are given the chance to correct mistakes, typos.  We
X    often accept their suggestions/comments about our remarks as well.
X    This is done prior to posting the winners to the wide world.
X
X    Judging consists of a number of elimination rounds.  During a round,
X    the collection of entries are divided into two roughly equal piles;
X    the pile that advances on to the next round, and the pile that does
X    not.  We also re-examine the entries that were eliminated in the
X    previous round.  Thus, an entry gets at least two readings.
X
X    A reading consists of a number of actions:
X
X	* reading the ---entry--- section
X	* reading the uudecoded ---build--- section
X	* reading the uudecoded ---program--- section
X	* reading the uudecoded ---info--- section(s), if any
X	* passing the source thru the C pre-processor
X	    shipping over any #include files
X	* performing a number of C beautify/cleanup edits on the source
X	* passing the beautified source thru the C pre-processor
X	    shipping over any #include files
X
X    In later rounds, other actions are performed:
X
X	* linting the source
X	* compiling/building the source
X	* running the program
X	* performing misc tests on the source and binary
X
X    Until we reduce the stack of entries down to about 25 entries, entries
X    are judged on an individual basis.  An entry is set aside because it
X    does not, in our opinion, meet the standard established by the round.
X    When the number of entries thins to about 25 entries, we begin to form
X    award categories.  Entries begin to compete with each other for awards.
X    An entry often will compete in several categories.
X
X    The actual award category list will vary depending on the types of entries
X    we receive.  A typical category list might be:
X
X	* best small one line program
X	* best small program
X	* strangest/most creative source layout
X	* most useful obfuscated program
X	* best game that is obfuscated
X	* most creatively obfuscated program
X	* most deceptive C code
X	* best X client (see OUR LIKES AND DISLIKES)
X	* best abuse of ANSI C
X	* worst abuse of the rules
X	* <anything else so strange that it deserves an award>
X
X    We do not limit ourselves to this list.  For example, a few entries are so
X    good/bad that they are declared winners at the start of the final round.
X    We will invent awards categories for them, if necessary.
X
X    In the final round process, we perform the difficult tasks of
X    reducing the remaining entries (typically about 25) down to 8 or 10
X    winners.  Often we are confident that the entries that make it into
X    the final round are definitely better than the ones that do not
X    make it.  The selection of the winners out of the final round, is
X    less clear cut.
X
X    Sometimes a final round entry good enough to win, but is beat out
X    by a similar, but slightly better entry.  For this reason, it is
X    sometimes worthwhile to re-enter an improved version of an entry 
X    that failed to win in a previous year.  This assumes, of course, 
X    that the entry is worth improving in the first place!
X
X    More often that not, we select a small entry (usually one line), a
X    strange/creative layout entry, and an entry that abuses the contest
X    rules in some way.
X
X    In the end, we traditionally pick one entry as 'best'.  Sometimes such
X    an entry simply far exceeds any of the other entry.  More often, the
X    'best' is picked because it does well in a number of categories.
X
X
XANNOUNCEMENT OF WINNERS:
X
X    The first announcement, occurs at a Summer Usenix conference.  By tradition,
X    this is done during the latter part of the UUNET/IOCCC BOF, just prior to
X    the Berkeley BSD, and BSDI BOF.
X
X    Winning entries will be posted in late June to the following groups:
X
X	    comp.lang.c		  comp.unix.wizards	alt.sources
X
X    In addition, pointers to these postings are posted to the following
X
X	    comp.sources.d	  alt.sources.d		misc.misc
X	    comp.sources.misc	  comp.windows.x
X
X    Winning entries will be deposited into the uunet archives.  See
X    below for details.
X
X    Often, winning entries are published in selected magazines.  Winners 
X    have appeared in books ("The New Hackers Dictionary") and on T-Shirts.
X
X    Last, but not least, winners receive international fame and flames!  :-)
X
X
XFOR MORE INFORMATION:
X
X    You may contact the judges by sending Email to the following address:
X
X	...!{apple,pyramid,sun,uunet}!hoptoad!judges	(not the address for
X	[e-mail]					 submitting entries)
X
X    Questions and comments about the contest are welcome.
X
X    One may obtain a copy of the current rules, guidelines or mkentry
X    program.  To obtain all 3 of them, send Email to the address above 
X    and use the subject 'send rules'.
X
X    One may also obtain the above items, we well as winners of previous
X    contests, via anonymous ftp from:
X
X	host: ftp.uu.net	(137.39.1.9)
X	user: anonymous
X	pass: yourname@yourhost
X	dir:  pub/ioccc
X
X    Often, contest rules, guidelines and winners are available from
X    archive sites.  Check comp.sources.unix archives, for example.
X    You may also request previous winners by Email, using the judges
X    Email address, though we ask that you do this as a last resort.
X
X
Xchongo <Landon Curt Noll> /\cc/\  	hoptoad!chongo
XLarry Bassel			  	{uunet,ucbvax,cbosgd}|sun!lab
SHAR_EOF
chmod 0444 guidelines ||
echo "restore of guidelines failed"
set `wc -c guidelines`;Wc_c=$1
if test "$Wc_c" != "25375"; then
	echo original size 25375, current size $Wc_c
fi
echo "End of part 1, continue with part 2"
exit 0
-- 
Sunnyvale residents: Vote Landon Noll for Sunnyvale City Council seat 1.