HDTenEightyP/NetNews huggingface dataset:
From: jcastner@nyx.cs.du.edu (John Castner)
Subject: Re: NO NUMBERS! (or even SHORT INTS!)
X-Disclaimer: Nyx is a public access Unix system run by the University
	of Denver for the Denver community.  The University has neither
	control over nor responsibility for the opinions of users.
Organization: Nyx, Public Access Unix at U. of Denver Math/CS dept.
Date: Sat, 3 Oct 92 17:34:35 GMT

In article <kaufman.718082916@Xenon.Stanford.EDU> kaufman@CS.Stanford.EDU writes:
>How about the following:
>
>GMST = 24110.54841 + (8640184.812866 + (0.093104 - 6.2e-6 * Tu) * Tu) * Tu;
>
>which is the equation for the relationship between Greenwich mean sidereal
>time and Universal time. (or was in 1985).  I could also post the equation
>for the nutation of the Moon, which has 19 terms.  Surely you don't expect
>someone to define constants for each of them...

I would guess that if you were writing a program with this expression, you
would be likely to need these numbers again.  Even if you didn't need
them anywhere else, constants would be nice.  Or better yet, since these
numbers had to come from some equation, probably other than this one,
compute them from more basic numbers like the length of the sidereal year
in seconds. (Plus, of course, a user entered value like the number of
leap seconds added so far this year.  :)  But I would never use numbers
like these as literal constants.  0, 1, 2, and traditional values like
XSub1, YSub1, XSub2, and YSub2 (for a distance formula) are as far as I go.

Of course, I don't know the meaning of the values in this expression
(since someone forgot to comment them!  :), so I could be wrong.
Still, they shouldn't be in the program statements like that.
--
+----------------------------------------------+
|jcastner@nyx.cs.du.edu                        |
|  186,000 miles per second:                   |
|    It's not just a good idea; it's the law.  |
From: rcarter@wpi.WPI.EDU (Randolph Carter <Joseph H. Allen>)
Newsgroups: comp.programming
Subject: Translators preserving comments
Date: 28 Sep 92 02:33:19 GMT
Organization: Worcester Polytechnic Institute
NNTP-Posting-Host: wpi.wpi.edu

Every once in a while I get the desire to make a really good ANSI-C to K&R-C
translator.  It's unque feature would be that it inserts appropriate
typecasts to preserve the exact meaning of the original ANSI code.  For
example:

	long a; double b; int c;
	void f(int,int,int,char *);

	f(a,b,c,0);

would be translated into:

	long a; double b; char c;
	int f();

	f((int)a,(int)b,c,(char *)0);

Anyway, that could easily be done with a real ANSI-C parser.  A neat
additional feature would be if it could preserve the comments properly.  My
best idea so far is to have the scanner attach the comments which appear to
the immediate left of any token to the token it passes to the parser.  The
parser then has to propogate the comment through the parse tree (or through
various levels if a parse tree is not made).  Then when new code is output,
the comments are generated as each level of the parse tree is unparsed.

Has anyone seen something similer to this?  I'm curious if and how anything
similer has been done in other translators (pascal to C is probably the
closest problem).  
-- 
/*  rcarter@wpi.wpi.edu */      /* Amazing */             /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Xref: sparky comp.programming:2797 comp.lang.c:14574 comp.lang.pascal:5854 comp.lang.objective-c:590
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.programming,comp.lang.c,comp.lang.pascal,comp.lang.objective-c
Subject: Re: NO NUMBERS! (or even SHORT INTS!)
Date: 6 Oct 92 05:33:36 GMT
Followup-To: comp.programming
Organization: Comp Sci, RMIT, Melbourne, Australia

In article <mcdonald.347@aries.scs.uiuc.edu>, mcdonald@aries.scs.uiuc.edu (J. D. McDonald) writes:
> In article <1992Oct2.083136.11412@ITcorp.com> geoff@ITcorp.com (Geoff Kuenning) writes:
> >(1) It is generally a mark of weak programming
> >(2) It is generally poor practice
> >(3) It is *always* poor practice
> 
> Sigmund Freud had a name for people who think like the above, and
> its not very pretty: Anal Retentive.

In this day and age, I am disappointed to see people clinging to an
outworn superstition.  I am also also disappointed by ad hominem attacks;
never mind the insults dredged from the vocabulary of a dying religion,
is Kuennin *right*?  Will Kuennin's advice help people to become better
programmers or not?

In fact, there is so much trash code around that Kuennin's attitude could
be more worthily described as wanting to _Expel_ the garbage.
-- 
RMIT policy requires the use of Gender Inclusive Language in all publications
and in all information conveyed to students, staff, and potential job
applicants.  Lapses into English are the sole responsibility of the author.
The Constitution of Australia does _not_ guarantee Freedom of Speech.
From: sboswell@sdcc13.ucsd.edu (Xianity is stupid)
Newsgroups: comp.programming
Subject: Re: reference counting garbage collection
Date: 4 Oct 92 19:16:35 GMT
Organization: University of California, San Diego

In article <NICKEL.92Oct4185459@desaster.cs.tu-berlin.de> nickel@cs.tu-berlin.de writes:
>> This post is a request for references to papers or books with guidelines 
>> for  the use of reference counting garbage collection.
>
>Sorry, I don't know any. But this article reminds of a question that
>never puzzled me enough to dig through the literature:
>
>How does reference counting garbage collection (RCGC) deal with
>circular data structures? 

It doesn't.  That's why other forms of garbage collection (tracing,
copying, etc.) dominate today.

George Row: I would suggest not using reference counting.  There are
many other algorithms out there today that do a much better job.
Not only do they deal with circular data structures quite well, but they
compact the heap & have better incrementality than reference counting.

An excellent introduction to uniprocessor garbage collection techniques
(including reference counting) is a paper called "Uniprocessor Garbage
Collection Techniques" by Paul R. Wilson.  Apparently it was submitted
to the International Workshop on Memory Management.  You can mail him
(wilson@cs.utexas.edu) and ask him where you can get a copy.

Steve Boswell
whatis@ucsd.edu
From: jos@and.nl (Jos Horsmeier)
Newsgroups: comp.programming
Subject: Lookahead (was: Re: Pascal vs C)
Date: 26 Sep 92 12:36:41 GMT
Organization: AND Software BV Rotterdam

In article <gram.717417205@aim1> gram@aim1.aztec.co.za (Graham Wheeler) writes:
[ sensible things about C vs. Pascali, and he continues: ]

|Incidentally, C is not in general a difficult language to compile; the most
|problematic aspect are the type declarations, where a considerable lookahead
|is needed. The typical approach is to build a tree from the declaration, and
|then traverse it (so it is done in two stages).

I beg to differ: there's no need to do any lookahead here. The problem
is located in the communication between the lexical analyzer and the
parser. The lexical analyzer doesn't know what to return to the parser
when it reads an identifier, i.e. it could be a user defined type or
just the name of a variable (local, global or parameter.) The trick
is that there are certain `points' in the grammar where the parser
definitely does or doesn't expect a user defined type name. If the
parser toggles a switch here, telling the lexical analyzer to return
a USER_TYPE token when it sees one, all works fine. In pseudo code,
the lexical analyzer does something like this:

id_or_type(token id) {

	if (switch_on) 
		if (isusertype(id))
			return(USER_TYPE);

	return(IDENTIFIER);

}

The only syntactic ambiguous construct where this trick fails is in
situations like this:

typedef int t;

int f(t)
int t;
{}

When the parser is beginning to parse the formal parameter list, it
can expect both things: user defined types and identifier names. 
After parsing the line `int f(t)' the parser decides to have `seen'
a function proto type and it expects a semi colon but it reads
another type (int.) It's the old style parameter declaration list
that causes the trouble here. The new style would have solved it:

int f(int t) 
{}

I agree that the first (old style) definition needs a considerable
amount of lookahead to parse this thing succesfully, but I've never
seen any compiler (ANSI-C conformant or not) that does it this way.
It's very tedious to implement and the quick hack I described above
works for all but this pathetical situation ...

kind regards,

Jos aka jos@and.nl
From: alanj@endeavor18.tek.com (Alan Jeddeloh)
Newsgroups: comp.programming
Subject: Re: NO NUMBERS! (or even SHORT INTS!)
Date: 6 Oct 92 16:37:34 GMT
Article-I.D.: shaman.1917
Organization: Tektronix, Inc.

In article <1906@shaman.wv.tek.com> I (Alan Jeddeloh) wrote:
><begin shouting>
>
>COULD YOU KINDLY SEPARATE CONSTANTS, OPERATORS AND VARIABLES WITH WHITESPACE
>SO SOMEBOBY CAN READ IT?
>
><end shouting>

I apologize.  I should not have shouted, and instead should have offered more
constructive critisism.  The code would be much easier to read and understand
if it was formatted more like the following.  Note that doing so is beyond
the capabilities of programs like `indent'.

	*dml =	(3.31364e-1 - (1.0281e-2 + 4.692e-3 * x1) * x1) * sx5 +
		(  3.228e-3 - (6.4436e-2 - 2.075e-3 * x1) * x1) * cx5 -
		(  3.083e-3 + (  2.75e-4 -  4.89e-4 * x1) * x1) * s2x5 +
		 2.472e-3 * sx6 +
		1.3619e-2 * sx7 +
		1.8472e-2 * s2x7 +
		 6.717e-3 * s3x7 +
		 2.775e-3 * s4x7 +
		 6.417e-3 * s2x7 * sx3 +
		( 7.275e-3 - 1.253e-3 * x1) * sx7 * sx3 +
 		 2.439e-3 * s3x7 * sx3 -
		(3.5681e-2 + 1.208e-3 * x1) * sx7 * cx3;

--
    Alan Jeddeloh      W:(503) 685-2991  H:(503) 292-9740
    Tektronix, Inc.  D/S 60-850; PO Box 1000; Wilsonville, OR 97070
    Alan.Jeddeloh@tek.com          Let sleeping dogs^H^H^H^Hbabies lie
    You can put the children to bed, but you can't make them sleep!
From: perm@csd.uu.se (Per Mildner)
Newsgroups: comp.programming
Subject: Re: hash function
Date: 5 Oct 92 14:35:27
Organization: Computing Science Dept.,Uppsala University, Sweden
Distribution: world
NNTP-Posting-Host: groucho.csd.uu.se
In-reply-to: sansom@dcs.glasgow.ac.uk's message of 5 Oct 92 10:08:54 GMT

This is from Communications of the ACM v33n6 (june 1990)

An algorithm by Peter K. Pearson (p677)

the basic idea (as described in the article and in the same pseudo code)
 h[0] := 0;
 for i in 1..n loop
   h[i] := T[ h[i-1] xor C[i] ] ;
 end loop ;
 return h[n]

where h[n] is the final hash code, C[i] is char i in the string to be
hashed and T[AlphabetSize] is any random permutation of eg 0..255.
of course the intermidiate h doesn't need to be kept.

It's easy to extend it to get 16 bit hashcodes and also cycle randomly
through the hashcodes for a given key ( ie cheap and good
rehash/secondary hash ).

The article also compares to some other methods and gives a way to
generate a T that gives a perfect hash function.

Regards,
--
Per Mildner			perm@CSD.UU.SE
Computing Science Dept.		tel: +46 18181049
Uppsala University, Sweden	fax: +46 18521270
Xref: sparky comp.programming:2718 comp.lang.c:14176 comp.lang.objective-c:552 comp.lang.pascal:5671
From: tm8t+@andrew.cmu.edu (Tod McQuillin)
Newsgroups: comp.programming,comp.lang.c,comp.lang.objective-c,comp.lang.pascal
Subject: Re: NO NUMBERS! (or even SHORT INTS!)
Date: 27 Sep 92 20:26:42 GMT
Organization: Carnegie Mellon, Pittsburgh, PA

jfr@RedBrick.COM writes:
>						      Why would you EVER
> use NUMBERS in a program.  Except in TWO places: inside quoted strings
> and on the right side of #defs (or the equivalent depending on the
> language).

Have you thought this through?  Do you really think that

	x *= TWO;
or
	#define DOUBLE(x) ((x)*=2)
	DOUBLE(X);

is preferable to just

	x *= 2;
?


	      There is no justification for using a number in a variable
> name or typedef or whatever.

Sure there is!  What about

	struct headers *rfc822(char *message) {...}
or
	srand48()
or even
	wait3()
?
				The above example should be vsi, si and li 
> or shint, regint, lngint or something like that.  JUST NAMES, NOT NUMBERS.
> Why?  Because using numbers causes a confusion in the event that you 
> decide to change the platform or the concept.  It is fair to say that
> a lngint must be equal to or longer than a regint, but I contend it is
> erroneous and misleading to say that an int4 must be EQUAL TO or longer
> than an int2.  Longer than, maybe, but EQUAL TO?  That is just wrong.
> In fact, int4 and int2, by normal thought processes, expresses an exact
> 2:1 relationship.  And the fact that I can change that in a hidden way
> does NOT make things clearer, it makes things muddier.

In this case, maybe.  In general?  Probably not.  But even if you're
right, your next statement is draconian and (pardon me but I must be
blunt) stupid.

> So I suggest a coding standard: numbers should be barred from use in
> variable and type names.  Only letters can be used.  Numbers can only
> appear where you define manifest constants (#def, const, etc.) to 
> names and inside strings (where they generally do no harm).  
> 
> Any comments?

Sorry, but I disagree.

--tod
From: mgmam@uxa.ecn.bgu.edu (Mark A. Morrell)
Newsgroups: comp.programming
Subject: Re: Costs per line of code
Date: 1 Oct 92 04:41:18 GMT
Organization: Educational Computing Network

In article <1992Sep20.204323.23602@afterlife.ncsc.mil> sjr@afterlife.ncsc.mil (Stephen J. Roznowski) writes:
>I'm looking for some estimates for what it costs to produce/document/maintain
>a line of code. What I'm trying to compute is the "worth" of a software
>package.
>
>For example, if a line of code cost about $50.00 to produce, then a 10,000
>line package represents an investment of $500,000.00.
>
>Thanks,
>-- 
>Stephen J. Roznowski	(sjr@afterlife.ncsc.mil)

I am going to have to agree with everyone else on the idea that cost per
line of code is a poor measurement of the value of a software package.
However I think that the actual "worth" of a software package needs to
be measured in a slightly different way than the other responses have
indicated.

The "worth" of software developed in house will be a function of how
much time (and other resources) your programmers took to develop it
versus how much it would cost to do the same task without the program,
and, assuming the program will actually generate revenue, how much the
program will make you.

I can't think of a fairer way to measure the actual value of a
program.

Mark A. Morrell
Disclaimer:  Opinions expressed are not necessarily my own.
Newsgroups: comp.programming
From: tada@athena.mit.edu (Michael J Zehr)
Subject: Re: Costs per line of code
Organization: Massachusetts Institute of Technology
Date: Mon, 28 Sep 1992 16:01:01 GMT

In article <1992Sep28.053826.12290@ttinews.tti.com> kevin@drogges.tti.com (Kevin Carothers) writes:
>In article <19lu8pINNkhm@rodan.UU.NET> avg@rodan.UU.NET (Vadim Antonov) writes:
>%In article <-191659999@hpopd.pwd.hp.com> richi@hpopd.pwd.hp.com (Richard Jennings) writes:
>%>If a software engineer costs (say) US$150000/year [1], including all overheads
>%Wow. Wow. I'd love to [be paid] US$60 per line
>
>It's very easy to get caught up with thinking that "my programs are more
>complicated than yours"  especially when you don't know what the payroll
>or applications programmer is doing.

There are other factors as well.  An applications programmer is expected
to maintain the code, perhaps for several years (and often while working
on someone else).  I don't know how one gets requests for changes in
device drivers, but it happens a lot with (custom anyway) applications.

But obviously both jobs are difficult or else why would the best ones
get paid a lot for doing it?

And keep in mind that the programmer isn't getting $150,000 a year, but
more like $50,000.  (proof by the payroll equals 1/3 of expenses rule!
*grin*)

-michael j zehr
NOTE: my reply address will soon be tada@silver.lcs.mit.edu
From: ai686@cleveland.Freenet.Edu (Ishaq Syed)
Newsgroups: comp.programming
Subject: C programing
Date: 6 Oct 1992 17:57:07 GMT
Organization: Case Western Reserve University, Cleveland, Ohio (USA)
NNTP-Posting-Host: slc10.ins.cwru.edu


I am highschool student..and I would like to request a book that
would teach me C in a si,mple way.  All the books I have incountered
so far have been very complcateed.  I would like a name of a book that
is good for self learning people.  The place I can buy the book would also 
be nice.  Thank you very much.

				ishaq
-- 
           *_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*
           *_           ISHAQ SYED                            _*
           *_           E-MAIL:ai686@cleveland.freenet.edu    _*
           *_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*
Newsgroups: comp.programming,comp.lang.c,comp.lang.pascal,comp.lang.objective-c
From: kaufman@Xenon.Stanford.EDU (Marc T. Kaufman)
Subject: Re: NO NUMBERS! (or even SHORT INTS!)
Reply-To: kaufman@CS.Stanford.EDU
Organization: CS Department, Stanford University, California, USA
Date:  3 Oct 92 03:28:36 GMT

geoff@ITcorp.com (Geoff Kuenning) writes:

>(2) It is generally poor practice to use numeric constants (other than
>0, 1, occasionally 2, and [*very* rarely] certain bit masks) in the
>body of program code.

How about the following:

GMST = 24110.54841 + (8640184.812866 + (0.093104 - 6.2e-6 * Tu) * Tu) * Tu;

which is the equation for the relationship between Greenwich mean sidereal
time and Universal time. (or was in 1985).  I could also post the equation
for the nutation of the Moon, which has 19 terms.  Surely you don't expect
someone to define constants for each of them...
-- 
Marc Kaufman (kaufman@CS.Stanford.EDU)
From: sjr@afterlife.ncsc.mil (Stephen J. Roznowski)
Newsgroups: comp.programming
Subject: Re: Costs per line of code
Date: 29 Sep 92 01:06:13 GMT
Organization: The Great Beyond

Tony Wingo writes:
>
>And an exercise for the reader:
>
>"If one worker can dig a posthole in five minutes, how long would it take
>ten workers to dig the same posthole?"

I prefer to think of the original question as follows:

If a worker digs an average of 12 postholes an hour earning $10.00 per
hour, approximately how much will it cost me to dig 120 postholes with
10 workers? [and to really get back to the intent of the original question
how much are those postholes worth?]

-- 
Stephen J. Roznowski	(sjr@afterlife.ncsc.mil)
From: jonathan@mantis.co.uk (Jonathan Egre')
Newsgroups: comp.programming
Subject: Re: Costs per line of code
Date: 23 Sep 92 15:53:26 GMT
Organization: Mantis Consultants, Cambridge. UK.

avg@rodan.UU.NET (Vadim Antonov) writes:

> In article <-191659999@hpopd.pwd.hp.com> richi@hpopd.pwd.hp.com (Richard Jenn
> >If a software engineer costs (say) US$150000/year [1], including all overhea
> >and she writes 10 lines of code per day [2]
> 
> Wow. Wow. I'd love to join that organization. I'd f* off all those
> overpaid executives :-) Why nobody pays me US$60 per line? And i'm
> not a Pascal or COBOL programmer -- my job is writing device drivers,
> a bit trickier stuff than spitting out payrolls!
> 
> Life is unfair, i guess.

I think the figure of $150,000/year includes lots of overheads: office space,
equipment, phone bill, training bills, a quarter of a secretary, a tenth of a
manager, a tenth of an accountant, social security or pension contributions 
which do not show up on the software engineer's payslip, etc.

Similarly, the 10 lines of code per day also includes (or do I mean 
"excludes"?) a lot of overheads: time spent on documentation, time spent
discussing requirements with the client, time spent testing, time spent on
training, time spent replacing 1000 lines of code with a different 1000 lines
of code because the client changed his or her mind, etc.

-- Jonathan Egre' = jonathan@mantis.co.uk = jonathan_e@cix.compulink.co.uk --

From the Usenet Dictionary of English Usage:
clueless: Adjective describing someone with opinions different from your own
                     
Xref: sparky comp.programming:2798 comp.lang.c:14576 comp.lang.pascal:5855 comp.lang.objective-c:591
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.programming,comp.lang.c,comp.lang.pascal,comp.lang.objective-c
Subject: Re: NO NUMBERS! (or even SHORT INTS!)
Date: 6 Oct 92 06:06:09 GMT
Followup-To: comp.programming
Organization: Comp Sci, RMIT, Melbourne, Australia

In article <1ao349INNbb2@uwm.edu>, markh@csd4.csd.uwm.edu (Mark) writes:
> #define R 6378000.0
> #define PI 3.1415926
> void Stats(Vector r, Vector v, double t) {
>    double tR, tV, mR, mV; char Dir;
>    tR = atan2(r.Y, r.X)*180.0/PI;

It is good to give meaningful names to things.
It is even better when the names are truthful.
pi is not 3.1415926; if you round it to 8 digits you get 3.1415927
And why round it to 8 digits?  I once ran into serious numeric trouble
in a Macintosh program where the calculations were done in 80 bit arithmetic
but PI had been rounded to 64 bits.

What we really want for things like this is the proposed Ada interface,
where you can say how many "things" there are in a complete circle, e.g.
	tR := atan(X => r.X, Y => r.Y, Cycle => 360);

This code fragment is a perfect example of something which deserves to be
named.  Myself, I might do

	#include <math.h>
	#if	DEGREE_TRIG_PROVIDED
	extern double atan2d(double, double);
	...
	#else
	#ifndef	M_PI
	#define M_PI 3.14159265358979323846
	#endif
	#define HALF_CIRCLE_OVER_PI (180.0/PI)
	#define	atan2d(x, y) (atan2(x,y)*HALF_CIRCLE_OVER_PI)
	...
	#endif

	void Stats(Vector r, Vector v, double t)
	    {
		double tR = atan2d(r.Y, r.X);
		...
	    }

I have often found code for special functions in books and journals that
_would_ be useful except that they have rounded the coefficients and
truncated the series to fit a particular machine, and it doesn't fit mine.

-- 
RMIT policy requires the use of Gender Inclusive Language in all publications
and in all information conveyed to students, staff, and potential job
applicants.  Lapses into English are the sole responsibility of the author.
The Constitution of Australia does _not_ guarantee Freedom of Speech.
Newsgroups: comp.programming,comp.sys.next.programmer
From: shiva@vega.Stanford.EDU (Marcos Javier Polanco)
Subject: Agent-Oriented Programming: Request for Information
Organization: DSO, Stanford University
Date: Wed, 30 Sep 92 21:50:26 GMT


Hello.

I am looking for papers or articles about agent-oriented programming.

If you could direct me to some, I would certainly appreciate it.

Thanks.

-Marcos J. Polanco
-shiva@vega.stanford.edu
-415-691-2255
From: daveb@Ingres.COM (Dave Brower, DBMS hack, [510] 748-3418)
Newsgroups: comp.programming
Subject: Re: Daylight saving time (UK)
Date: 30 Sep 92 00:53:23 GMT
Reply-To: daveb@lotus (Dave Brower, DBMS hack, [510] 748-3418)
Distribution: uk
Organization: Ingres, an ASK Company
Originator: daveb@lotus
In-reply-to: dsg@impmh.uucp (Dave Gordon)

In article <1992Sep28.170200.705@impmh.uucp>, dsg@impmh (Dave Gordon) writes:
>In <1992Sep24.151232.14461@rtf.bt.co.uk> bonnaud@rtf.bt.co.uk (Neil Bonnaud) writes:
>>
>>  are the dates [of GMT/BST change] calculated (e.g. always the last Sunday
>>  in October) so an algorithm can be used or is it an arbitary decision by
>>  the powers that be (i.e. enter changeover dates in advance)???
>
>I tried to find an algorithm for this many years ago ... unsuccessfully.
>I have heard that it is an arbitrary decision on a year by year basis; I
>also heard that some diaries have been known to mark in the dates of
>changeover as 'provisional' i.e. they have gone to press before the
>official word has been received.
>
>Anyway, good luck in trying to find out whether there really is an
>algorithm; if you find one, I'd like to know about it...

Yes, there is.  It's called "table lookup", and the best complete
version is the "olson" (by Arther Olson) code available from any
comp.sources archive; it is also what is included on the recent BSD
releases, and used on SunOS.  The code is completely PD, and may be
used in anything.

-dB
Newsgroups: comp.programming