HDTenEightyP/NetNews huggingface dataset:
From: robert@metropolis.com (Robert Munyer)
Subject: Re: Teaching the basics
Organization: Metropolis Software, Inc.
Date: Tue, 18 Aug 1992 10:36:25 GMT

In article <1992Aug17.123916.14815@husc13.harvard.edu>
peregrin@husc13.harvard.edu writes:

> [...] Basically, I'm giving you all the oportunity to tell a programming
> teacher what to better prepare students with.

Yo, James!

I'd say the most important skill that is lacked (!) by a whole lot of
programmers, not necessarily only entry-level ones, is TESTING.  They should
know how to be sure that their code will "do the right thing" for any
possible combination of inputs.  Reading in a resource from disk?  Don't just
assume blindly that there will be enough memory for it.  Check and make sure!

There is way too much software in the world that will crash your machine
depending on whether it is Tuesday and what phase the moon is in.

______________________________________________________________________
Robert Munyer            |   "I may be synthetic, but I'm not stupid."
robert@metropolis.com    |      -- Bishop, _Aliens_

P.S.  I know that C is fashionable, but it's really not a very good language
for teaching complete beginners.  C has a lot of "traps and pitfalls" for the
unwary.  When you're not even ready to learn about pointers, C is not much
more than a twisted version of Pascal.  What good is C without pointers?

They'd be better off starting with Pascal (or Modula-2 or -3), and switching
to C only after they've learned how to use pointers in Pascal.  Of course,
often there are political considerations, and there's not much you can do.

Newsgroups: comp.programming
From: crawford@church.mitre.org (Randy Crawford)
Subject: Re: Teaching the basics
Organization: The MITRE Corporation, McLean, VA
Date: Tue, 18 Aug 1992 01:42:03 GMT

In article <1992Aug17.123916.14815@husc13.harvard.edu> peregrin@husc13.harvard.edu writes:
...
>	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?)

IMHO, the most important characteristics of any program, in order:

1) It is correct; it does what it professes to do.
2) It is portable; it is written to the language and not to the machine.
3) It is efficient; it executes in a acceptable amount of time and space.
4) It is maintainable; it is well documented and well organized.  Others
   can discern what you have done in a short time and without your help.
5) It is fault tolerant; it responds gracefully to unexpected input.
6) It is user-friendly; users learn to use it with a minimum of training.

In general, I would emphasize this priority.  At times, efficiency or 
fault tolerance may rise in importance.  But always, correctness is
_paramount_.

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: crawford@church.mitre.org (Randy Crawford)
Subject: Re: ANSI C, was Re: Teaching the basics
Organization: The MITRE Corporation, McLean, VA
Date: Sat, 22 Aug 1992 03:42:14 GMT

In article <1992Aug21.232022.28931@prl.dec.com> boyd@prl.dec.com (Boyd Roberts) writes:
>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.

Then you're going to be stuck with zero type checking in your compiler.  Since 
the compiler cannot know what types the arguments are to its functions, it will 
be unable to do the automatic type conversions that ANSI C does.  As in K&R C,
the compiler will promote types to the largest integral type it has, and pass
all user defined types by address (because it doesn't know how large it is).  
This is wasteful and sometimes bug inducing.  You'll have to remember that the 
automatic type conversion is always going on, and may introduce some precision 
loss due to the float -> double -> float operations.

>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 same is true in DOS.

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.
-- 

| Randy Crawford        crawford@mitre.org        The MITRE Corporation
|                                                 7925 Colshire Dr., MS Z421
| N=1 -> P=NP           703 883-7940              McLean, VA  22102
From: enag@ifi.uio.no (Erik Naggum)
Newsgroups: comp.programming
Subject: Re: Teaching the basics
Date: 19 Aug 92 17:17:42 GMT
Organization: Department of Informatics, University of Oslo, Norway

Randy Crawford <crawford@church.mitre.org> writes:
|
|   IMHO, the most important characteristics of any program, in order:
|
|   1) It is correct; it does what it professes to do.
|   2) It is portable; it is written to the language and not to the machine.
|   3) It is efficient; it executes in a acceptable amount of time and space.
|   4) It is maintainable; it is well documented and well organized.  Others
|      can discern what you have done in a short time and without your help.
|   5) It is fault tolerant; it responds gracefully to unexpected input.
|   6) It is user-friendly; users learn to use it with a minimum of training.

I second this list, but wish to emphasize the "minimum" in point 6.  Too
many people think that "minimum" is a small amount, which it isn't.
Sometimes, it can be months of training, and still be "minimum" in order
to get full use of the software.

Hmm, maybe I'd rotate the list down from points 2 through 5, since I
consider fault tolerance as part of being correct.

Best regards,
</Erik>
--
Erik Naggum             |  ISO  8879 SGML     |      +47 295 0313
                        |  ISO 10744 HyTime   |
<erik@naggum.no>        |  ISO 10646 UCS      |      Memento, terrigena.
<enag@ifi.uio.no>       |  ISO  9899 C        |      Memento, vita brevis.
Newsgroups: comp.programming
From: agc@bmdhh298.bnr.ca (Alan Carter)
Subject: Re: Teaching the basics
Organization: BNR-Europe-Limited, Maidenhead, England
Date: Tue, 18 Aug 1992 08:18:25 GMT

In article <1992Aug17.123916.14815@husc13.harvard.edu>, peregrin@husc13.harvard.edu writes:
|> 
|> 	Basically, I'm giving you all the oportunity to tell a programming
|> teacher what to better prepare students with.
|> 
|> Thanks,
|> James

Teach them that it is OK not to know the *right* way to do something straight 
off. That sometimes *days* of contemplation are needed before a real 
understanding of a problem is reached. Show them that if they find 
themselves layering shovelfuls of meandering source riddled with special cases
and mutually cancelling areas of complexity then there is almost certainly
a better way to do things. Don't let them value listings by the yard.

   Alan

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   Maidenhead itself is too snobby to be pleasant. It is the haunt of the
   river swell and his overdressed female companion. It is the town of showy
   hotels, patronized chiefly by dudes and ballet girls. 

   Three Men In A Boat, Jerome K. Jerome, 1889
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Newsgroups: comp.programming
From: andyc@eliot.uucp (Andy Panda Collins)
Subject: Re: Any simple Random Number generators?
Keywords: random bit stream
Organization: Systems Center, Inc., Reston, VA, USA
Distribution: na
Date: Tue, 18 Aug 1992 18:39:49 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.

This ^^ method sure is simple. Here is an alternate method for generating
random bits, may I repeat, RANDOM BIT STREAMS. The word that is used can't
be considered random by any definition, really. Anyway here's the method

This method is best suited for electronics buffs, but is applicable to 
computers as well.

Take a n-bit shift register and a couple of XOR gates and put together
a circuit like the following.

     +---+---+---+---+---+---     ---+---+---+---+---+---+
     |   |   |   |   |   |    ...    |   |   |   |   |   |
 <---- 1 | 0 | 1 | 0 | 1 |    ...    | 0 | 1 | 0 | 0 | 1 ---+
     +-|-+---+---+---+-|-+---     ---+---+---+---+---+---+  |
       |               |               __                   |
       |               +-------------\\  \                  |
       |                              ||  >-----------------+
       +-----------------------------//__/

As the shift register shifts the XOR gate will take inputs from the
shift register and put its output as the registers input.

This method is now clearly better suited for hardware applications,
but can be implemented in software.

For rmore information about this and the theory of its operation
look into some discrete math books or even Numerical Recipes books,
that's were I remember seeing this in the first place.

Andy Collins

andyc!eliot!uunet
Newsgroups: comp.programming,comp.lang.c,comp.sys.intel,comp.sys.ibm.pc.misc
From: pdh@netcom.com (Phil Howard )
Subject: Using lookup tables for faster Life Game programming
Date: Thu, 20 Aug 92 02:54:34 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 

If you are interested in the article, read it in comp.theory.cell-automata.
Lookup tables, C code, and 8086 real mode segmentation is involved.
-- 
/***********************************************************************\
| Phil Howard  ---  KA9WGN  ---  pdh@netcom.com   |   "The problem with |
| depending on government is that you cannot depend on it" - Tony Brown |
\***********************************************************************/
Newsgroups: comp.programming
From: keelings@wl.aecl.ca
Subject: Teaching by Value
Organization: AECL RESEARCH
Date: Thu, 20 Aug 1992 22:31:12 GMT

  Date sent:  20-AUG-1992 16:15:21 
In a previous article, peregrin@husc13.harvard.edu wrote:
>	70% - meets specs
>	30% - robust (can't be crashed)
> 
>	-20% per day past due date
> 
>	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?

	At this level, I would prefer that MOST of the emphasis was
placed on analysis of the problem ( meets specs? ). So many people seem
unable to solve for the "general case"; their solutions are robust for
the present but crash as soon as the situation changes only slightly.

	As well, I would point out that speed and efficiency will be
picked up through practice. It's irrational to expect these from the
"newbies".

>	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?

	Absolutely!

>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?

	Right again. However, I don't think it's quite so easy to break
things down into these black and white categories. We all have our 
strengths, and weaknesses.


 _keelings@wl.aecl.ca wp33::keelings____AECL Research - Whiteshell Labs_
 __programmer/analyst, DTD/ESAB/SDS______Pinawa, MB., Canada   R0E 1L0__
From: dbsuthe@pbhya.PacBell.COM (Daniel B. Suthers)
Newsgroups: comp.programming
Subject: Re: Any simple Random Number generators?
Keywords: random, shift
Date: 20 Aug 92 16:43:14 GMT
Reply-To: dbsuthe@PacBell.COM (Daniel B. Suthers)
Organization: Pacific * Bell, San Ramon, CA

In article <1992Aug20.143244.6305@watson.ibm.com> curt@watson.ibm.com (Curt McDowell) writes:
>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
>> -- 
>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)).

Hold on Guys, Aren't we supposed to be language independent?  I can imagine
that Bill could be using C or GFA basic. His real message is that most
languages have a built in mechanism.

Dan Suthers
From: peregrin@husc13.harvard.edu
Newsgroups: comp.programming
Subject: Teaching by Value (was Re: Teaching the Basics)
Date: 19 Aug 92 18:25:13 GMT
Article-I.D.: husc13.1992Aug19.142513.14893
Organization: Harvard Business School

Okay, to continue with this thread I started ...

	We currently grade our introductory programming course thusly:

		60% - getting the answer right
		20% - style (documentation, indentation, etc.)
		20% - design (input checking, efficiency, etc.)

	The reason for the 60% chunk is that it is easier to give partial
credit for incomplete programs.

	But should we stress the grading differently?  In the real world,
is the value of a program more like:

		40% - Meets specs.
		40% - Robust (doesn't crash or crashes cleanly)
		20% - Maintainability

	or maybe like this:

		5% - Maintainability
		70%- Meets specs
		25%- Robust

especially since in today's market, you have to get the damn program out
the door as quick as you can.  Maintainability considerations are rarely
thought about except for the individual programmer's concern that he/she
can debug their own code?  Does anyone slow down to make their code
more maintainable?

	If we wanted to teach programmers what it is really like in the
real world, should we way things like this:


	70% - meets specs
	30% - robust (can't be crashed)

	-20% per day past due date


	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?

-James
+----------------------------------------------------------------------------+
| James Peregrino                        |       peregrin@hbsstg.harvard.edu |
| Programmer/Analyst                     |       PEREGRIN@HULAW1.BITNET      | 
| Science & Technology Interest Group    +-----------------------------------+
| Harvard Business School                | "Renovations Underway,            |
| Boston, MA 02163                       |  Thank You for Your Patience.     |
| Voice:(617)495-6307 FAX:(617)495-0351  |  Will Reopen Soon."               |
+----------------------------------------------------------------------------+
Newsgroups: comp.programming
From: dbsjwb@Edm.Arco.COM 
Subject: Re: New application methodology
Originator: dbsjwb@doofus
Reply-To: bielak@arco.com
Organization: ARCO Exploration and Production Technology
Date: Fri, 14 Aug 1992 12:36:03 GMT


I've been pointed to comp.software-eng .... thanks!

jwb
-- 
bielak@Arco.COM             ARCO Exploration and Production Technology
james.bielak@Edm.Arco.COM   2300 W. Plano Parkway PRC-D1139A
(214) 754-6184              Plano, TX 75075

Newsgroups: comp.programming
From: johng@lucid.com (John Gregory)
Subject: Re: Teaching the basics
Reply-To: johng@lucid.com (John Gregory)
Organization: Lucid, Inc.
Date: Tue, 18 Aug 92 23:04:26 GMT


|> In article <1992Aug17.123916.14815@husc13.harvard.edu>
|> peregrin@husc13.harvard.edu writes:
|> 
|> > [...] Basically, I'm giving you all the oportunity to tell a programming
|> > teacher what to better prepare students with.
|> 

Have them work on a *group* project and force them to deal with integration
issues.  Not many people hack alone in the real world, and the one's who
do are often painfully unaware of the problems of integration (no flames 
please).
Newsgroups: comp.programming
Subject: Re: To branch or not to branch
From: ecmtwhk@ccu1.aukuni.ac.nz (Thomas Koenig)
Date: Sun, 16 Aug 1992 02:41:53 GMT
Organization: University of Auckland, New Zealand.

jtien@seal.eng.uci.edu (Joe Tien) writes:

[about a FP package for the SPARC using only integer arithmetic]

>What I'm trying to find out is: what are the pros and cons to using more
>branches as opposed to repeating the code several times. That is:

[diagram deleted]

>I know that (1) will have smaller code size, but (2) is faster in execution.
>But are there any other factors involved? How is it done in the real world? 

In a cache architecture, there is a fair chance of losing whatever gain
you have in speed to more cache misses, either at the time or later. If
you are really unlucky, you might even get an additional page fault,
which takes forever, in comparison. Unless your speed advantage is
quite large, go for the small code.

Also, if you repeat code several times, your program will be more
difficult to read and to maintain, especially if you hand - tweak
compiler - produced code, which does not use macros.

One thing which might have a large enough speed advantage, however, is
loop unrolling, which few C compilers do yet. Instead of writing

for (i=0; i<N; i++) { do_something_with_i; } 

you might write, for example

for (i=0; i<N/2; i++) { do_something_with_i+i; do_something_with_i+i+1; } 
if (odd(N)) {do_something_with_N-1; }

A final thing - you did not ask, but there is at least one hand-written
assembler floating point library out there, for the 68000, which is
relatively easy to read, as assemblers go. It is part of the gcc
distribution for the Atari ST, and can be found on atari.archive.umich.edu.
-- 
Thomas Koenig, ecmtwhk@ccu1.aukuni.ac.nz, ib09@rz.uni-karlsruhe.de
The joy of engineering is to find a straight line on a double logarithmic
diagram.
Xref: sparky comp.programming:2354 comp.realtime:963
From: rmal@jet.uk (Richard Lucock)
Newsgroups: comp.programming,comp.realtime
Subject: Fitting a gaussian curve to data
Keywords: fit,gaussian,normal
Date: 17 Aug 92 10:08:36 GMT
Organization: Joint European Torus

Hi,
	I am looking for a routine (code or algorithm) to fit a
gausian curve to data. I can do this easily using a least squares
minimisation routine (from the Nag library in fact), but it is too
slow (this is for a realtime application, hence the crossposting), so
I am trying to find something faster.

Many thanks,
	Richard (rmal@jet.uk)
- Disclaimer: Please note that the above is a personal view and should not 
  be construed as an official comment from the JET project.
From: lippin@jaffna.berkeley.edu (The Apathist)
Newsgroups: comp.programming
Subject: Re: When should a debugger be used?
Date: 15 Aug 1992 22:15:49 GMT
Organization: Authorized Service, Incorporated
Reply-To: lippin@math.berkeley.edu
NNTP-Posting-Host: jaffna.berkeley.edu

From the tinkling keys of atbowler@thinkage.on.ca (Alan Bowler):

>What features are in your debuggers that allow you to tract memory
>leaks?  

Macintosh debuggers are generally more aware of the heap structure
than debuggers I've seen on other platforms.  This may be because the
heap structure is documented and easy to look at, or it may be because
the OS makes heap-related bugs so common.

I'll describe MacsBug here, which is the debugger I generally use for
memory problems.

For finding memory leaks, two tools are particularly useful.  One is
the "heap total" command, which lists (among other statistics) the
number and total size of allocated heap blocks.  This is good for
spotting leaks: run through a part of the program a few times, and see
if the numbers grow in ways you don't expect.

For fixing the leaks, I use an add-on tool called "leaks" (whose
author I should credit, but I don't have the name handy).  When turned
on, it records block allocations and disposals.  It records the call
chain of the allocations, and groups those with similar call chains
and sizes.  The effect is wonderful -- I run the program for a while,
and it points out the code that allocates leaky blocks.

For other heap related problems there are features worth pointing out:

It can run a consistency check on the heap structure.  This will
often catch writes to locations just outside a block.

It will (with some difficulty) tell you the stats of a block you're
interested in.  This is particularly useful when you think you may be
referencing a freed block.

It can be set to break on or record particular system calls (with a
few limitations).  It's a good way to find the spot where you're
enlarging that memory block, among other problems.

It can use the processor's trace mode to break on a change to a
particular memory location.  This helps find writes through wild
pointers.  On a 68040, the processor caches will allow this to run at
a respectable speed.

The program being run can issue debugging commands.  This helps one
get a handle on some of the more twisted bugs, particularly those that
only happen in real time.

					--Tom Lippincott
					  lippin@math.berkeley.edu

	     "Come see the violence inherent in the system!"
				--Dennis, "Monty Python and the Holy Grail"
From: pem@Minsk.DoCS.UU.SE (Per-Erik Martin)
Newsgroups: comp.programming
Subject: Re: Any simple Random Number generators?
Date: 14 Aug 92 10:41:21 GMT
Organization: Student

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

>I want to know how random numbers are generated.

If you are talking about "pseudo random numbers" (which is the common
case in programming) you may want to read Donald E. Knuth's "The art
of computer programming, vol 2", and definitely the article
"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.

>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.

>I did download a program to do that from wuarchive but I was wondering
>if there was a simpler way.

If you're running Unix and C you (usually) have random(3) (good enough)
and drand48(3) (better but slower), and rand(3) *if* it's an ANSI-C
library. (Beware of the old Unix rand()!)

--
 |\/|\/|\/| Per-Erik Martin,
 |  |  |/\| Department of Computer Systems, Uppsala University,
 |/\|  |  | Email: pem@minsk.DoCS.UU.SE
Newsgroups: comp.programming