cgp at star.le.ac.uk
Mon Feb 9 00:54:36 PST 2004
On Sat, 7 Feb 2004, Martin Hill wrote:
> There is a small inconsistency between XMatch and Region. Because the Region is
> a single 'search function' with all its parameters included inside the brackets,
> it's straightforward for the backend to optimise the SQL. However the XMatch
> one is a function, of the form:
> XMatch(table1, table2) < sigma
I think there's more than a small inconsistency. I don't understand,
myself, how to implement XMATCH as currently defined. Surely you need to
know the value of sigma before you can work out which sources in table1
will match to those in table2 (to compute the maximum position offsets)?
If so, it would be better (well essential) to have the sigma value as one
of the parameters of the function, e.g.
XMATCH(sigma, table1, table2)
I'm not sure, actually, whether "sigma" presumably meaning some multiplier
of standard error, is the right thing to use. It assumes that our errors
are always Gaussian. Some sort of probability or likelihood would be more
appropriate, wouldn't it?
I suppose the main advantage of sigma as a probability measure is its
simplicty (e.g. with a 3-sigma result you can write a conference paper, a
5-sigma one means you can try to get something in a refereed journal)
while the corresponding likelihood values (assuming a Gaussian
distribution) have lots of zeros in them and are harder to remember.
It's not clear that the same advantage applies here.
Dept of Physics & Astronomy,
University of Leicester,
Leicester, LE1 7RH, U.K.
More information about the voql