HDTenEightyP/NetNews huggingface dataset:
From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Newsgroups: alt.folklore.computers
Subject: Re: Your co-worker may be an alien
Date: 17 Aug 92 06:16:59 GMT
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Distribution: na
Organization: Columbia University

In article <1992Aug17.043726.22001@msc.cornell.edu> maynard@esther.msc.cornell.edu (Maynard J. Handley) writes:
>
I guess you came to invade Earth, but you forgot your speech so you became
a driving instructor from France who consumes mass quantities of things and
toss sensor rings onto honed cones.

I remember the SCTV routine where people had cabbage leaves on the backs of 
their necks and were controlled by Zontar.

Wasn't there a movie about Zontar starring John Agar, the guy who was in all
those other SF movies like the Brain from Planet Arous, or the Mole People?

cjl
Newsgroups: alt.folklore.computers
From: wolff@zen.et.tudelft.nl (Rogier Wolff)
Subject: Re: CASIO watch display question
Organization: Delft University of Technology, Dept. of Electrical Engineering
Date: Mon, 17 Aug 1992 08:04:23 GMT

ivie@cc.usu.edu (CP/M lives!) writes:

>In article <1992Aug16.045515.21844@gossip.urich.edu>, helen@nomad.urich.edu (Helen C. O'Boyle) writes:
>> When my CASIO's have needed new batteries in the past, the LCD panel
>> has simply stopped displaying anything.  Is the above just another
>> symptom of a nearly-dead battery, or is it necessary to take the thing
>> in for service?

>Probably, especially since running the light probably takes more power than
>the rest of the watch put together. When you turned on the light, you probably
>lowered the power supply far enough to drive the machine crazy. Turning off
>the light upped the supply far enough to run the display again.

>Roger Ivie
>ivie@cc.usu.edu
Which means that a hard reset (pull the bateries out for about a second)
will fix the problem. (A watch uses about 0.5 uA, the light on the order of 
mA (I guess about 1 to 10.) The light could have a very big influence on
the battery power.....)

						Roger

-- 
If the opposite of "pro" is "con", what is the opposite of "progress"? 
(stolen from  kadokev@iitvax.iit.edu, who got it from brydon@asl.sinet.slb.com)
EMail:  wolff@duteca.et.tudelft.nl   ** Tel  +31-15-783644 or +31-15-142371
From: cblandy@ccwf.cc.utexas.edu (Chris Blandy)
Newsgroups: alt.folklore.computers
Subject: Re: You know you've been hacking too long...
Date: 15 Aug 92 19:54:02 GMT
Organization: The University of Texas at Austin

In article <BswnIE.Dpt@world.std.com> bmarcum@world.std.com (Bill Marcum) writes:
>Speaking of screen color, I've noticed somthing interesting on a computer
>where I work.  The screen display has alternating lines of red and light-blue
>text on a dark-blue background.  I wear very thick glasses, and as I move my
>head, the red letters seem to move around while the light blue letters stand
>still.
>
>Bill Marcum  bmarcum@world.std.com  b.marcum@genie.geis.com

There is another interesting phenomenon I have noticed with red color 
persistance.  Look at your favorite LED clock/watch/etc at night and move your
eyes slowly up-down/back-forth.  The numbers seem to actually move less than
the clock itself!

Chris Blandy
cblandy@ccwf.cc.utexas.edu

Newsgroups: alt.folklore.computers,comp.unix.misc
From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Subject: Re: The need for an assembler (was: Favorite CPU)
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University
Date: Sun, 16 Aug 1992 07:46:23 GMT

In article <id.NZDS.UCE@ferranti.com> peter@ferranti.com (peter da silva) writes:
>In article <1992Aug14.081326.24359@news.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>> This gets to the heart of the matter: hll programmers depend on the compiler
>> to do "magic" of various hues and colors for them; for most of them, they
>> haven't a clue as to what's going on,
>
>I take it you include Richard Stallman, Dennis Ritchie, Niclaus Wirth, and
>myself in this. We all, so far as I know, typically write in high level
>code by preference. Richard Stallman has written a rather good compiler,
>Dennis Ritchie invented C, and Niclaus Wirth invented Pascal. I've written
>in everything from raw bits to high-level dataflow languages, and implemented
>compilers, interpreters, and assemblers... as well as safety critical code
>with hard real;-time constraints in assembly and PL/M, and I always pick the
>highest level language that will get the job done. Declaring onself an
>"assembly programmer" and coding in assembly out of misplaced macho is
>simply limiting your options and wasting your time.

a)	Putting yourself into that category could be interpreted as misplaced
macho.  I can drop names as good as anyone.

b)	I said *most* users of hll.  If you put yourself in the category of
the people whose names you used, then you are proving my point:  There are
possibly as few as 5 people who actually have a clue as to what a compiler
is doing for them in any detailed way; for the rest, who are apparently a
huge ignorant horde that *you* want to distance yourself from, they likely
know little to none about what's going on under the hood.

cjl



Newsgroups: alt.folklore.computers
From: Josef Moellers <mollers.pad@sni.de>
Subject: Re: Hacker Test
Date: Thu, 13 Aug 1992 07:17:42 GMT
Organization: Siemens Nixdorf Info.Sys. AG, Paderborn, Germany

In <1992Aug11.053234.7874@nezsdc.icl.co.nz> derek@nezsdc.icl.co.nz (Derek Tearne) writes:

>In article <85477@netnews.upenn.edu> hedden@eniac.seas.upenn.edu (Jerry Hedden) writes:
>>
>>Would someone enlighten me on a couple of items from
>>"THE HACKER TEST - Version 1.0"
>>
>>   ....
>>   0475 Do you know Duff's device?
>>   0476 Do you know Jensen's device?
>>   ....
>>
>>I know what Duff's device is, but not Jensen's.

>I know what Jensens device is - I drive it to work every day...

Jensen's Device is based on ALGOL's "Call By Name": When You specified
a formal parameter to a procedure/function to be a "NAME" parameter, then
referring to it would cause a re-evaluation of the actual parameter,
e.g. (sorry for this incorrect ALGOL, it's been years ...):

INTEGER PROCEDURE JENSEN(NAME INTEGER I; NAME INTEGER J);
BEGIN
   INTEGER SUM;

   SUM := 0;
   FOR I := 1 STEP 1 UNTIL 10 DO
      SUM := SUM + J;

   JENSEN := SUM;

END JENSEN;

Now, this looks just like a function to multiply I by J, doesn't it? And
a very clumsy one too!

If, however, this function was called in a context like

INTEGER ARRAY A[1:10];
INTEGER S, X;

S := JENSEN(X, A[X])

Then every reference to I in JENSEN was an actual reference to X and
every reference to J was a (literal) reference to A[X] TAKING INTO
ACCOUNT THE CURENT VALUE OF X!
So, when I was 1, then J was A[1],
    when I was 2, then J was A[2],
    when I was 3, then J was A[3],
    when I was 4, then J was A[4],
    ...
    when I was 10, then J was A[10].

With this call, JENSEN would therefore sum up the elements of A!

And now, turn it around, what's DUFF's device?
-- 
| Josef Moellers		| c/o Siemens Nixdorf Informationssysteme AG  |
|  USA: mollers.pad@sni-usa.com	| Abt. STO-XS 113	   | Riemekestrasse   |
| !USA: mollers.pad@sni.de	| Phone: (+49) 5251 835124 | D-4790 Paderborn |
Newsgroups: alt.folklore.computers
From: peterk@public.sub.org (Peter Kittel)
Subject: Re: Bogosort
Organization: Public News & Mailserver, Commodore Germany PM UNIX, Frankfurt
Date: Wed, 12 Aug 92 15:19:58 GMT

john@mullet.gu.uwa.edu.au (John West) writes:

>I'm sure you all know the standard bogosort algorithm: randomly arrange the
>keys, then check to see if they're in order. But thats only O(n*n!) or so.
>
>That should be nice and slow. Can anyone come up with anything better? Perhaps
>we should have a competition.

If you search for a really slow algorithm, go and disassemble the ROM of
the Commodore Plus/4. It had some "database" software built in. When it
had to sort, it did it not in memory but on the floppy (you know, slooooow
1541). But anyway, the results were exceptionel: For 80 (yes, eighty)
data records it needed 4 hours with constant crunching of the poor
floppy device. With 90 records, we stopped this torture after 8 hours
and decided to put a notice on red paper in every box to avoid record
numbers beyond 80... (I still wonder how they achieved this marvel,
never had the time to look through the ROM.)

-- 
Best regards, Dr. Peter Kittel  // E-Mail to  \\  Only my personal opinions... 
Commodore Frankfurt, Germany  \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
                                   or  peterk@public.sub.org
Newsgroups: alt.folklore.computers
From: jimf@centerline.com (Jim Frost)
Subject: Re: 9600 baud ignorance??
Organization: CenterLine Software, Inc.
Date: Tue, 18 Aug 1992 15:20:50 GMT

pdt@mundil.cs.mu.OZ.AU (Peter David THOMPSON) writes:
>I have a proposal: Why not name modems by the most important descriptor of
>all: Transfer rate.

>Example : "My FrobCo modem transfers 8K per second using Zmodem from
>XYZsite."

What you're saying is exactly what they're providing -- bps *is* a
transfer rate, it just uses different units.  It tries to provide
information on optimal throughput, which is sane -- your "real world"
results will vary dramatically depending on how clean the phone line
is and how fast the machines on either end can handle the data.  There
are a lot of variables that are independent of the modem.

BTW I want the modem and computer pair that can get 8Kbytes/second
throughput.  Zoom zoom....

jim frost
jimf@centerline.com
Newsgroups: alt.folklore.computers
Subject: Re: What has AI done for me lately?
From: ecmtwhk@ccu1.aukuni.ac.nz (Thomas Koenig)
Date: Sat, 22 Aug 1992 03:58:15 GMT
Organization: University of Auckland, New Zealand.

Last year, at the Chemical Engineering World Congress, there were a few
reports about AI implementations. One of them was a presentation of a
system which was supposed to be of use in the selection and integration
of unit operations for chemical plants. As was to be expected, they had
not implemented it completely yet, but they predicted astonishing things
once it ran. Does that sound familiar at all?

One mistake these people made, IMHO, was that they tried to take the
descisions out of the engineers' hands. This will probably make sure
that it is never going to be used. While I am sure most engineers would
welcome a tool which showed them, for example, which unit operations
were suited for the particular circumstances, a system which shoves a
supposedly optimal solution at them and tells them to take it or leave
it is not going to be popular.

Another problem is the frightening complexity of that field. One guy I
met is currently doing research into an AI system for selection of heat
exchanger models and materials. The knowledge base would have to be
huge, constantly expanding because of technological change, and with
huge gaps where simply no data is available, all of which makes things
rather tricky for AI.
-- 
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.
Newsgroups: alt.folklore.computers
From: me@grmbl.saar.de (Martin Emmerich)
Subject: Re: Deutsches Museum (was: Zuse Computers
Reply-To: me@grmbl.saar.de
Organization: ME Inc.
Date: Fri, 21 Aug 1992 07:20:19 GMT

In <4058@cruzio.santa-cruz.ca.us> aki@cruzio.santa-cruz.ca.us writes:

>In article <1992Aug16.200705.58190@cc.usu.edu>, ivie@cc.usu.edu (CP/M lives!) writes:
>> It was kind of funny seeing people try to take flash pictures of the
>> planetarium screen...

>Will those tourists _EVER_ learn?

No. 

I once visited the Peter's Church in Rome, the biggest church in
Christianity. You can see the tourists standing there, trying to
lighten the really huge dome with the flash of their pocket cameras.

-- 
Martin  Emmerich   <--- this is a warlord-proof   <--- this is
me@grmbl.saar.de        signature                      not
Newsgroups: alt.folklore.computers
From: RFowler@kelvin.jpl.nasa.gov (Robert A. Fowler)
Subject: Re: Computers killing people?  (WAS Re: 9 track data storage???)
Organization: Jet Propulsion Laboratory
Date: Thu, 20 Aug 1992 00:45:26 GMT

In article <SEM.92Aug19100401@sunny.mitre.org> sem@mitre.org (Stan McQueen) writes:

>In article <1400@newsserver.cs.uwindsor.ca> oliver@cs.uwindsor.ca (Timothy Oliver) writes:
>> With a SERIAL port, maybe. But very unlikely. Few printers have the
>> transmit data line hooked up. 

What? Haven't you ever heard of x-on/x-off (or etx/ctx) protocols?  Almost 
all serial printers have RxD and TxD connected and used, becuase lots of 
devices (like modems and printservers and VT-100s) ignore hardware 
handshaking so the printer has to be able to say "stop sending" rather than 
assertin DTR=false.
    _________________________________________________________________
                        
                        HONDA -- The only way to fly
    o          
  _/\_>   -A proud owner (just wish they were made in the USA)
 O,> / O   [with all respects to Ohio MINE were made in Japan]
           
                           CM400T/XL500R/VF500F
                             '79   '82    '84
                           
     Slower trafic keep right (SUCKzukies, HDs, etc.) ->->->->->->->
    _________________________________________________________________
From: rice@enterprise.Berkeley.EDU (Daniel S. Rice)
Newsgroups: alt.folklore.computers
Subject: Re: Computer History/Biography/NonFiction Book List  (Version 1.0)
Date: 19 Aug 1992 22:04:13 GMT
Organization: University of California, Berkeley
NNTP-Posting-Host: enterprise.berkeley.edu
Keywords: books computers non-fiction


	To tie together several threads, the book:

A History of Computing in the Twentieth Century
Edited by N. Metropolis, J. Howlett, and Gian-Carlo Rota
659p
New York, Academic Press, c1980
0-12-491650-3

has some interesting essays on subjects including Zuse's machines, COLOSSUS,
ENIAC, early Soviet, European and Japanese computing, and early programming
languages, the latter in a paper co-authored by Knuth.  In typical Knuthian
style, he takes a small program and implements it in languages ranging
from Zuse's Plankalkuel to Fortran 56, in each case attempting to write in
the style of the times.

						Dan
Xref: sparky alt.folklore.computers:12519 comp.unix.misc:3221
From: bjj@ecl.psu.edu (Bryan J. Jensen)
Newsgroups: alt.folklore.computers,comp.unix.misc
Subject: Re: The need for an assembler (was: Favorite CPU)
Date: 13 Aug 92 15:42:11 EDT
Organization: Engineering Computer Lab, Pennsylvania State University

In article <1992Aug13.074807.24687@ccu1.aukuni.ac.nz>, ecmtwhk@ccu1.aukuni.ac.nz (Thomas Koenig) writes:
> bjj@ecl.psu.edu (Bryan J. Jensen) writes:
> 
> [among other things, a FORTRAN example where loop indices were used
>  as subroutine arguments, which led to bad optimizations]
> 
> If the compiler does indeed generate code like that for the code you
> showed, it does not optimize as well as it could.
> 
> The FORTRAN 77 standard states that it is illegal to modify the value
> of a DO loop iteration variable inside the loop. Any program which does
> so violates the standard, and the results are undefined or, in other words,
> random.

Then it becomes important to identify which compiler made this less
than optimal choice.  I'm using the VAX/VMS FORTRAN compiler.
A simple example follows:

    	real a(10,10)		! 0001
				! 0002
    	do 100 i=1,10		! 0003
    	do 100 j=1,10		! 0004
    	a(j,i)=func(i,j)	! 0005
  100	continue		! 0006
     				! 0007
    	call subr(a)		! 0008
    	end			! 0009

Generates the following code segment.  Note the multiply (MULL3)
and add which wouldn't be there were it not for the function call.

    0009	MOVL	#1, I(R11)
    000C  L$1:
							; 0004
    000C	MOVL	#1, J(R11)
    0010  L$2:
							; 0005
    0010	CALLG	$LOCAL+^X198(R11), FUNC
    0018	MULL3	#10, I(R11), R1
    001C	ADDL2	J(R11), R1
    0020	MOVL	R0, A-44(R11)[R1]
							; 0006
    0026	AOBLEQ	#10, J(R11), L$2
    002B	AOBLEQ	#10, I(R11), L$1
							; 0008
    002F	CALLG	$LOCAL+^X1A4(R11), SUBR
							; 0009
    0037	MOVL	#1, R0
    003A	RET	

Newsgroups: alt.folklore.computers
From: peterk@public.sub.org (Peter Kittel)
Subject: Re: Zuse Computers
Organization: Public News & Mailserver, Commodore Germany PM UNIX, Frankfurt
Date: Wed, 19 Aug 92 12:11:13 GMT

xexeo@dxlaa.cern.ch (Geraldo Xexeo) writes:

>Swiss German spoken TV (DSR) showed yesterday night a service about Konrad Zuse
>(or Conrad Zuze?) . 

Konrad Zuse is correct spelling. He was much ahead of his time. So much
that he also was not really considered valuable by militair in WWII.
Ok, he got some resources by them, but far too little to get it really
going.

>He was the pionner of computing in Germany. The Z1 was
>a MECHANIC computer, able to do simple calculations, while the last
>Z was a REAL COMPUTER.

Yes, the Z1 was purely mechanic and did NOT work when he did it, I think
already in the thirties. But the concept was ok, and as far as I heard
they now built one WORKING after the old plans, for his 80th birthday
I think. - The Z2 and Z3 (perhaps also Z4) were electromechanical in that
they used relays as active elements, and these machines really worked.
This must have been 1942 or 43. They were fully programmable and used
punched film tape as program input medium. By using more than one
reader for these and pasted loops, they already could do jumps and
branches and subroutines in these programs. Comparably much advanced
against ENIAC. - The later machines were all vacuum tube ones. The
last was the Z24, I think. In Braunschweig where I studied, they had
abandoned this Z24 only short time before I came there (1969). But I
myself used the Zuse Graphomat, a 1 m x 1 m plotter. It was really 
great and wonderful for scientific curve drawing.

For his very first machines, Zuse also invented a high-level programming
language, named Calculus, I think. But when memory serves me, this was
never really implemented.

>Zuse work was parallel to the one done in USA, independent creation and
>used much less money. The program showed some machines and a copy
>of Z1, that was made and installed in a Museum in Germany.

No, that must be a Z2 or Z3. One of these (don't know it precisely) is
shown fully functional in the Deutsches Museum in Munich. There they also
have one of the later models with vacuum tubes.

>He is now retired, 82 year old and painting nice pictures.

>Zuse company was bought by Siemens Nixdorf

Well, when my memory seves me, it was bought by AEG Telefunken. How it
should have come to Siemens Nixdorf, don't know, but I wouldn't deny it,
it is possible.

>Any of you  used or know were Zuse computers can be seen?

Yes, go to Munich in the Deutsches Museum. Their relatively new computer
department is very nice, they even have a Commodore PET there! (Though
no original one, but a hacked-up 3032.)

-- 
Best regards, Dr. Peter Kittel  // E-Mail to  \\  Only my personal opinions... 
Commodore Frankfurt, Germany  \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
                                   or  peterk@public.sub.org
Newsgroups: alt.folklore.computers,comp.unix.misc
From: Josef Moellers <mollers.pad@sni.de>
Subject: Re: The need for an assembler (was: Favorite CPU)
Date: Thu, 13 Aug 1992 06:59:23 GMT
Organization: Siemens Nixdorf Info.Sys. AG, Paderborn, Germany

In <1362@eouk18.eoe.co.uk> ahaley@eoe.co.uk (Andrew Haley) writes:

>ketil@edb.tih.no (Ketil Albertsen,TIH) writes:

>[ quotes are extracts, hopefully not out of context, from a long article ]

>: This is definitely far from reality! I think it is a safe bet than in any 
>: reasonable amount of code, the difference between c and asm, the best you 
>: can hope for is a doubling of speed. If you want to speed the total system 
>: by 10% - anything less isn't worthwile - you must find a section consuming 
>: at least 20% of the time. In most modern systems, that will be a significant 
>: chunk of code! (Although not 20% of the code lines, hopefully.) 

>I think that this is more true for modern RISCs than for other
>processors.  Computer designers have removed a lot of instructions
>from CPUs because high level language compilers never generated them,
>and therefore they were very rarely used.  If your computer has a very
>small, simple, regular instruction set it's that much more likely that
>a compiler will do a good job with it.

You're reference to RISCs gives me the opportunity to join the club B-{)

At least with the MIPS series, it's a moderate pain in the *** to
program in assembly language. There are so many things You must
consider: delay slots of branch instructions, load delays on ... well,
load instructions and so forth.

It is very much easier to have a mechanism to take care of all this: a
compiler.

Of course, one can expect that the assembler should be able to assist
You, and that's what a MIPS assembler does, but then You won't recognize
Your code when You look at it during debugging sessions (not only
debugging _Your code_, but also other people's hardware). So I try to
avoid programming in MIPS assembly as much as possible.

Programming on Intel or Motorola or NatSemi CPUs is completely
different, though.

-- 
| Josef Moellers		| c/o Siemens Nixdorf Informationssysteme AG  |
|  USA: mollers.pad@sni-usa.com	| Abt. STO-XS 113	   | Riemekestrasse   |
| !USA: mollers.pad@sni.de	| Phone: (+49) 5251 835124 | D-4790 Paderborn |
Newsgroups: alt.folklore.computers,alt.religion.computers
From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Subject: Re: Good source code to read?
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University
Date: Fri, 14 Aug 1992 09:18:54 GMT

In article <jimf.713735176@centerline.com> jimf@centerline.com (Jim Frost) writes:
>
>Damn, you mean that the compiler might actually have to have knowledge
>of range limitations when picking algorithms?  Wow.  I guess all this
>time my compiler has always treated different variable ranges like
>those implied by byte, signed/unsigned char, signed/unsigned short,
>signed/unsigned int, signed/unsigned long, float, double, etc or
>subranges like 0..10 *exactly the same*.  The compiler people must
>have totally missed that somewhere along the line.(*)
>
>(*) If you didn't read this paragraph sarcastically, read it again.

Sarcasm aside, you missed the point of this particular exercise.  There
exists an optimal algorithm that only applies to a limited subset of the
possible values the variables applied to said algorithm could take on.  If
you don't tell the compiler ahead of time what to expect, it has no business
using the algorithm.  It has nothing to do with what data type you specify,
rather each data type will only partially function assuming the same precise
algorithm is used.  In theory, if the arguments are constants known at
compile time, then the compiler can be made smart enough to use the limited-
range algorithm because it can pre-check that it's the right thing to use
for optimizing this subset of what's possible, but if it has no knowledge
of what the data values may take on, it can't use the code because you
can't tell it what it needs to know.  Therefore, you can tinker with
the compiler to make it so stupid that your code crashes should the
data values exceed the algorithms limitations, or you can use more robust
albeit more inefficent code, but you can't have it both ways.  If you
abstract your point of view, you abdicate the optimal case for the majority
of cases where it actually would work to avoid the few where it won't.  The
method works in 2^N-1 cases which is half of the 2^N cases possible for a
word size of N.  Someone pointed out that an existent compiler used a trick
where longword arithmetic was generated using the optimal algorith as a trick
to avoid the problem, but that presupposes that longword arithmetic is
acceptable (it might not be, and has its own overhead), and still doesn't
match the assembler code which is used when the *programmer* knows that the
cases that blow away the code won't come up.  (note that the longword form
still blows up for half of the longword cases, just that there are 2^N times
as many cases to consider.  Half of them still crash and burn.)

cjl

Newsgroups: alt.folklore.computers