Inputs for UCDs [this part: IEEE in ADQL]

[Markus Demleitner]

Hi Stéphane,

On Wed, Oct 09, 2019 at 06:54:56PM +0200, Stéphane Erard wrote:
> Here are some comments I’ve collected since the last Interop
> Meeting about UCDs, in relationship with Planetary Science / coming
> EPNCore standard. 

I'll leave the first comments to the UCD suggestions to Mireille,
who's volunteered as (let me invent a position here) UCD manager for
the time being, but, since you asked:

> + I’m not sure if this is for here, but I also noted:
> • Clarify usage of inf / -inf / Nan in ADQL (should apparently
> exist, as per DALI - but do not)

That's a DAL topic that you probably should bring up there with
concrete use cases and requirements, in particular whether:

(1) ADQL float literals should know about IEEE magic values, so that
you can write "WHERE u<inf" or so?  Me, I doubt there's many credible
use cases for that, in particular because comparisons of magic values
are tricky.  Note, in particular, that NaN!=NaN.  With floats, that's
a distinction of NaN, in ADQL, there's NULL that whould also show
this behaviour, complicating matters a bit (I've recently blogged
about this: https://blog.g-vo.org/adql-traps-1-null/)

(2) ADQL needs at least an isnan operator?  Me, I think that the
semantic difference between SQL NULL and IEEE NaN is so slim that we
probably shouldn't map it in ADQL land.  At least, it's not
maintained in TABLEDATA and BINARY VOTable serialisations, which
would make any possible benefit on the ADQL side questionable.
Hence, I'd say we should discourage having NaNs in float-valued
columns and tell people to have proper NULLs there instead.  Matters
become murkier when ADQL grows actual support for arrays, though.
But let's talk about that when we properly specify arrays.

(3) Just clarify that you may get back IEEE magic values from TAP
queries?  I guess that's more or less implied, except that, as I
said, NaN is not reliably representable in VOTables.  If that's what
you'd like to see, where would you make that clarification?

Whatever it is, would you take this to DAL?

Thanks,

           Markus