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.
-- Clive Page Dept of Physics & Astronomy, University of Leicester, Leicester, LE1 7RH, U.K.Received on 2004-02-09Z09:54:40