HDTenEightyP/NetNews huggingface dataset:
From: mjh22@cl.cam.ac.uk (M.J. Hardcastle)
Subject: Re: TIME HAS INERTIA (A1) EXPLAINS GRAVITATION
Reply-To: mjh22@phx.cam.ac.uk
Organization: Dept. of Physics, U of Cambridge, England
Date: Tue, 15 Dec 1992 02:13:22 GMT

In article <1992Dec10.044056.245@nuscc.nus.sg> matmcinn@nuscc.nus.sg (Brett McInnes) writes:
>abian@iastate.edu (Alexander Abian) writes:
>: Hardcastle: listen carefully, I shall say this only once.
>: 
>: you write:
>:  
>: >Physicists *do not have* to explain 'why' gravity works. Physics is about
>: >observing phenomena and inducing generalities from them:. 
>: 
>:  such as  THE SUN RISES BECAUSE THE ROOSTER CROWS !!
>:  
>I suppose it had to happen. Abian finds somebody whose understanding of
>what physics is about is as frantically conventional as his own is
>frantically ridiculous.

Well -- I'd rather have mine than his, to be honest. But then I'm only a
physicist with a strong interest in philosophy of science, so what do I know?

I see Abian is still raving. I second whoever it was who suggested the
creation of alt.bad.philosophy . His statement that "science and physics
are what I say they are" was one of the more amusing things I've seen on
the net for a while, but it reminded me of why I don't usually read
sci.physics...

May the farce be with you

Martin

Newsgroups: sci.physics
From: sarfatti@well.sf.ca.us (Jack Sarfatti)
Subject: PS on Budnik's "delay" in Bell's inequality test.
Organization: Whole Earth 'Lectronic Link
Date: Sat, 19 Dec 1992 03:28:39 GMT


I looked again trying to understand what is exciting Budnik so much. Does he
not know that Aspect's experiment in 1982 has polarization orientation
switching times that were short compared to photon flight times from source
to detectors. So that the nonlocal correlation of (cos@)^2/2 that violates
Bell's locality inequality is definitely observed across spacelike
intervals. If that is his concern then the answer is simple. But it seems to
be something else- he says the "delay" can be measured but he does not give
a clear and complete procedure so that I conclude it is much ado about
nothing. I would like to be proved wrong in this opinion if any one else
thinks they understand Budnik's idea.
Newsgroups: sci.physics
From: terry@aslws01.asl.dl.nec.com (Terry Bollinger)
Subject: Re: Passive Magnetic Levitation (was: Science Fair Project)
Organization: (Speaking only for myself)
Date: Wed, 16 Dec 1992 16:37:43 GMT

In article <1992Dec11.202853.8041@murdoch.acc.Virginia.EDU>
crb7q@kelvin.seas.Virginia.EDU (Cameron Randale Bass) writes:

> My guess is that torsional perturbations do you in. The levitated [three
> disk magnets connected by long arms] simply flops out of your carefully
> arranged [three ring magnets] and proceeds to ... resting on the ground.

Dale is correct.  I was focusing on the arms on the *assumption* that the
disk-over-ring arrangement was capable of creating a shallow but real
potential well that provided lateral stability.  After trying it out with
some real magnets, I'm now convinced that this potential well does not
really exist, and thus the entire arrangement cannot depend on its lateral
stability.

Experimentally, the non-existent potential well of which I'm speaking is
an interesting sort of tactile illusion -- you can run a disk over a ring
with your hands and rather easily persuade yourself that there is a well
of some sort there (there is) *and*, more importantly, that it retains
the ability to repel the disk magnet while simultaneously providing a
certain degree of lateral stability.  And in fact, both of those attributes
*are* true -- you can get some repulsion with some lateral stability.

What's not obvious until you start making more careful versions of the
experiment, however, is that the potential well is like a failing elevator
-- it's inherently unstable, and once the disk magnet falls a little ways
into it the repulsion effect begins to drop rapidly.  Entering this little
well thus means a trip on down to the bottom

And guess what?  The lateral stabilization effect does not exist *until*
you drop into the well, at least just a wee little bit -- which is all
it takes to destabilize and drop down to the bottom.

(And anywho, it gave me a great excuse to play around with magnets again,
which I *always* enjoy doing!)

				Cheers,
				Terry

Newsgroups: sci.physics,rec.arts.startrek.tech
From: petitc@nuge113.its.rpi.edu (Christopher Jon Petit)
Subject: Re: Accellerating Spaceship (yet another bird in a plane)
Date: Mon, 14 Dec 1992 04:25:11 GMT

ses52823@uxa.cso.uiuc.edu (Marius) writes:

>Although I realize this isn't a Star Wars newsgroup...

>I wanted to clarify my previous definitions of the 'wormhole travel' tech --

>* Star Wars ships can't maneuver (as per Peter Suk) faster than the speed of
>  light.  Their hyperdrives are only calibrated to calculate a clear linear
>  path (so that they don't, say, wormhole into a sun) and then go go go...
>  This is why the Millenium Falcon can't evade the Star Destroyers in some of
>  the scenes from all three movies -- they don't have enough time/distance
>  to clear a hyperspatial path.

>* Han Solo does however mention at one point in time (you'd have to see 
>  rec.arts.sf.starwars to find the source) that his engines (NOT hyperdrive)
>  are capable of 1.5 times the speed of light (he says 'point five past c')

  Actually, you got it wrong.  When he says "She'll make .5 past lightspeed",
he's referring to the Hyperdrive.  Why?  Because, if you look in the newest
Star Wars saga (Heir to the Empire), they mention that a cruiser can do about
.3, but, when I did the math, .3 came out to be about 65,000 times c!

  So, it seems that their scale is 0 < x < 1, where x is a measure of
hyperspatial speed.

-- 
Now on sale, in Aisle 5 of the Divine Supermarket---Lives, and Clues.  Buy
yours now and avoid the rush!  They make great Christmas gifts!
"I may not agree with what you say, but I will defend to the death your right
to say it."  - Voltaire.
Newsgroups: sci.physics,sci.math
From: sschaff@roc.SLAC.Stanford.EDU (Stephen F. Schaffner)
Subject: Re: Physics World - Digest of December issue
Organization: Stanford Linear Accelerator Center
Date: Mon, 14 Dec 1992 22:51:20 GMT

In article <1992Dec14.192949.20557@galois.mit.edu>, jbaez@riesz.mit.edu (John C. Baez) writes:

|> A great idea!  Why stop there?  
|> 
|> I eagerly look forward to the development of degree programs in
|> the humanities that do not require literacy!

It's called "Film Studies".

-- 
Steve Schaffner        sschaff@unixhub.slac.stanford.edu
	The opinions expressed may be mine, and may not be those of SLAC, 
Stanford University, or the DOE.
Newsgroups: sci.physics
From: ahall@fmrco.com (Andrew Hall)
Subject: Re: TIME HAS INERTIA
Organization: Fidelity Management & Research Co.
	<abian.724571877@pv343f.vincent.iastate.edu>
	<1992Dec17.184403.26492@ugle.unit.no>
Date: Fri, 18 Dec 1992 17:52:26 GMT

In article <1992Dec17.184403.26492@ugle.unit.no> kim@Lise.Unit.NO (Kim Gunnar St|vring yhus) writes:

   Here the EVIL Abian is demonstrating how STUPID he is. He clearly don't
   understand that since he did write LOTS, he must have had time.

   And Abian is LYING! He said that Daniel Seeman said he was modest and immodest. I
   read him, and he said neither. Yet again Abian demonstrates how EVIL he is.

I don't think he is evil or stupid.  He is very ill --- probably a manic/depressive
in a wildly manic stage.  I have seen three people go over the edge in a manic state
and they were very similar to Abian (wild theories, delusions of grandeur, listen to
nobody, etc).  If there was some way to contact his peers maybe something could be
done about it.  All most manic/depressives need is a daily dose of lithium.

This thread has gone from being an amusing absurdity to a fairly tragic demonstration
of a mind breaking down.  Notice that lately he has gotten much worse with his "logic"
and how fragmented (in syntax and spelling) his posts have become.


=======================================================================


Keep the war alive.
                -- A White House official, describing President Bush's
                   1992 reelection strategy.
From: deanaj@elec.canterbury.ac.nz (A. J. Dean)
Subject: Re: assembly vs C (was: FFTs for the 486)
Organization: Electrical Engineering, University of Canterbury, New Zealand
X-Newsreader: TIN [version 1.1 PL6]
Date: Mon, 14 Dec 1992 04:14:19 GMT

Mike Newberry (newberry@aquarius.as.arizona.edu) wrote:
: One point you brought up that I forgot to mention about the Watcom C/386
: compiler is that it can pass and retrieve arguments using registers instead
: of pushing and popping the stack as per the original C standard.  That does
: save some time when your code calls a function inside a tight loop.  The
: Watcom C/386 compiler is an industrial strength package that one doesn't find
: all that often in the PC world. I understand that Metaware's compiler is
: of similar caliber but I can't speak from experience with it.

Come to think of it it has always been one of my pet peeves why compilers
don't just treat code as one big piece of, well, code. It could keep a
track of when variables 'start' and when they 'finish' and allocate
memory/use registers accordingly, despite the fact there may happen to
be a few functions (which are never called from anywhere else) nested
in there. It makes programming in a structured way also the most
inefficient way to program! (unless you use assembly...(bias)) But I'm
going against my original comment that robust and intelligent compilers
would be difficult to make. Another (as you noticed) is that C is really
a low level language and 'the standard' assumes you know what the machine
is going to do with your code.

We've actually got a Watcom fortran 486 compiler here which is supposed
to scream. Apparently only works on a 486. I might get into it and see
how it ticks (after learning fortran again...).

I must shut up on this subject anyway. Always gets me into trouble!

Antony
Newsgroups: sci.image.processing
From: newberry@aquarius.as.arizona.edu (Mike Newberry)
Newsgroups: sci.image.processing
Subject: Re: assembly vs C (was: FFTs for the 486)
Date: 11 Dec 92 23:23:17 GMT
Organization: University of Arizona, Tucson, AZ

In article <Bz2rKn.ByF@cantua.canterbury.ac.nz> deanaj@elec.canterbury.ac.nz (A. J. Dean) writes:
>Mike Newberry (newberry@aquarius.as.arizona.edu) wrote:
>: >you are using, etc. PC C compilers seem to be generally pretty useless, even
>: >if they do optimise they often still leave massive room for improvement in
>: >the assembly. Sparc compilers seem to get it together much more. But if you
>: 
>: It depends greatly upon the PC compiler.  Watcom C/386 and Metaware High C
>: produce good code, as one can tell by disassembling the object module and
>: inspecting the assembly code.  The 16 bit compilers all have troubles
>: because of the 16 bit address space and the fact that the 287 compatible
>: code they produce has no sin, cos, arcsin, and arccos instructions--they
>: don't exist on the 87 and 287.  They so exist on higher processors.
>
>No doubt, they are getting _much_ better. A lot of it seems to be to do with
>the way arguments and data is passed into functions - quite slow on a 80x86,
>but I suppose like the lack of sin, cos etc there is some minimum amount of
>mess you just have to put up with.  Also something I don't immediately
>appreciate while looking wild-eyed at some ultimately 'stupid' compiler
>output, is that it did have to be compiled, and every departure from the
>line by line approach leaves a little more room availble for something to
>come unstuck. Someone has to write the compiler after all. Though I still
>rekon I could do it better!...
>
>Antony.

One point you brought up that I forgot to mention about the Watcom C/386
compiler is that it can pass and retrieve arguments using registers instead
of pushing and popping the stack as per the original C standard.  That does
save some time when your code calls a function inside a tight loop.  The
Watcom C/386 compiler is an industrial strength package that one doesn't find
all that often in the PC world. I understand that Metaware's compiler is
of similar caliber but I can't speak from experience with it.
.
From: smith@mcclb0.med.nyu.edu
Newsgroups: sci.image.processing
Subject: Re: FFT software
Date: 17 Dec 92 07:20:32 EST
Distribution: world
Organization: NYU Medical Center, New York, NY 10016, USA

In article <1992Dec17.012938.23423@jupiter.sun.csd.unb.ca>, akarpowicz@mta.ca (Adam Karpowicz) writes:
> ....
> I do not want to invest a lot of money (usually ~$2000) for software
> until I know if the method works for me. Is there a PD or shareware
> to do FFT on images? 
> 
We have a FFT program set on this machine available via anonymous/FTP. We 
also have a progrma package that uses this which might do what you want. But 
it runs on VAXes and Ultrix DECstations.

+----------------------------------------------------------------------------+
|Ross Smith,  Research Computing Resource, Department of Cell Biology, NYU-MC|
|E-Mail:  SMITH@NYUMED.BITNET (BITNET),   SMITH@MCCLB0.MED.NYU.EDU (Internet)|
+----------------------------------------------------------------------------+
From: dak@kaa.informatik.rwth-aachen.de (David Kastrup)
Newsgroups: sci.image.processing
Subject: Re: assembly vs C (was: FFTs for the 486)
Date: 14 Dec 92 23:12:41 GMT
Organization: Rechnerbetrieb Informatik - RWTH Aachen
NNTP-Posting-Host: kaa.informatik.rwth-aachen.de

newberry@aquarius.as.arizona.edu (Mike Newberry) writes:

>One point you brought up that I forgot to mention about the Watcom C/386
>compiler is that it can pass and retrieve arguments using registers instead
>of pushing and popping the stack as per the original C standard.  That does
>save some time when your code calls a function inside a tight loop.  The
>Watcom C/386 compiler is an industrial strength package that one doesn't find
>all that often in the PC world. I understand that Metaware's compiler is
>of similar caliber but I can't speak from experience with it.
>.

One thing about the GNU compiler is that you can imbed fragments you write
yourself in assembly language in such an ingenious way into plain C code
(without calls or such), that the compiler chooses the addressing modes
best to employ in your assembly code, knows about the side effects,
and may optimize multiple use of your code away, if you tell it that
your code depends solely on the input parameters. You tell GNU as well
which registers are thrashed, and what registers CAN be used in your
instructions.

I have had the C compiler generate better code with only very short
templates than I would have done myself, because I was not as firm in
the use of addressing modes of the 386.

The GNU assembler templates are yet something I have to see surpassed
by ANY commercial compiler. Usually, IF you have a possibility of
inlining assembly code, one thing it does is throwing the optimizer
for a loop. Not so with GNU.
Newsgroups: sci.image.processing
From: lam@mrcnext.cso.uiuc.edu (Ken Lam)
Subject: Overlay photoimage/altimetry data..any software to do this?
Organization: University of Illinois at Urbana
Date: Wed, 16 Dec 1992 14:24:48 GMT

I've got some images and altimetry data which I want to overlay.  Does anyone
have any suggestions on how to do this?  Any software packages?

Thanks..Ken

--
Ken Lam                                                     (803)-884-7615 (H)
System Administrator                                        (803)-792-4969 (W)
Senior Systems Consultant                                   (803)-792-5446(FAX)
Netware/UNIX System Programmer/Integrator                    lam@jove.cofc.edu
MultiMedia Works & Video Productions ======= Teaching the world in better ways

Newsgroups: sci.image.processing
From: jempci@ultb.isc.rit.edu (J.E. Mason)
Subject: [Remote sensing]Question on LOWTRAN7 handling of clouds.
Originator: jempci@ultb
Organization: Rochester Institute of Technology
Distribution: sci.image.processing
Date: Fri, 18 Dec 1992 12:56:40 GMT

Can anyone familiar with LOWTRAN7 tell me how it computes atmospheric
radiance and transmission values when clouds are present?  Or at least
point me in the right direction?  The USER'S GUIDE TO LOWTRAN7 (dated 
16 August 1988) is of little help.

Thanks,


John E. Mason
-- 
************************************************************************
John E. Mason        |      jempci@ultb.isc.rit.edu
************************************************************************
From: kboland@ee.egr.duke.edu (V. K. (Keith) Boland)
Newsgroups: sci.image.processing
Subject: Looking for real-time benchmarks
Date: 11 Dec 92 20:43:48 GMT
Organization: Duke University EE Dept.; Durham, NC


Does anyone know of any publically available
image processing programs that are in use in
real-time systems (ie a manufacturing robot
processing an image, etc..).  I am interested
in doing some performance analysis research
on such programs.

Thanks in advance,

- Keith Boland
  kboland@egr.duke.edu
Newsgroups: sci.image.processing
From: carlin@gandalf.nosc.mil (Mike Carlin)
Subject: acoustic imaging
Originator: carlin@gandalf.nosc.mil
Organization: Naval Ocean Systems Center, San Diego
Date: Wed, 16 Dec 1992 23:52:42 GMT


Hello,

Does anyone know of any researchers who have been using the Astronomical
Image Processing System (AIPS) software package for acoustic imaging
(e.g. medical imaging, petroleum exploration)?  If yes, I would 
appreciate it if you could provide me with information as to how to
contact them.  I have the same request concerning users of the MIDAS and
IRAF image processing packages.

For those of you using AIPS, MIDAS or IRAF for non-radio astronomical
purposes, did you find it easy to use and easy to modify for your 
purposes?

Can anyone doing acoustic imaging recommend any other software packages?

Thank you for your time.

Michael Carlin
carlin@nosc.mil
(619) 553-1795


Newsgroups: sci.image.processing
From: dottir@callisto.nr.no (Jorunn Olafsdottir)
Subject: OCR-systems
Organization: /nr/pluto/u1/dottir/.organization
Date: Fri, 18 Dec 1992 10:42:42 GMT

PLease, have patience if this has been thoroughly discussed
earlier.

I would like any information about commercially avaliable
OCR-machines/systems. Information about producers, prize, 
performance etc. is og great interest.
If there has been done any work on evaluation of different OCR
systems I would really appreciate a copy.

Thanks in advance !

Jorunn Olafsdottir
Norwegian Computing Center
Po.box 114, Blindern
Norway

Email: Jorunn.Olafsdottir@nr.no
Newsgroups: sci.image.processing
From: mukul@laser1.engr.utk.edu (Mukul Shirvaikar)
Subject: Re: Similarity metric for images
Keywords: image restoration, image metrics, noise reduction
Organization: University of Tennessee ECE dept.
Date: Fri, 11 Dec 1992 18:12:03 GMT

With regard to the discussion on image quality, please refer to the 
following paper in the "Special Issue on Target Recognition":

  ``Developing Texture-Based Image Clutter Measures for Object Detection'', 
  Mukul V. Shirvaikar and M.M. Trivedi, {\it Optical Engineering}, Dec 1992.

I hope it is helpful. The references should lead you to a few other 
good papers too.

Mukul
From: khan@diku.dk (Klaus Hansen)
Newsgroups: sci.image.processing
Subject: Re: Images needed for edge-detection algorithm evaluation
Date: 11 Dec 92 16:57:57 GMT
Organization: Department of Computer Science, U of Copenhagen

I am at the moment working on a set of synthetic images
(i.e. algorithmically/computer generated) with specific
properties for testing edge detectors. Some of them
comes with a "solution" (but some does not have edges
at all, and no "answer" is in existence).

However, I am still working on it, so it would be a bit
premature to release the set.

I don't know of other images specifically constructed
for evaluation; it is quite normal to take a well-known
image (e.g. lennie) or a local photography and use that.

One of my images is a simple edge overlayed with a ceratin
amount of noise. Other images test symmetry, corners.

Klaus Hansen, DIKU
Newsgroups: sci.image.processing
From: akarpowicz@mta.ca (Adam Karpowicz)
Subject: Re: FFT software
Reply-To: akarpowicz@mta.ca
Organization: Mount Allison U, Sackville, N.B. Canada 
Date: Thu, 17 Dec 1992 15:37:09 GMT

In article <1992Dec17.072032.7172@mcclb0.med.nyu.edu>, smith@mcclb0.med.nyu.edu writes:
>In article <1992Dec17.012938.23423@jupiter.sun.csd.unb.ca>, akarpowicz@mta.ca (Adam Karpowicz) writes:
>> ....
>> I do not want to invest a lot of money (usually ~$2000) for software
>> until I know if the method works for me. Is there a PD or shareware
>> to do FFT on images? 
>> 
>We have a FFT program set on this machine available via anonymous/FTP. 

Could you send me the FTP adress?  (*nyu.edu?)

>We 
>also have a progrma package that uses this which might do what you want. But 
>it runs on VAXes and Ultrix DECstations.

Won't work, I use MSDOS.

Thanks for help

Adam  akarpowicz@mta.ca
From: carldelo@phoenix.Princeton.EDU (Carl James Delo)
Newsgroups: sci.image.processing
Subject: test
Date: 16 Dec 92 20:38:20 GMT
Distribution: princeton
Organization: Princeton University
Originator: news@nimaster

this is a test
From: bobw@csg.uwaterloo.ca (Bob Wildfong)
Subject: Re: assembly vs C (was: FFTs for the 486)
Organization: Computer Systems Group, University of Waterloo
Date: Mon, 14 Dec 1992 21:22:59 GMT

In article <Bz0J8F.4IC@cantua.canterbury.ac.nz> deanaj@elec.canterbury.ac.nz (A. J. Dean) writes:
>For example I was able to speed up an 80x86 FIR filtering routine over 15*
>over the original hand optimised _assembly_ (ie we're not talking about the
>usual assembly vs C argument here) just buy taking advantage of the needs of
>the application and assembly's freedom. Things like unrolling the right
>loops the right number of times, using the most cunning addressing modes,
>lookup tables etc. Until I see this sort of 'cunning' built into a compiler
>(or assembler) I will never believe that assembly has lost it. To each their
>own opinions...
>
>Antony.

While it's true that most C optimizers don't do these "cunning" things,
one can just as easily use the same tricks to hand-optimize C code (write
the code using unrolled loops and lookup tables in the first place).  You
can't exploit handy addressing modes, but IMHO you rarely save much by
doing so anyway, since the addressing modes which compilers tend to not use
are hardly ever useful in real applications (now and then doesn't count for
much).

So you lose the elegance of the original "un-optimized" C code, but I'd
rather maintain a messy C routine than a messy assembler routine.

Yet another $0.02  (must have about a buck by now)

Bob Wildfong
University of Waterloo
Newsgroups: sci.image.processing,sci.med.physics
From: jogl@numenor.imsd.rwth-aachen.de (Joachim Glaubrecht  #Alwd#)
Newsgroups: sci.image.processing
Subject: wanted: (pseudo)color _L_U_T_ (LookUpTable)
Date: 17 Dec 1992 12:47:55 GMT
Organization: Institut f. Med. Statistics @ Dokumentation
NNTP-Posting-Host: numenor.imsd.rwth-aachen.de


hi,

the "Subject:"-line say's it all. we are about to test some
(pseudo)color LookUpTables for grey-scale images (12Bit/Pixel or
256 Grey-Scales) and like to collect some.

any kind of point to books and reviews are also wellcome!
                    ~~~~~~~   ~~~~~~~~~
we primary use the KHOROS-Software, but LUTs in ANY format
(e.g. PBMPlus) are o.k.

any idea/help for us ?
-- 
  ___             _________________________________________
 /  /  _____     !    jogl@tolkien.imsd.rwth-aachen.de     !
 __/__/_/ Gl     ! Inst. f. med.Inform. & Biometrie (IMIB) !
/_/              !___Never_send_a_boy_to_do_a_man's_job____!
Newsgroups: sci.image.processing