HDTenEightyP/NetNews huggingface dataset:
From: bweiner@ruhets.rutgers.edu (Benjamin Weiner)
Newsgroups: sci.astro
Subject: Re: The Hole Story
Date: 11 Dec 92 20:41:35 GMT
Organization: Rutgers Univ., New Brunswick, N.J.

young@spinifex.dg.oz (Philip Young) writes:


> (Jack Gallimore,P254) writes:
>|> [...]  I was always led to believe that a photon emitted
>|> at the event horizon could at best simply "orbit" if it were sent in 
>|> the right direction.  Could you clear this up?  My GR was a while back
>|> and I'm very rusty.
>|> -- 
>|>          Jack Gallimore

>While we're in "clearing up" mode, would such a photonic orbit be
>allowable under current theories?

Yeah, if you work out the circular orbit of a test paricle in Schwarzschild
geometry, the speed of the particle is c at r=2M (event horizon).  I.e.
a circle around the BH's "equator" at r= 2M is a null geodesic.  A massive
particle can't follow this path though.  In other words the light cone at
r=2M has one edge aligned with the r=2M worldline.

>If so, could it be stable?

No.  The moment it is perturbed to the inside, the light cone tips over
and the particle, or photon, is doomed to hit the singularity.  You
can derive an upper limit of, I think, ~ 10^-5 sec (proper time) to the 
singularity for a 1 M_sun black hole.  Which should point out why this
"communication through the horizon" stuff is irrelevant.  (Note: how
you gonna "communicate" with the static field?  You need _radiation_ to
communicate, and we do agree that gravitational radiation can't escape
a BH, right?)
From: strobel@dirac.phys.washington.edu (Nicolas Strobel)
Newsgroups: sci.astro
Subject: collision timescales in galactic disk
Summary: How find collision timescales in flat rotation curve disk
Keywords: galaxy disk collision
Date: 17 Dec 92 23:58:09 GMT
Distribution: na
Organization: University of Washington

Can anyone give me a derivation of the timescale between collisions of
objects in the slightly less trivial case of a rotating galactic disk?
I know the timescales for a spherically distributed system with no net
rotation. The case of a flattened system whose rotation tends to keep
objects from colliding as frequently as if there was no rotation should
be a little trickier to find. The particular case I'm interested in is
one for a flat rotation curve galactic disk with a given velocity 
dispersion ellipsoid (or epicyclic frequencies).

Please email. If there is interest, I'll post what answers I receive.

Thanks
Nick Strobel
strobel@dirac.phys.washington.edu
From: j.jahn@abbs.hanse.de (Jost Jahn)
Newsgroups: sci.astro
Subject: Sunspots at 13.12.1992.
Reply-To: j.jahn@abbs.hanse.de
Date: 13 Dec 92 15:59:00 MET
Distribution: sci
Organization: ABBS AstroMail, D-W 2121 Dahlenburg / Germany
X-Version: ZerUU V6.45c

Sunspots at 13.12.1992., 0 h UT.

No.    Pos.  Cl.  Ar.  Mag. SF  F  M  X
---------------------------------------
7355 18S 50W Hsx   50   a
7360 18S 09W Eao  390   b    2
7362 06S 23W Eki  580   b
7363 08S 19E Dao  140   b
7364 09N 16E Cso   60   b
7365 21S 43W Bxo   10   b
7366 12S 44E Dao   90   b    3


No optical or x-ray flares yesterday observed.


 
--
------------------------------------------------------------------------------
ABBS AstroMail, the first and most popular German astronomical bulletin board
------------------------- for amateur astronomers ----------------------------
    + 49 5851 7896 / V.21, V.22, V.22bis, V.32, V.42, V.42bis and MNP5
    ------------------------------------------------------------------


Newsgroups: sci.astro
From: Brian Drummond <drummond@taligent.com>
Subject: Undercorrected mirrors
X-Xxmessage-Id: <A756140E8802C1D0@kip-14.taligent.com>
X-Xxdate: Thu, 17 Dec 92 19:25:02 GMT
Organization: Taligent, Inc.
X-Useragent: Nuntius v1.1.1d9
Date: Thu, 17 Dec 1992 19:22:06 GMT

I've read in several ATM articles that some mirror makers intentionally
under correct their mirrors (one number is 90% of full correction). 
Apparently the thought is that most mirrors are used in falling
temperatures (e.g., evening time) and that under correcting the mirror
counteracts the over correcting effect of uneven temperature cooling
across the surface.   The overcorrection occurs when the edge zone of the
mirror "curls" up a little.

How much of an effect is this over correcting due to cooling?  I suppose
the severity depends on the amount of temperature difference over time.  

Is undercorrecting frequently done?
----------------------------------------------------------
Brian Drummond                    |          Taligent, Inc.
email: drummond@taligent.com	  |          Cupertino, CA
From: donald.mcintyre@almac.co.uk (Donald Mcintyre)
Newsgroups: sci.astro
Subject: Hubble constant
Date: 11 Dec 92 18:11:00 GMT
Reply-To: donald.mcintyre@almac.co.uk (Donald Mcintyre)
Organization: Almac BBS Ltd. Scotland. +44 (0)324-665371


>I heard recently that there was new evidence just published somewhere
>pinning the Hubble constant to about 60 km/sec/megaparsecs. Can anyone
>comment on how this relates to estimates on the time from the Big
>Bang?

The following articles may be of interest:

The Hubble Constant
Huchra, John P.
Science 256 (17 April 1992) 321-325

The Hubble constant takes the low road again
Travis, John
Science 257 (3 July 1992) 34
Research News
---
 . DeLuxe. 1.25 #12084 .
From: paul.burnett@pcs.sj.ca.us (Paul Burnett) 
Newsgroups: sci.astro
Subject: Re: Yet Another "New Look
Date: 12 Dec 92 08:51:00 GMT
Distribution: world
Organization: PCS-BBS - San Jose, CA - 408-270-4085
Reply-To: paul.burnett@pcs.sj.ca.us (Paul Burnett) 

TO: tomrice@netcom.com

TRR>>Why?  Granted that some things stay the same, a collection of articles
   >>from _Scientific American's_ ATM columns from the 1930's and 1940's is
   >>simply too old to be of much use at all.

TRR>    Perhaps I've become confused here.  The ATM to which I
   >    was referring was the three-volume set Amateur Telescope
   >    Making.  I'm not aware that the books are comprised of
   >    previously-printed magazine pieces; some are simply too
   >    long and others too technical, IMHO.

If you'll look in the front of your three volumes, you might notice some
copyright dates (if you care to do so, please let us know what your
research shows) and other information as to the origin of the books. For
several decades, the predecessor to _Scientific American's_ current
"Amateur Scientist" column was the "Amateur Telescope Maker" column - it
eventually spread beyond just astronomy and telescope making into the
realm of general science; into amateur science instead of restricting
itself to just telescope making and astronomy.

TRR>    If I'm wrong, then
   >    it indicates that Sci. Am. was a helluva lot better mag
   >    in the old days than it is today.

You are exactly right.  For many years SA was a weekly, and was
published in a larger format (LIFE-magazine size).

TRR>    I beg to differ with the "too old to be of much use at all" part,
   >    as well.

TRR>    There's nothing wrong with learning some fundamentals
   >    and some history in any field, if only because it'll
   >    help you avoid making silly mistakes.

Granted - I have no problem with learning fundamentals - but technology
and materials have progressed considerably in the sixty years since the
older articles in the ATM.  The common names of chemicals have changed
considerably, and plastics have replaced natural fibers and other
materials - have you tried to locate any gutta percha recently?
---
 . QMPro 1.0 41-8688 . ...from San Jose, CA
                                                                            
Newsgroups: sci.astro.fits
From: thompson@stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040)
Subject: Re:      Re: VAX R*8 to FITS/IEEE R*8 conversion problem
News-Software: VAX/VMS VNEWS 1.4-b1  
Organization: NASA/GSFC-Laboratory for Astronomy and Solar Physics
Date: Thu, 17 Dec 1992 19:53:00 GMT

In article <9212171724.AA01436@fits.cv.nrao.edu>, Lucio Chiappetti <lucio@ifctr.mi.cnr.it> writes...

	(stuff deleted)

>  The conversion from G_FLOAT would be analogous to the R*4 one, but the
>  one for D_FLOAT (the reverse of the ieeed routine in the IRAF VMS assembler
>  routine) is not obviously done in Fortran.
>  What I am uncertain of, is whether I should continue using D_FLOAT on Vax
>  or move to G_FLOAT.
> 
>  I actually use quite a limited amount of REAL*8 values, and I was always
>  happy with applying some scale factors when exceeding the exponent range
>  (1.OE38 for both R*4 and D_FLOAT R*8). From the quoted assembler routine
>  I derive that IRAF does the same.
> 
>  I would appreciate to know other people's opinion on the matter
>  whether G_FLOAT should be recommended on VMS for IEEE compatibility,
>  or not.

I believe that G_FLOAT and H_FLOAT (REAL*16) are not supported on the new Alpha
machines.

We use IDL, which doesn't give the user the option of selecting D_FLOAT or
G_FLOAT (and doesn't support quadruple-precision).  On the VAX, it uses D_FLOAT
numbers for double precision.  (As an aside, IDL does provide built-in support
for converting between IEEE and host formats, for all datatypes it supports.)

Bill Thompson
Newsgroups: sci.astro.fits
From: bhill@stars.gsfc.nasa.gov (Robert S. Hill)
Subject: Re: VAX R*8 to FITS/IEEE R*8 conversion problem
News-Software: VAX/VMS VNEWS 1.4-b1  
Organization: Hughes STX Corp./NASA Goddard Space Flight Center
Date: Thu, 17 Dec 1992 20:10:00 GMT

In article <JENNINGS.92Dec17144132@antwrp.antwrp.gsfc.nasa.gov>, 
jennings@antwrp.antwrp.gsfc.nasa.gov (Don Jennings) writes...
>In article <9212171630.AA05949@tetra.gsfc.nasa.gov> William Pence writes:
>   My reaction to this is that it is not very useful to put information in a FITS file
>   that only a particular machine will be able to interpret.  One of the main purposes of 
>   FITS is to make the information in the file portable to any machine.  So I think
>   you have 2 choices.
> 
>The precision is significant, in that we must be able to repoduce the original
>data byte for byte. Breaking the VAX R*8 up into an IEEE R*8 + remainder would
>still introduce roundoff error.

I just want to cast a vote that stuffing part of the VAX precision into
the IEEE format (with an auxiliary byte) seems like questionable  style
to me.  It would be much better to split the number up, as someone
suggested, into an exponent and mantissa, then store those as integers.
Extended precision formats you make up yourself from scratch, cleanly,
should be easier to deal with than ``IEEE-plus.''

Perhaps it would be better for user-friendliness to make the exponent

       fix(log10(stuff))    instead of   fix(log2(stuff) + offset)

with the corresponding change in the mantissa.


Robert S. Hill                  
bhill@stars.gsfc.nasa.gov
Newsgroups: sci.astro.fits
From: forveill@gag.observ-gr.fr (Thierry Forveille)
Subject: Re: VAX R*8 to FITS/IEEE R*8 conversion problem
Organization: National Radio Astronomy Observatory
Date: Fri, 18 Dec 1992 08:16:13 GMT

I received the mail below from Thierry Forveille privately, but then we
both considered it could be of interest to the list, so I am forwarding
it below.
                             Lucio Chiappetti


----------------------------Original message----------------------------
We actually have available some fortran code that performs the transformations
you need and which I can send you if you like. It was developped for exactly
the kind of application you contemplate, transparent access to data files
accross an heterogeneous network. In addition to what you request, we also
support conversion to non-native formats since we also want to modify files
on other machines, not only read them.
The code is written in fortran (I agree the R*8 conversion is non trivial!)
and performs all possible conversions between Vax and both flavours of IEEE
(little and big endians), and has versions for all three types of hardware
(for efficiency, it uses integer multiplications instead of bit shifts where it
can). All IEEE special values are handled (infinities, NaNs...) are handled,
and converted to a user specified blanking value. These routines have been
extensively used for about two years, and work without user complaints...

        Thierry Forveille
        Observatoire de Grenoble
        forveill@gag.observ-gr.fr
Newsgroups: sci.astro.fits
From: jennings@antwrp.antwrp.gsfc.nasa.gov (Don Jennings)
Subject: VAX R*8 to FITS/IEEE R*8 conversion problem
Organization: Compton Gamma Ray Observatory Science Support Center
Date: Thu, 17 Dec 1992 13:54:50 GMT

My organization often needs to convert data that is native to the VAX
architecture into a FITS format. Since the VAX real*8 bit pattern is different
from the FITS/IEEE real*8 bit pattern, it is not possible to completely
encapsulate a VAX real*8 in a IEEE real*8; specificly, a loss of precision
occurs when transforming a VAX real*8 into an IEEE real*8.

One solution we have devised is to save the 7th byte of VAX real*8 values, 
where the loss of precision occurs, and add them to a column of the binary
table where the real*8 values are being stored. The following is a suggested
list of rules for the extra column:

   It would always be the last column of the table.

   Each column entry would contain the 7th byte of all real*8 values
   occurring in a given row. Thus, if a table row contained 5 real*8
   values, then the extra column's TFORM code would be 8B, if the
   row contained any real*8 variable length array entries then the
   extra column's TFORM code would be PB(XXXX).

FITS readers residing on non-VAX architectures would be able to ignore the
extra column, while VAX FITS readers could completely reconstruct the original
real*8 value by reading the extra column's values.

Has anyone out there had this problem? Does anyone out there have a 
different solution? If so, then I would like to hear from you. Please 
send/post any general comments on the above scheme you might have as well. 

                    Don Jennings, COSSC/GSFC 
Newsgroups: sci.astro.fits
From: jennings@antwrp.antwrp.gsfc.nasa.gov (Don Jennings)
Subject: Re: VAX R*8 to FITS/IEEE R*8 conversion problem
Organization: Compton Gamma Ray Observatory Science Support Center
Date: Thu, 17 Dec 1992 19:41:32 GMT

In article <9212171630.AA05949@tetra.gsfc.nasa.gov> William Pence writes:


   I think you mean 5B, not 8B  (?)

Yes, I meant 5B not 8B; sorry for the dyslexia

   My reaction to this is that it is not very useful to put information in a FITS file
   that only a particular machine will be able to interpret.  One of the main purposes of 
   FITS is to make the information in the file portable to any machine.  So I think
   you have 2 choices.

   1.  If this added precision in the VAX value is really significant, then you 
   need to find a portable way of including it in the FITS file.  One way might be
   to express the double precision value as 2 columns:  one containing the integer
   part, and the other containing the fractional part of the value.

   2.  If the added precision in the VAX value is not really significant (the VAX
   G_floating datatype has effectively 4 more bits of precision than an IEEE R*8 value)
   then one should not worry about it, and one should accept the fact that the
   FITS file cannot preserve every last bit of information on every type of machine.

The precision is significant, in that we must be able to repoduce the original
data byte for byte. Breaking the VAX R*8 up into an IEEE R*8 + remainder would
still introduce roundoff error.


   As an aside, I'm sure you are aware that the VAX has 2 different R*8 data 
   representations.  The default D_floating representation which you are probably using
   reserves 8 bits for the exponent and 55 bits for the mantissa.  The G_floating
   representation on the otherhand is similar to the IEEE R*8  representation: both
   have 11 bits for the exponent and 52 bits for the mantissa.  The G_floating
   and IEEE values are still not identical though because the VAX interprets the
   exponent and mantissa numbers as normalized, ("hidden bit normalization") which
   effectively gives you another bit of precision compared to the IEEE value.
   If you were to use G_floating on the VAX, you probably would not notice the
   loss of precision in converting the data back and forth from FITS.


I was aware of the D_floating and G_floating compiler options, but did not
know that much about them. Unfortunately, the data is produced using D_floating
and there is nothing we can do about it.

Thanks for your interest Bill. I'll think about what you had to say. 


                        Don Jennings
From: cflatter@nrao.edu (Chris Flatters)
Newsgroups: sci.astro.fits
Subject: Re: VAX R*8 to FITS/IEEE R*8 conversion prob
Date: 17 Dec 92 18:09:12 GMT
Reply-To: cflatter@nrao.edu
Organization: NRAO

In article AA05949@tetra.gsfc.nasa.gov, pence@tetra.gsfc.nasa.gov (William Pence) writes:
>As an aside, I'm sure you are aware that the VAX has 2 different R*8 data 
>representations.  The default D_floating representation which you are probably using
>reserves 8 bits for the exponent and 55 bits for the mantissa.  The G_floating
>representation on the otherhand is similar to the IEEE R*8  representation: both
>have 11 bits for the exponent and 52 bits for the mantissa.  The G_floating
>and IEEE values are still not identical though because the VAX interprets the
>exponent and mantissa numbers as normalized, ("hidden bit normalization") which
>effectively gives you another bit of precision compared to the IEEE value.
>If you were to use G_floating on the VAX, you probably would not notice the
>loss of precision in converting the data back and forth from FITS.

IEEE values are also normalized as long as they are greater than or equal
to 2 ** E_min, where E_min is the minimum exponent.  An IEEE-754 double
has a precision of 53 base-2 digits (identical to VAX G-floating) as long
as E >= E_min (E_min = -1022).  VAX G-floating and IEEE-754 doubles probably
differ in the bias of the exponent (this is the difference between normalized
IEEE singles and VAX F-floats).

Incidentally, if you think about it you will realize that the exponent can
not be normalized.

	Chris Flatters
	cflatter@nrao.edu
Newsgroups: sci.astro.fits
From: thompson@stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040)
Subject: Re: VAX R*8 to FITS/IEEE R*8 conversion problem
News-Software: VAX/VMS VNEWS 1.4-b1  
Organization: NASA/GSFC-Laboratory for Astronomy and Solar Physics
Date: Thu, 17 Dec 1992 20:04:00 GMT

In article <JENNINGS.92Dec17085450@antwrp.antwrp.gsfc.nasa.gov>, jennings@antwrp.antwrp.gsfc.nasa.gov (Don Jennings) writes...
>My organization often needs to convert data that is native to the VAX
>architecture into a FITS format. Since the VAX real*8 bit pattern is different
>from the FITS/IEEE real*8 bit pattern, it is not possible to completely
>encapsulate a VAX real*8 in a IEEE real*8; specificly, a loss of precision
>occurs when transforming a VAX real*8 into an IEEE real*8.
> 
>One solution we have devised is to save the 7th byte of VAX real*8 values, 
>where the loss of precision occurs, and add them to a column of the binary
>table where the real*8 values are being stored. The following is a suggested
>list of rules for the extra column:
> 
>   It would always be the last column of the table.

This statement alone raises warning flags in my mind.  I'm firmly of the
opinion that the structure of binary tables should not in any way depend on the
order in which the columns appear.  If you're going to do something like this,
you should indicate the column with an appropriate label (TTYPE).

> 
>   Each column entry would contain the 7th byte of all real*8 values
>   occurring in a given row. Thus, if a table row contained 5 real*8
>   values, then the extra column's TFORM code would be 8B, if the
>   row contained any real*8 variable length array entries then the
>   extra column's TFORM code would be PB(XXXX).
> 
>FITS readers residing on non-VAX architectures would be able to ignore the
>extra column, while VAX FITS readers could completely reconstruct the original
>real*8 value by reading the extra column's values.
> 
>Has anyone out there had this problem? Does anyone out there have a 
>different solution? If so, then I would like to hear from you. Please 
>send/post any general comments on the above scheme you might have as well. 
> 
>                    Don Jennings, COSSC/GSFC 

If that last byte is important, than it will be important regardless of what
computer you're analyzing the data on.  If so, then a better, more
machine-independent way of transferring the full significance of the data has
to be devised.  If it isn't important, then one shouldn't worry about it.

Bill Thompson
Newsgroups: sci.astro
From: mje@pookie.pass.wayne.edu (Michael J. Edelman)
Subject: Re: Buying mail-order from camera stores
Reply-To: mje@pookie.pass.wayne.edu
Organization: Wayne State University
Distribution: usa
Date: Thu, 17 Dec 1992 13:14:19 GMT

In article 9576@hplabsz.hpl.hp.com, dsmith@hplabsz.hpl.hp.com (David R. Smith) writes:
>We have heard some horror stories about buying astronomical stuff from New
>York camera stores, among others.  Does anyone have an opinion on Shutan
>Camera and Video in Chicago?  They sent me a catalog, presumably from
>borrowing Sky & Tel's mailing list.  Their 20% off sale on TeleVue eyepieces
>looks tempting.
>
I never ordered from Shutan, but I came close. They were extremely helpful
on the phone when I was interested in a Teleview Oracle.

There seems to be a difference in Chicago camera store culture and NYC camera 
store culture. I dealt with Calumet in Chicago for years for camera gear and
never had a complaint.

           --mike
From: DAVID_JOHNSON@cpsnet2.cps.edu
Newsgroups: sci.astro
Subject: Earth's orbit if no other planets
Date: 18 Dec 1992 01:39:21 -0600
Organization: UTexas Mail-to-News Gateway
NNTP-Posting-Host: cs.utexas.edu

Thanks to all who have responded to my question regarding the Earth's
orbit and if it would change if the other planets were removed (or
hadn't formed in the first place).  The various responses received
through both the net news and by email will be very useful in my
argument.  Hopefully my friend will see the "error of his ways". :-)

(On an aside to the respondent who suggested that I was blasting my
friend for his "beliefs"...I wasn't.  We started the conversation as a
topical discussion, no personal beliefs were insulted or belittled. 
Just a nice friendly argument! :-] )
Newsgroups: sci.astro
From: tg@cs.toronto.edu (Tom Glinos)
Subject: Digital Setting Circles
Organization: Department of Computer Science, University of Toronto
Distribution: na
Date: 14 Dec 92 22:04:04 GMT


The holidays are fast approaching and, well, you know the rest...:-)
A few questions on these little devices.

(1) The Lumicon, JMI, and Celestron (possibly others?) "look" like the
same unit suggesting a common manufacturer. Is this the case? If so
what differentiates the sellers/units other than price?

(2) Are there units out there that use "higer" resolution encoders
than the 4k pulse ones? For visual use, these units would be fine, but
if you want to use a narrow field device like a CCD, then I don't think
these units would be appropriate.

(3) Do the RS232 ports on the "top of the line" models do anything
usefull?
-- 
=================
No regrets, ever!			| Tom Glinos @ U of Toronto Statistics
For down that path, lies madness	| tg@utstat.toronto.edu
Newsgroups: sci.astro