HDTenEightyP/NetNews huggingface dataset:
From: curt@watson.ibm.com (Curt McDowell)
Subject: Re: Any simple Random Number generators?
Date: Thu, 20 Aug 1992 14:32:44 GMT
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
Organization: IBM T.J. Watson Research Center
Keywords: random, shift

In article <1992Aug18.143439@fdr.jsc.nasa.gov>, shirley@fdr.jsc.nasa.gov (Bill Shirley [CSC]) writes:
> 
> If you just want it to reseed differently
> 
> random(time())  
> 
> will do it
> -- 
> Bill Shirley		|  ``Computer Science is not about computers any 
> shirley@fdr.jsc.nasa.gov|	more than astronomy is about telescopes.''

No, that won't quite do it.  Firstly, the call is srandom.  Secondly,
time() requires an argument or it will core dump.  What you wanted to
say was srandom(time(0)).

A slightly better way is srandom(time(0) + getpid()), since if your
program runs quick it might be run more than once a second (e.g. from a
shell script).

Here are my favorite convenience #defines when my program is not in
a hurry:

#define rander() (((unsigned long) random() << 5) ^ \
		   (unsigned long) random()       ^ \
		  ((unsigned long) random() >> 5))

#define srnd()   srandom(time(0) + getpid())
#define rnd(n)   (rander() % (n))

Here is my favorite way to generate vaguely random numbers when my
program is in a tremendous hurry (e.g. as for test data).  It's a
pseudo-random shift register of the type detailed in a previous note
from Andy Collins, cycling through every possible bit combination
except 0 before recycling.  The numbers are far from ideally random,
but it's very fast.  You may be able to find a way to make them
appear more random.

/*
 * randomize_buffer
 *
 *   Fill a buffer of 'len' unsigned longs with semi-random data.
 */

void randomize_buffer(buf, len)
	unsigned long  *buf;
	int		len;
{
	unsigned long	b;

	while ((b = rander()) == 0)
		;

	while (len--) {
		*buf++ = b;
                b = b << 1 | (b >> 30 ^ b >> 27) & 1;
	}
}

--
Curt McDowell
IBM T. J. Watson Research Center
Newsgroups: comp.programming
From: crawford@church.mitre.org (Randy Crawford)
Newsgroups: comp.programming
Subject: Re: Teaching by Value (was Re: Teaching the Basics)
Date: 20 Aug 92 04:41:00 GMT
Organization: The MITRE Corporation, McLean, VA

In article <1992Aug19.142513.14893@husc13.harvard.edu> peregrin@husc13.harvard.edu writes:
...
>	Should efficiency really be a concern at the introductory
>level? Should that concern be reduced so that more time can be spent on
>problem solving?
>
>	If you look at your programming peers, are you more concerned that
>they can write easily maintainable code than if they can write super-slick
>fast routines?  Who do you want on your programming team?  Should the
>majority of programmers be writers of clean, easy to read and maintain
>code, and only a few are needed to right tight, fast, efficient routines?

In the words of Samuel Johnson (as paraphrased by Charniak, McDermott, Riesbeck,
and Meehan) "we advise you to look over your code very carefully, and whenever
you find a part that you think is particularly fine, strike it out."

I think efficiency is always a concern.  However, there is efficient code and 
there is clever code.  Efficient is good; clever (usually) is not.  I see
the difference as:  efficient code is marked by a lack of waste; clever code is 
a weird trick which is unnaturally efficient.  Weird code is interesting and 
fast, but is generally illegible, unmaintainable, and unextensible.  Excessively
efficient code is almost never worth its other excesses.

The only time that cleverness may be preferable is in routines which will be 
reused extensively, as in libraries, or in computationally intensive algorithms
where efficiency is everything.  

So in answer to your last question:  Yes.  Very few programmers need to be 
"clever".  The rest of us should focus on writing efficient readable code.

Randy
crawford@mitre.org
-- 

| Randy Crawford        crawford@mitre.org        The MITRE Corporation
|                                                 7925 Colshire Dr., MS Z421
| N=1 -> P=NP           703 883-7940              McLean, VA  22102
Newsgroups: comp.programming
From: cscc13@judy.uh.edu (NAVEED IQBAL)
Subject: Any simple Random Number generators?
News-Software: VAX/VMS VNEWS 1.41    
Organization: University of Houston
Date: Thu, 13 Aug 1992 23:22:00 GMT

I want to know how random numbers are generated.
I want to get a "new" random number everytime I run the program.
I did download a program to do that from wuarchive but I was wondering
if there was a simpler way.


Thanx
Naveed Iqbal
NIqbal@uh.edu


Xref: sparky comp.programming:2424 comp.unix.programmer:4397 comp.lang.c:12626 comp.arch:9002
From: bet@cyclone.sbi.com (Bennett E. Todd)
Newsgroups: comp.programming,comp.unix.programmer,comp.lang.c,comp.arch
Subject: Re: What would you like in a debugger?
Date: 21 Aug 92 00:25:52 GMT
Followup-To: comp.programming
Organization: Salomon Brothers, Inc

I'd like to see a debugger with fewer bugs than my code:-(. The only
debugger I've never ever been able to bomb off was adb. And before sneering
too violently at adb, you really oughta experience running adb from a jove
shell window, using the macros under /usr/lib/adb, to root through the data
structures of your currently-running kernel. Yow!

The most useable source-level debugger I've used so far as gdb; I seem to
recall having confused it more than once, but it isn't so fragile as dbx.


One thing I'd insist on: a debugger should have a line-oriented interface.
If you want to do a full-screen or graphic interface on _top_ of it, like
dbxtool under SunTools or like gdb-mode in GNU Emacs, well that is terrific,
and I like using those interfaces, when I can. But if it doesn't have a
plain line mode that I can run from within an editing window, and copy stack
traces into bug reports and so on, then it just isn't as useful.

-Bennett
bet@sbi.com
Newsgroups: comp.programming
From: boyd@prl.dec.com (Boyd Roberts)
Subject: Re: ANSI C, was Re: Teaching the basics
Organization: Digital Equipment Corporation - Paris Research Laboratory
Date: Sat, 22 Aug 1992 11:32:19 GMT

In article <1992Aug22.034214.19539@linus.mitre.org>, crawford@church.mitre.org (Randy Crawford) writes:
> 
> And why would you want to defer the task until the link step?  Don't you _want_ 
> to be told ASAP that your argument types don't match those of the function you 
> are calling or that you've provided the wrong number of arguments in the call?
> 
> That's the reasoning behind why compilers and linkers rely on function 
> prototypes.

Nonsense.  Prototypes are cheap hack, and they can lie, whereas the actual
function declaration specifies it exactly.  The protypes just say that the
calls agree with the prototypes, and that's not the same as the actual
declaration.

Putting extra info in the object would be a total win.  Why should I go to
declare my functions twice, when the machine can do that stuff for me?


Boyd Roberts			boyd@prl.dec.com

``When the going gets wierd, the weird turn pro...''
From: sdms@bnr.ca (Andrew Sterian)
Newsgroups: comp.programming
Subject: Re: Teaching the basics
Date: 20 Aug 92 16:42:09 GMT
Organization: Bell-Northern Research, Ottawa, Canada

In article <ratner.714247759@ficus.cs.ucla.edu> ratner@ficus.cs.ucla.edu (David Ratner) writes:
>I most wholeheartedly agree.  At Cornell, where I did my undergrad, 
>the first two computer programming classes are both taught in Pascal, 
>both because Pascal is a more structured langauge than C (the compiler
>complains much more often and is more strict than a C-compiler), and
>because I feel it is "easier" as a introductory language, primarily
>because of the difficulty in C with pointers.  Introductory students
>have enough to worry about without having to learn about pointers
>right off.  In C it just isn't that practical to do anything complicated
>without using pointers.

Hmmmm...I disagree on this one. It may have been true some years ago that 
the type checking etc. of Pascal made it easier on novice programmers but
the latest ANSI C compilers do just as good a job of it as Pascal. I also
don't feel it is a good idea to shield novice programmers from pointers. They
will just end up with a "pointer phobia" and will find it hard to pick them
up later on.

>Another reason to use Pascal.  C has the wonderful feature that you can write
>incredibly obtuse code, and while it is possible to teach good coding
>practices in C, I would argue that it is easier in a more structured
>language like Pascal.

Trust me, you can write incredibly obtuse code in Pascal. Writing clear
code should be part of any beginning programming course. I also don't see
how it is easier to *teach* good coding practices in Pascal. A good teacher
can teach good coding practices in any language.

I didn't post this to start a Pascal vs. C holy war. In my experience,
however, being forced to program in Pascal for my introductory courses
(waaay back) was a frustrating experience. It was even worse because at the
time we were forced to use a context-sensitive editor ("Alice") which
enforced the Pascal syntax as you were editing. It was supposed to help
you learn the language in that it was impossible for you to create a 
program which had syntax errors. It was a nightmare.

Andrew.
-------------------------------------------------------------------------
Not the opinions of BNR          | For the teddy bear who has everything:
Andrew Sterian (613)765-2562     | a person.
asterian@bnr.ca                  |
Newsgroups: comp.programming
From: dak@kaa.informatik.rwth-aachen.de (David Kastrup)
Subject: Re: Any simple Random Number generators?
Organization: Rechnerbetrieb Informatik  /  RWTH Aachen
Date: 15 Aug 92 10:30:09 GMT

>In article <13AUG199218224504@judy.uh.edu> cscc13@judy.uh.edu (NAVEED IQBAL) writes:

>>I want to know how random numbers are generated.
Well, suggesting that you save your last number, in 32bit unsigned systems
you can get good 32-bit numbers by multiplying the last value with 69069
and adding 1. This pretty good, easy to memorize number generator is ana-
lyzed in The Art of Computer programming vol. 2.

You have to use the higher bits when wanting a small random number, or the
behaviour will be terrible. That is, use ((long long)rand * 25 >>32) for
a number from 0 to 24.
Newsgroups: comp.programming
From: boyd@prl.dec.com (Boyd Roberts)
Subject: Re: ANSI C, was Re: Teaching the basics
Organization: Digital Equipment Corporation - Paris Research Laboratory
Date: Fri, 21 Aug 1992 23:20:22 GMT

In article <1992Aug21.154839.2664@organpipe.uug.arizona.edu>, dave@cs.arizona.edu (Dave Schaumann) writes:
> 
> IMHO, you should do it anyway.  Make your own header files with the
> appropriate prototypes if you need to.

I just can't see the worth in function prototypes.

Now, a type checking loader would be a fine thing.
So just what is the problem here?  Why can't I buy one?


Boyd Roberts			boyd@prl.dec.com

``When the going gets wierd, the weird turn pro...''
Newsgroups: comp.programming
From: prener@watson.ibm.com (Dan Prener)
Subject: Re: ANSI C, was Re: Teaching the basics
Date: Sun, 23 Aug 1992 08:28:30 GMT
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
	<1992Aug21.232022.28931@prl.dec.com>
	<1992Aug22.034214.19539@linus.mitre.org>
Organization: IBM T.J. Watson Research Center, Hawthorne, New York

In article <1992Aug22.034214.19539@linus.mitre.org> crawford@church.mitre.org (Randy Crawford) writes:

  [ ... stuff omitted ... ]

>>Now, a type checking loader would be a fine thing.
>>So just what is the problem here?  Why can't I buy one?

>You can.  It's called a VAX.  However, in Unix, ld (the linker) has lost all
>type information by the time the link occurs.  Unless you change the object
>file format to keep argument and function types around after compilation, no 
>linker will have the information needed to do the job.

The ld in AIX on IBM's RS/6000 does such type checking, if one compiles with
the option that asks the compilers to put type information into the .o files.

It is optional because many people want to lie across calls to separately
compiled routines.
--
                                   Dan Prener (prener@watson.ibm.com)
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.programming
Subject: Re: Teaching the basics
Date: 18 Aug 92 01:06:26 GMT
Organization: Comp Sci, RMIT, Melbourne, Australia

In article <1992Aug17.123916.14815@husc13.harvard.edu>, peregrin@husc13.harvard.edu writes:
> 	This course is meant to teach students the basics.  Even though it
> is in C, we don't really touch on pointers, and the fanciest thing we teach
> is recursion (which most don't get anyways).

If you don't know recursion, you don't know programming.  It is one of the
simpler concepts in computing.  (Much simpler than mutable variables, IMHO.)

> 	So if you look around at your fellow programming peers (perhaps the
> the entry level ones), what basic skills do you wish they were better prepared
> in?  Documenting?  Indentation? top-down problem solving? Debugging? Numeric
> methods?  Better understanding of hardware (cpu, terminal i/o)? Efficiency?
> Engineering skills ? (like kludging vs. recoding; writing code so that it
> can be maintained in the future; time management; reliability; human
> interfaces?)

Spelling.  Elementary English grammar and usage.  Proof-reading (being able
to look at what you _did_ write and notice when it isn't what you _meant_
to write).  Knowing how to look things up in manuals.

-- 
You can lie with statistics ... but not to a statistician.
From: cyberman@toz.buffalo.ny.us (Cyberman)
Newsgroups: comp.programming
Subject: Re: finding 1st one in in
Date: 14 Aug 92 00:41:43 GMT
X-Maildoor: WaflineMail 1.00r


     -=> John Henders spoke of "Re: finding 1st one in in" <=-
    To All at 08-12-92  01:50
 JH> 68k chips support a rotate right or left which would allow a rotate, 
 JH> followed by a test of the lsb.  Do any other chips have rotate? 
 JH> Of course, this wouldn't be portable, as it would have to be done in
 JH> assembly.

most platforms support bit rotateing left or right through the
carry thier are some that don't but these are VERY rare.
here are some processors I KNOW support this
8080 z80 80x86 680x0 I860 6800 6809 VAXPDP11

        Stephen Cyberman@Toz.Buffalo.NY.US
        Scripted at Thu  08-13-1992  16:26:41

... To every beginning there is an end
--- Blue Wave/QWK v2.10
                                                                            
Newsgroups: comp.programming
From: markh@csd4.csd.uwm.edu (Hunk)
Subject: Re: Teaching the basics
Organization: Computing Services Division, University of Wisconsin - Milwaukee
Date: Wed, 19 Aug 1992 15:48:30 GMT

In article <14066@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
>If you don't know recursion, you don't know programming.  It is one of the
>simpler concepts in computing.  (Much simpler than mutable variables, IMHO.)

I think recursion is a farce.  And just to rub it in, here's the Towers of
Hanoi (up to N = 31, I'm assuming long integers are 32 bits) without it (in C):

#include <stdio.h>

/* Move a stack of N objects from tower A to C, using B */
void Hanoi(int N, char A, char B, char C) {
   unsigned long X = 0; char D;
HANOI:
   if (N > 0) {
      D = B, B = C, C = D, N--;
      X = 2*X + 2; goto HANOI; X2: X = (X - 1)/2;
      N++, D = B, B = C, C = D;
      printf("Move %d from %c to %c.\n", N, A, C);
      D = A, A = B, B = D, N--;
      X = 2*X + 1; goto HANOI; X1: X = (X - 1)/2;
      N++, D = A, A = B, B = D;
   }
   if (X&1) goto X1;
   if (X > 0) goto X2;
}

main() { Hanoi(5, 'a', 'b', 'c'); }

or with the recursion scars removed, and algebraic cancellations carried out,
this:

#include <stdio.h>

/* Move a stack of N objects from tower A to C, using B */
void Hanoi(int N, char A, char B, char C) {
   unsigned long X = 0; char D;
   while (1) {
      if (N&1) D = B, B = C, C = D;
      for (; N > 0; N--) X = (X + 1) << 1;
      for (; X&1; X >>= 1, N++) D = A, A = B, B = D;
      if (X == 0) break;
      printf("Move %d from %c to %c.\n", N + 1, A, B);
      D = C, C = B, B = A, A = D, X--;
   }
}

main() { Hanoi(5, 'a', 'b', 'c'); }
From: sundar@fiber-one.ai.mit.edu (Sundar Narasimhan)
Newsgroups: comp.programming
Subject: Re: What would you like in a debugger?
Date: 12 Aug 92 17:59:28 GMT
Reply-To: sundar@ai.mit.edu
Organization: MIT Artificial Intelligence Laboratory

In article <12455@lupine.ncd.com>, jim@ncd.com (Jim Fulton) writes:
|> 
|> 	Bill writes:
|> 
|> 	Such a thing existed in X version 10; it was called Xnest.  I'm
|> 	surprised that it hasn't been reimplemented for X11 by now..
|> 
|> I forget the actual name of it, there was an "Xnone" that I think Matt Pappas
|> rigged up in the summer of '88 or '89 when he was a student working for us at the
|> X Consortium.  It had no input or output devices and just did all of the graphics
|> to a chunk of memory (GetImage was used to compare images).  
|> 
|> It was used for a little while, but folks generally found that it was easier to
|> just throw hardware at the problem.  With all of the different platforms we were
|> trying to support as well as samples from the X terminal companies, we each had
|> at least 2 displays.  This also helped when debugging applications that did
|> any sort of grab (e.g. window managers, xdm, etc.).

With X, there are 3 processes involved which is the main cause of the
problem.  The debugger, the application process and the X server (really 4 if
you include the window manager). There should be a way of preventing deadlock
which can arise in such situations transparent to the application process.
For example, if Motif or Xt decide to do a grab, then a debugger's PTRACE
messages could also be intercepted by them to release the grab. Another 
is for debuggers to talk to the X server or WM direct.  
Newsgroups: comp.programming
From: nickel@cs.tu-berlin.de (Juergen Nickelsen)
Subject: ANSI C, was Re: Teaching the basics
Reply-To: nickel@cs.tu-berlin.de
Organization: STONE Project, Technical University of Berlin, Germany
	<ratner.714247759@ficus.cs.ucla.edu> <13226@bnr-rsc.UUCP>
	<MHCOFFIN.92Aug20162507@tolstoy.uwaterloo.ca>
Date: Thu, 20 Aug 1992 23:07:25 GMT

In article <MHCOFFIN.92Aug20162507@tolstoy.uwaterloo.ca>
mhcoffin@tolstoy.uwaterloo.ca (Michael Coffin) writes:

> It is true that if you use a certain amount of discipline and make
> sure that the same prototype appears in both places---by putting it in
> an include file---the compiler will detect the error.  The problem is,
> there isn't any enforcement of this policy.

This is indeed a weakness of the standard, but at least gcc can be
told to issue a warning when a function call without a previous
prototype is encountered. From the manual:

    `-Wmissing-prototypes'
	 Warn if a global function is defined without a previous prototype
	 declaration.  This warning is issued even if the definition itself
	 provides a prototype.  The aim is to detect global functions that
	 fail to be declared in header files.

But using this is a major pain on a system without ANSI Header files.

--
Juergen Nickelsen
From: lavinus@csgrad.cs.vt.edu (Joseph Lavinus)
Newsgroups: comp.programming
Subject: Re: Any simple Random Number generators?
Date: 14 Aug 92 14:28:43 GMT
Organization: VPI&SU Computer Science Department, Blacksburg, VA

In article <1992Aug14.104121.29374@corax.udac.uu.se> pem@Minsk.DoCS.UU.SE (Per-Erik Martin) writes:
>In article <13AUG199218224504@judy.uh.edu> cscc13@judy.uh.edu (NAVEED IQBAL) writes:
>>I want to know how random numbers are generated.

>"Random number generators: Good ones are hard to find" by Stephen K. Park
>and Keith W. Miller in Communications of the ACM October 1988 (v31n10).
>This article also contains a proposed "minimal standard" generator which
>is simple but yet quite good.

The article "Random Numbers for Simulation" by Pierre L'Ecuyer, from the
October 1991 CACM (v33, page 85--97).  It contains some generators that
are allegedly better than the minimal standard, and is a good article in
general.

>>I want to get a "new" random number everytime I run the program.

>You simply "seed" the generator with the system clock when the program
>is started.

Alternatively, each time the program finishes, generate one more random
number and write it to a file.  Then, seed the generator with that number
next time you run.

Joe
-- 
______________________________________________________________________________
 Joseph W. Lavinus (2816), Virginia Tech             email: lavinus@cs.vt.edu
        "Few NP-hard problems remain difficult when restricted, say,
           to the class of 1-vertex graphs." --- David S. Johnson
Newsgroups: comp.programming
From: mhcoffin@tolstoy.uwaterloo.ca (Michael Coffin)
Subject: Re: Teaching the basics
Organization: Dept. of Computer Science, University of Waterloo
	<ratner.714247759@ficus.cs.ucla.edu> <13226@bnr-rsc.UUCP>
Date: Thu, 20 Aug 1992 21:25:07 GMT

In article <13226@bnr-rsc.UUCP> sdms@bnr.ca (Andrew Sterian) writes:
> Hmmmm...I disagree on this one. It may have been true some years ago that 
> the type checking etc. of Pascal made it easier on novice programmers but
> the latest ANSI C compilers do just as good a job of it as Pascal.

I've heard this said with quite a bit of frequency lately, but it
isn't true.  C compilers---even ANSI ones---don't do type
checking across separately compiled files.  If I put the function
prototype

        int f(double);

in one file and call f(3.14), the compiler is happy.  If I
then put the function

        int f(int, char *) {... }

in another file, the compiler won't complain about that either.
And I don't know of any C linkers that will complain.  If the
programmer is lucky, the program will dump core; if not, who knows
what may happen?

It is true that if you use a certain amount of discipline and make
sure that the same prototype appears in both places---by putting it in
an include file---the compiler will detect the error.  The problem is,
there isn't any enforcement of this policy.

-mike
From: lippin@lhasa.berkeley.edu (The Apathist)
Newsgroups: comp.programming
Subject: Re: Detecting Integer Overflow/Underflow
Date: 23 Aug 1992 03:50:30 GMT
Organization: Authorized Service, Incorporated
Reply-To: lippin@math.berkeley.edu
NNTP-Posting-Host: lhasa.berkeley.edu

Jim Hudgens <hudgens@SCRI.FSU.EDU> asks for a portable way to detect
integer over- and underflow.

Some replies have appeared that display clear knowledge of the two's
complement representation, and great prowess with bitwise operations.

However, for the sake of sanity -- both yours and that of those who
program around you -- I suggest using this algorithm:

	a+b will overflow when a > 0 and b > maxint-a,
	and will underflow when a < 0 and b < minint-a.

It would be a strange implementation indeed which did not satisfy
these rules.

					--Tom Lippincott
					  lippin@math.berkeley.edu

    "This view derives partly from what is known as common sense,
     whose virtue, uniquely among virtues, is that everyone has it."
					--Tom Stoppard, _Jumpers_
Newsgroups: comp.programming