HDTenEightyP/NetNews huggingface dataset:
From: amodra@ucs.adelaide.edu.au (Alan Modra)
Newsgroups: comp.programming,comp.realtime
Subject: Re: Fitting a gaussian curve to data
Date: 19 Aug 92 02:44:38 GMT
Followup-To: comp.programming
Organization: Information Technology Division, The University of Adelaide, AUSTRALIA

From article <1992Aug17.100836.15450@jet.uk>, by rmal@jet.uk (Richard Lucock):
> 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.

Use   mean = (x1 + x2 + .. + xn) / n
      var = (x1*x1 + x2*x2 + .. + xn*xn - n*mean*mean) / (n-1)
Newsgroups: comp.programming
From: reuter@venice.sedd.trw.com (Joseph Reuter)
Subject: Re: finding 1st one in integer
Organization: TRW Systems Engineering & Development Division, Carson, CA
Date: Fri, 14 Aug 1992 15:36:12 GMT

In article <Bsx578.CzD@metropolis.com> robert@metropolis.com (Robert Munyer) writes:
>But the point of this discussion is that we're looking for ways to find the
>most significant "one" bit (i.e., count the number of leading 0's) WITHOUT
>having to go through a loop 31 times.
>

On the CDC6600, this was accomplished using the floating-point unit, provided
the number in question was less than 2**48.  The number was converted to
unnormalized floating-point by ORing it with 0x200000000000000 and then
normalizing.  The normalize instruction returned the number of left shifts
required, but the count could also be obtained by examining the exponent
part of the normalized floating-point number.

I don't know enough about the IEEE floating-point system to know if a
similar trick would work there.  If it does, this technique, while not 
perfectly portable, might be widely applicable.

-- 
Joseph A. Reuter, Wizard-in-Training
Speaking for myself from reuter@venice.sedd.trw.com
"Olorin I was in the West that is forgotten." -- J.R.R. Tolkien
"You can't win, you can't break even, and you can't quit the game."
Newsgroups: comp.programming
From: morris@samson.bnr.ca (Morris Bernstein)
Subject: Re: When should a debugger be used?
Organization: Bell Northern Research Montreal, Canada.
Date: Thu, 13 Aug 92 14:21:40 GMT

In article <1992Aug12.233904.11067@thinkage.on.ca> atbowler@thinkage.on.ca (Alan Bowler) writes:
>
>However, I am intrigued by the following statement.
>
>In article <164c9vINNijk@agate.berkeley.edu> lippin@math.berkeley.edu writes:
>>
>>Some bugs (e.g., memory leaks) are very nearly intractable without
>>debugging tools, simply because they show few visible symptoms in
>>ordinary test conditions.
>>
>
>Memory leaks are one of the areas where I have found debuggers to be
>very little use.  I do use it to examine the free memory list, and say
>to myself "this look suspiciously large", but that just tells me there
>MIGHT be a leak.  Finding the actual is has always been more of
>an analysis problem.
>
>What features are in your debuggers that allow you to tract memory
>leaks?  


This topic was discussed a couple of months ago, when someone asked
how to find a memory leak.  I and several others gave explanations of
varying degrees of clarity.

In short, a memory leak can be found using a debugger and auxilliary
tools.  You modify your call to [m]alloc/free to report when memory
operations are performed.  You run a (eg awk) script on the output to
match alloc with free.  You then have a list of memory allocations
that are not freed during your program.

You take the list and program your debugger to stop on the nth
occurrence of malloc (there are several ways to do this) where the nth
allocation is not freed.  You then know the context in which the
object is being allocated.  You can usually figure out where it should
be freed.


Morris
--
Morris Bernstein		 phone:	(514) 765-8275
Bell Northern Research Ltd. 	 fax:	(514) 765-0500
worldnet: bnrmtl!morris@larry.mcrcim.mcgill.edu
"Knowlege is a mind-expanding drug."
From: shirley@fdr.jsc.nasa.gov (Bill Shirley [CSC])
Newsgroups: comp.programming
Subject: Re: Any simple Random Number generators?
Date: 18 Aug 92 19:34:39 GMT
Organization: Software Technology Branch - NASA/JSC
Originator: shirley@fdr


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

-- 
Bill Shirley		|  ``Computer Science is not about computers any 
shirley@fdr.jsc.nasa.gov|	more than astronomy is about telescopes.''
Newsgroups: comp.programming
From: dlb@fanny.wash.inmet.com (David Barton)
Subject: Re: what skills does a programmer need
Organization: Intermetrics Inc., Washington Division, USA
	<1992Aug17.155545.15339@uwm.edu>
Date: Thu, 20 Aug 1992 13:32:50 GMT

Dijkstra has stated that the first skill needed by any programmer is
the ability to write clearly and concisely in his native language.  I
would agree.

					Dave Barton
					dlb@hudson.wash.inmet.com
Newsgroups: comp.programming
From: mlbauman@rchland.vnet.ibm.com (Mark Bauman)
Subject: RE: TCP/IP Programming on AS/400 
Date: Mon, 17 Aug 1992 14:29:50 GMT
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
Organization: IBM Rochester

Jacques,

You can program to the TCP/IP Connectivity Utilities/400 from another high level language, however, you must use QPXXCALL for the inter-HLL calls AND you must provide a PASCAL ONERROR routine.   When using QPXXCALL you must ensure that you map to the data structures expected by the TCP/IP PASCAL routines.   And, unfortunately, you will still need to buy the PASCAL/400 compiler in order to define the PASCAL ONERROR routine.  You only need to buy one PASCAL/400 license though - for your development AS/400 - 


because the PASCAL execution time services (ETS) are provided as part of OS/400.
From: dave@cs.arizona.edu (Dave Schaumann)
Newsgroups: comp.programming
Subject: Re: Any simple Random Number generators?
Date: 14 Aug 92 02:39:21 GMT
Reply-To: dave@cs.arizona.edu (Dave Schaumann)
Organization: University of Arizona

In article <13AUG199218224504@judy.uh.edu>, cscc13@judy (NAVEED IQBAL) writes:
>I want to know how random numbers are generated.

Well, you could hook up an A/D converter to a Geiger counter.

You could also read chapter 3 of Don Knuth's _Art of Computer
Programming_.

-- 
--- jumbo shrimp --- pretty ugly --- awfully nice --- constant change ---
From: crawford@church.mitre.org (Randy Crawford)
Newsgroups: comp.programming
Subject: Re: Teaching the basics
Date: 22 Aug 92 03:17:17 GMT
Organization: The MITRE Corporation, McLean, VA

In article <1992Aug21.141617.22808@nstn.ns.ca> maceache@fox.nstn.ns.ca (Tim Maceachern) writes:
>I think some of the arguments in this thread would have to be modified
>if c++ were used for the beginning language with a suitable class 
>library for beginners -- for instance the var class recently posted.  In
>particular, would it be possible to teach a c++ course without pointers
>if everything is hidden in a supplied object?

Yes, as long as you were satisfied with some inability to construct your own
classes, or extend existing ones.  This isn't really a problem if you expect
the students to use the OOPL to program in a somewhat non-OO manner -- to 
use the data types which the language (and the instructor) give you and not 
be fully able to "roll your own".   However, to build the sophisticated ADTs 
in C++ (which are the hallmark of OOPLs) you need to be able to use dynamic 
memory -- and pointers.

It _is_ an interesting idea, to introduce students to C++ and OOP without using 
pointers.  They could get their feet wet in OO programming, overloading
functions, deriving classes, creating simple classes, and _using_ the more 
sophisticated data types like list classes, queue classes, tree classes, etc.  
Then after they have a sense of the power of OOP, teach them about the 
infrastructure in C++ that makes it all possible.  They could accomplish most 
of what they need from pointers simply by using references.

Not a bad idea.
-- 

| Randy Crawford        crawford@mitre.org        The MITRE Corporation
|                                                 7925 Colshire Dr., MS Z421
| N=1 -> P=NP           703 883-7940              McLean, VA  22102
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.programming
Subject: Re: Teaching the basics
Date: 21 Aug 92 08:39:26 GMT
Organization: Comp Sci, RMIT, Melbourne, Australia

In article <MHCOFFIN.92Aug20162507@tolstoy.uwaterloo.ca>, mhcoffin@tolstoy.uwaterloo.ca (Michael Coffin) writes:
> 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.

Pascal doesn't do type checking across separately compiled files either.
(I'm not talking about "PAscal Extended" here; I still haven't seen that.)
Suppose you want to write a program that calls procedure P, but you want
to put P in another file.  There is _no_ way to do that in standard Pascal.

There is nothing in the C standard that _forbids_ type checking across
separately compiled files, and there _are_ ANSI-compatible Lints.  We've
ordered one, but heaven only knows when we'll get it.  In the mean time,
-- 
You can lie with statistics ... but not to a statistician.
Newsgroups: comp.programming
From: dbsuthe@pbhya.PacBell.COM (Daniel B. Suthers)
Subject: Re: gem font spec?
Reply-To: dbsuthe@PacBell.COM (Daniel B. Suthers)
Organization: Pacific * Bell, San Ramon, CA
Distribution: comp
Date: Wed, 12 Aug 1992 22:36:56 GMT
Summary: DRI's GEM programmer reference manual has info.

In article <1992Aug10.2737.1250@dosgate> "gord armstrong" <gord.armstrong@canrem.com> writes:
>
>I'm writing a C/assembler program using bitmapped fonts for DOS and
>OS2. I would like to use GEM fonts.
>
>I need the details to the GEM font file format v2.0 or v3.0 (no
>v3.0 compression). This is what I've been able to figure out so
>far:
	[ TEXT DELETED ]

The information requested is in appendix G of the GEM programmer's 
reference manual.  My manual is dated 1985.  It does not mmatch the
information you listed.  I don't know if you are using a newer format.

DRI's address:  PO BOX 579, Pacific Grove, Ca, 93950, USA



Daniel B. Suthers,  CCP.
Technology Consultant, PCS & IN Development Lab,        Pac*Bell
Voice: (510) 671-1325               UUCP:  pacbell!pbeos!dbsuthe
================================================================================
=  Youth is a difficult time...  it gets tougher the longer you draw it out.  =
================================================================================
Newsgroups: comp.programming
From: nqueipo@euler.Berkeley.EDU (Nestor Queipo)
Subject: Distributed toolkit wanted!
Reply-To: nqueipo@euler.Berkeley.EDU (Nestor Queipo)
Organization: University of California, Berkeley
Date: Thu, 13 Aug 1992 17:46:27 GMT

Hello,  

I would like to hear your opinions about what is the "best" distributed
toolkit available for free/low cost in the Internet. Basically I am 
looking for a piece of software that would allow me to distribute an
application over a number of machines. It does not have to be fault-
tolerant.

I will post a summary of the responses,

Thank you so much in advance for your help,

Nestor  

Newsgroups: comp.programming
From: ratner@ficus.cs.ucla.edu (David Ratner)
Subject: Re: Teaching the basics
Organization: UCLA, Computer Science Department
Date: 19 Aug 92 18:09:19 GMT

anderson@Software.Mitel.COM (David Anderson) writes:

>In article <Bt6DGq.HuB@metropolis.com> robert@metropolis.com (Robert Munyer) writes:
>>Yo, James!
>>
>[ Excellent Testing remarks delete...]

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

>I currently teach C and have taught Pascal for the local college here and
>I tend to agree with Robert on the above comments.

>  o C is *not* a beginners  language.

[ comments deleted ]

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.

Just as a side-note, the more advanced classes used C, Lisp, and everything
else.

>Other general points in teaching any language:

>  o Style! Teach the student consistent coding practices. Readability counts
>    higher than fancy cryptic statements.
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.

[ other general points deleted ]
--
* *  ***  *     *    |   Dave "Van Damme" Ratner
* *  *    *    * *  / \  ratner@cs.ucla.edu
* *  *    *    ***  \ /  
***  ***  ***  * *   |   "Wham Bam, thank you Van Damme!"
From: dbsuthe@pbhya.PacBell.COM (Daniel B. Suthers)
Newsgroups: comp.programming
Subject: Re: When should a debugger be used?
Summary: When you have no obvious problems...
Date: 20 Aug 92 16:29:22 GMT
Reply-To: dbsuthe@PacBell.COM (Daniel B. Suthers)
Organization: Pacific * Bell, San Ramon, CA

In article <6453@fury.BOEING.COM> cek@sdc.boeing.com (Conrad Kimball) writes:
>|> >4.  Divide-and-conquer when things go wrong by adding some output somewhere
>|> >    (usually an fprintf() added at a strategic spot).
>
>And what do you do when the problem goes away when you add the fprintf()?
>I've had that happen.  A bad pointer leading to trashed memory, and
>inserting more code moves things around so the trashed memory no longer
>causes the program to fail...
>
>--
>Conrad Kimball		| Unix Server Tech Services, Boeing Computer Services


And you would be suprised how many programmers just leave the fprintf there
and assume the bug is fixed!!!

This seems to be one of the classic C bug symptoms, and (for me) it always 
turns out to be a pointer problem.  A real good debugger can help here, but so
can a deskcheck of your code.

To answer the question posed by the subject line:  IMHO a debugger is best used
after the logic has been checked.  The very first step is to make sure that
the bug can be reproduced consistantly.  Then and only then can you research
the cause of the bug with 100% assurance that your cure will be the cure.

Daniel B. Suthers,  CCP
Technology Consultant, PCS & IN Development Lab,        Pac*Bell
Voice: (510) 671-1325               UUCP:  pacbell!pbeos!dbsuthe
================================================================================
=  Commit unexpected kindnesses and senseless acts of beauty.                  =
================================================================================
From: Jonathan Egre' <jonathan@mantis.co.uk>
Newsgroups: comp.programming
Subject: Re: Teaching the basics
Date: Thu, 20 Aug 92 15:30:13 BST
Distribution: world
Organization: Mantis Consultants, Cambridge. UK.

anderson@Software.Mitel.COM (David Anderson) writes:

> Other general points in teaching any language:
> 
>   o Meaningful Identifiers. Please make sure the student is not using variabl
>     names like "a" when you really mean something like "tax_rate"!

This fault is largely the result of people not being able to type properly.
Therefore I suggest that the students be taught to type reasonably well
(seriously).

--
Jonathan Egre' = jonathan@mantis.co.uk = jonathan_e@cix.compulink.co.uk
Xref: sparky comp.programming:2285 comp.unix.programmer:4257 comp.lang.c:12230 comp.arch:8861
From: sundar@fiber-one.ai.mit.edu (Sundar Narasimhan)
Newsgroups: comp.programming,comp.unix.programmer,comp.lang.c,comp.arch
Subject: Re: What would you like in a debugger?
Date: 12 Aug 92 17:47:52 GMT
Reply-To: sundar@ai.mit.edu
Followup-To: comp.programming
Organization: MIT Artificial Intelligence Laboratory

In article <matt.713047463@centerline.com>, matt@centerline.com (Matt Landau) writes:
|> In <1992Aug5.193946.16004@linus.mitre.org> hargrove@ramirez.mitre.org (Paul H. Hargrove) writes:
|> >I want a debugger that works well with X11.  This means that if I'm
|> >tracing an X11 program and it has stopped at a breakpoint, and I
|> >happen to uncover the window, my X server doesn't just sit there 
|> >trying forever to tell the application to redraw it's window.
|> 
|> How, pray tell, do you expect your application to redraw its window if 
|> it's stopped at a breakpoint?  
|> 
|> The X server isn't "sit[ting] there trying forever to tell the application" 
|> to do anything at all.  The X server generates Expose events for your X11 
|> client application, then forgets about you until something else happens 
|> that you need to know about.  
|> 
|> The fact that your application doesn't read and process these Expose events 
|> when it's stopped at a breakpiont is really not something a debugger can 
|> do anything about.  This is kind of the definition of being "stopped at a 
|> breakpoint", is it not?
I agree with you on this, but the most painful thing about X/Motif 
are programs that involve widgets that do pointer and keyboard grabs.
I've had breakpoints in callback functions simply hang (freeze up the
server) because of the grab -- which I can't get out of because to do this
I would need to TYPE stuff at the debugger telling it to continue.

What is the right thing to do when this happens? (I have a solution 
but it is hardly pretty).
Newsgroups: comp.programming,comp.protocols.tcp-ip
From: nectar@world.std.com (Jacques A Vidrine)
Subject: TCP/IP programming on AS/400
Organization: The World Public Access UNIX, Brookline, MA
Date: Wed, 12 Aug 1992 19:08:20 GMT

My IBM Sales Rep tells me that the only language supported for programming
using TCP/IP Connectivity Utilities/400 is Pascal.  The TCP/IP Connectivity
Utilities/400 manuals seem to agree with this.

I would like to know if TCP/IP programming can be done with the C/400 compiler
before I am forced to buy the Pascal/400 compiler.  Seems to me that many
implementations of C support Pascal calling conventions.  Anyone have any
idea on this with regards to the AS/400?

Thanks in advance!
-- 
Jacques A. Vidrine 		|	What did the Zen Buddhist	
nectar@world.std.com		|	say to the hot dog vendor?
				|	"Make me one with everything."
Request my PGP public key	|
From: pgh@bnr.co.uk (Peter Hamer)
Newsgroups: comp.programming
Subject: Re: >How can I get more info on LALR ?
Date: 19 Aug 92 15:48:06 GMT
Reply-To: pgh@bnr.co.uk (Peter Hamer)
Organization: BNR Europe Limited, London Road, Harlow, Essex, GB

email bounced, so posting

In the referenced article hanso@research.ptt.nl (Otten H.A.H.) writes:
>
>The project I'm working on involves a translator from one high-level language
>to another. However, conflicts in one domain (the action part) have to be
>resolved in another (the type-declaration part), and I'm not sure if LALR can
>cope.

You may find the approach described in

Parse Tree Annotations
Purtilo & Callahan
Comms ACM
32(12)
dec 89
pp 1467-77

... of interest.

Regards, Peter
From: dave@cs.arizona.edu (Dave Schaumann)
Newsgroups: comp.programming
Subject: Re: Teaching the basics
Date: 21 Aug 92 02:39:19 GMT
Reply-To: dave@cs.arizona.edu (Dave Schaumann)
Organization: University of Arizona

In article <MHCOFFIN.92Aug20162507@tolstoy.uwaterloo.ca>, mhcoffin@tolstoy (Michael Coffin) writes:
>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.

Note that this is a problem only if you are careless enough not to
put the prototype for f() in a single .h file which is then included
in all your sources which call f().

>The problem is, there isn't any enforcement of this policy.

*sigh*.  What do you want a compiler to do -- generate an executable, or
be an AI conscience on how you should've written your code?  Sure, having
automated checks for consistency and reasonableness are worthwhile, but
there's a point where the programmer has to take responsibility for his
product.

Power requires responsibility; always has, always will.  If you can't
muster the discipline languages like C require of you, the B&D languages
are down two groups and to the left.  Tell 'em "Nick" sent you.

-- 
Dave Schaumann			dave@cs.arizona.edu
From: dbsuthe@pbhya.PacBell.COM (Daniel B. Suthers)
Newsgroups: comp.programming
Subject: Re: Teaching by Value (was Re: Teaching the Basics)
Date: 20 Aug 92 16:10:17 GMT
Reply-To: dbsuthe@PacBell.COM (Daniel B. Suthers)
Organization: Pacific * Bell, San Ramon, CA

In article <1992Aug19.142513.14893@husc13.harvard.edu> peregrin@husc13.harvard.edu writes:
>Okay, to continue with this thread I started ...
>	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

Maybe this is just a local phenomenom;  Programmers who learn to wtrite clean
and easy to read / maintain code have the time to learn to write tight,
fast and efficient routines.  I think that the increased ease of maintenance
is what enables the understanding needed to "soup up" the code.

Those who are taught to code tight and fast (first) don't seem have the 
luxury of enough time to retro fit their code for readability and 
maintainability.

I would rather work with others who value a clean, readable style.  You never
know when you will inherit a team mate's code.

Daniel B. Suthers,  CCP
Technology Consultant, PCS & IN Development Lab,        Pac*Bell
Voice: (510) 671-1325               UUCP:  pacbell!pbeos!dbsuthe
================================================================================
=  Commit unexpected kindnesses and senseless acts of beauty.                  =
================================================================================
Newsgroups: comp.programming