ADQL MOD

[Patrick Dowler]

Oh, I agree that the argument order is simply a bug/erratum for ADQL;
clients and services are probably lucky to have not read the spec
carefully :-)

For the treatment of negative args, I would have thought the
mathematical definition is clear (As Marco said: A%B=R is valid with R
having the same sign as A). That should probably be specified clearly
and test results (Cosmopterix) would be useful to tell implementers
whether they have to do something.

On 6 July 2016 at 14:20, Mark Taylor <M.B.Taylor at bristol.ac.uk> wrote:
> 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/



-- 
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada