ADQL MOD

[Mark Taylor]

Pat,

normally I would agree, but in this case it looks like the transposition
of arguments was just a typo in the standard which everybody simply
ignored/didn't read.  Well I'm not sure about everybody, but I've
tested DaCHS, HEASARC, CADC, IPAC, SIMBAD, ASDC, TAPVizieR, ...
and I haven't yet found one that does it the way that ADQL 2.0 says,
they all do it the way that ADQL 2.0 would say if it was following
SQL 2003.  So really I think it would be more disruptive to require
at this stage that services change to fit the standards text rather
than the other way round.  Hence I favour an erratum in this case.

The other issue here brought up by Ger is about behaviour in the
presence of negative arguments.  That is currently not mentioned
at all in the ADQL standard.  I tend to agree with Marco that
that's probably reasonable, though I could be persuaded otherwise.

Mark

On Wed, 6 Jul 2016, Patrick Dowler wrote:

> If a really clear definition is in the standard then users of
> non-compliant back-end DB can/should/must write code to mangle
> ADQL->SQL that returns the correct answer. That's always the case,
> sometimes simple (change function name), sometimes tricky (change
> function usage to operator usage), and in this case maybe swapping
> arguments. In the ADQL standard is especially important than not in
> cases where RDBMS are not consistent, it just isn't free for everyone.
> 
> my 2c,
> 
> Pat
> 
> 
> 
> On 6 July 2016 at 01:49, Marco Molinaro <molinaro at oats.inaf.it> wrote:
> > Hi again,
> > reporting Ger's comment on the  MOD function
> >
> > 2016-07-05 21:25 GMT+02:00 Ger van Diepen <diepen at astron.nl>:
> >> Maybe it should be described what the remainder is in case x and/or y is
> >> negative.
> >> E.g.: x%y gives different results in C and Python for negative numbers.
> >>
> >> Cheers,
> >> Ger
> >
> > I indeed think it is (R)DBMS implementation dependent, maybe one more
> > point to check with Dave's Cosmopterix.
> >
> > A quick search in the SQL standard discussions online seems to point out
> > that A%B=R is valid with R having the same sign as A and ABS(R) being
> > smaller than ABS(B), plus the counter check that A=B*K+R where K is some
> > integer value (out of A/B).
> >
> > Maybe we are lucky and all the RDBMSs we're interested in act this way.
> >
> > I'm not sure, however, that forcing this thing into the standard would be
> > useful. Probably alerting the ADQL users might be enough.
> >
> > Cheers,
> >      Marco
> >
> >
> >>
> >>>>> Marco Molinaro <molinaro at oats.inaf.it> 07/05/16 3:32 PM >>>
> >>
> >> Dear Mark, DAL,
> >> I think this is an erratum, with x and y switched in the description.
> >> Cheers,
> >> Marco
> >>
> >> 2016-07-05 15:25 GMT+02:00 Mark Taylor <M.B.Taylor at bristol.ac.uk>:
> >>> Dear DAL,
> >>>
> >>> table 1 of REC-ADQL-2.0 defines the MOD function thus:
> >>>
> >>> Name Arg type Return type Description
> >>> --------- -------- ----------- -----------
> >>> mod(x, y) double double Returns the remainder of y/x.
> >>>
> >>> but as far as I can see, SQL 2003 (I presume 92 as well) and all
> >>> the TAP services that I generally use define the arguments the other
> >>> way around, i.e. returning the remainder of x/y.
> >>>
> >>> Am I misreading something or is this an erratum candidate?
> >>>
> >>> Mark
> >>>
> >>> --
> >>> Mark Taylor Astronomical Programmer Physics, Bristol University, UK
> >>> m.b.taylor at bris.ac.uk +44-117-9288776 http://www.star.bris.ac.uk/~mbt/
> >>
> 
> 
> 
> -- 
> Patrick Dowler
> Canadian Astronomy Data Centre
> Victoria, BC, Canada
> 

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/