[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: TASS Discovers 13 "new" objects, maybe?
I do agree with Herb that I did a real poor job of writing up the
result. This was mostly intentional. My goal was just to see if
the database software worked and by chance I blundered into something
unexpected. The fact that the system allows one to "surf" the data
was the main message the found objects was secondary
I think there are two ways to analyze a big pile of data
(1) select some goal, make a plan, write software. This can be productive
if you have a well defined goal. (2) just look around and try things.
This can be a waste of time or you can get lucky. It can also be a good
way to become educated enough about what is in the data that you can do
method #1. So now I know that there are bright well observed objects
not in Arne's list I can go back and write a small script to extract
them and format the data in some usable way. I've got a long "do to"
list so if someone else want s pick up these objects great. This
data is not publicly available yet so e-mail me if you want some
data.
About Tom's idea that they are red stars. I don't think so. Instrumental
magnitudes are within about 0.5 mag in all filters. I looks
like v-i < 1 Arne's list is cutat V = 16 and goes deeper in B and R, sorry
don't remember the exact numbers. The fact that RA tracks JD is
odd for a star. I would expect a more random shatter.
About the format. The tables were created on the fly. There is no
program that needs to be changed to "correct" the format. As you can
see in the following excerpt I just typed a command at the prompt
"select tass_id ... and tass_id > 10000000;" The query language looks
looks complex but it is not. It is just wordy and requires you to
remember and type the table and column names with exact spelling.
The good point is that you can extract tables from the database on
demand and to your own specification and it is fast enough that you
don't need to save the result, just do it again later.
> >testdb=> select tass_id, ra::float/3600000.0 as ra,
> > dec::float/3600000.0 as dec
> > from tass_cat
> > where obs_count=6 and tass_id > 10000000;
> >
> > tass_id| ra| dec
> >--------+----------------+------------------
> >10003825|2.80183333333333| 1.26503333333333
> >10006686| 4.9697| 1.14985
> >10006736|5.00426666666667| 0.99155
> >10006856|5.09001666666667| 1.20248333333333
<deleted>
Tom Droege wrote:
>
> Chris and all,
>
><deleted>
>
> But we can ask Chris for a human interface. One suitable for Myself and
> others who don't want to get into the details of postgress. Something
> like what Michael has provided. But I don't expect to be able to ask
> complicated questions withoug doing some work on learning the language.
There are a endless "easy" interfaces that could be built. but there are
a few good ones already. Microsoft Office Professional has a pretty good
user interface that allows grabbing data from Postgres and making plots and
tables. Someone who understands MS Visual BASIC could do a custom program
front end program with little work. Then there is the web based approach.
I am more interested in building "server side" tools for now but after we
get this data calibrated I may want to make some light curves.
The language of databases is "SQL". If you only need to look at data, not
update or load it then there is only one SQL statement that is of use
It is the "SELECT" statment. It is pretty simple. In basic form it is just
SELECT <foo> FROM tablename WHERE <bar>
<foo> is a list of expressions like "ra" or "ra/3600000"
<bar> is a "conditional" just like what you would put inside an "IF" statement
in most conventional programming languages i.e. "ra>100 and ra<101".
The above will get 85% of what you want.
--Chris Albertson
chris@topdog.logicon.com Voice: 626-351-0089 X127
Logicon RDA, Pasadena California Fax: 626-351-0699