<html>
<head>
</head>
<body style="margin-right: 4px; font-weight: normal; font-size: 12pt; margin-bottom: 1px; font-style: normal; margin-left: 4px; font-variant: normal; font-family: Lucida Grande; line-height: normal; margin-top: 4px">
<p style="margin-bottom: 0; margin-top: 0">
<font face="Lucida Grande" size="3">Operator precedence is not even clear to programmers, let alone to users. Many people think that in C && and || have the same precedence which is not true. Therefore compilers give a warning when using them together without parentheses.</font> </p>
<p style="margin-bottom: 0; margin-top: 0">
<font face="Lucida Grande" size="3">Yet, I prefer operators to functions because they are less verbose and more natural. I agree with Walter that parsing is quite straightforward when using tools like bison/flex. I assume similar tools exist in the Java world.</font> </p>
<br>
<p style="margin-bottom: 0; margin-top: 0">
<font face="Lucida Grande" size="3">I think the query must be written like</font> </p>
<p style="margin-bottom: 0; margin-top: 0">
<font face="Lucida Grande" size="3">     IN_UNIT(M, "solmass") < 10</font> </p>
<p style="margin-bottom: 0; margin-top: 0">
<font face="Lucida Grande" size="3">because the unit of M has to be converted to solmass (you know 10 is specified as solmass).</font> </p>
<br>
<p style="margin-bottom: 0; margin-top: 0">
<font face="Lucida Grande" size="3">Some time ago I've had some discussion with Markus about units. Unlike Markus I prefer to write the query like</font> </p>
<p style="margin-bottom: 0; margin-top: 0">
<font face="Lucida Grande" size="3"> M < 10 solmass</font> </p>
<p style="margin-bottom: 0; margin-top: 0">
<font face="Lucida Grande" size="3">Quotes are needed for composite units like</font> </p>
<p style="margin-bottom: 0; margin-top: 0">
<font face="Lucida Grande" size="3"> velocity < 3 'km/h'</font><br><font face="Lucida Grande" size="3">In such grammar the unit specification is unambiguous and easy to parse (I've done that in TaQL). I find it more natural and less confusing, because that's the way we express it in normal language. I think it also easier to write.</font> </p>
<p style="margin-bottom: 0; margin-top: 0">
<font face="Lucida Grande" size="3">I understood that ADQL is parsed and rewritten, so in principle such syntax is possible.</font> </p>
<br>
<p style="margin-bottom: 0; margin-top: 0">
<font face="Lucida Grande" size="3">Cheers,</font> </p>
<p style="margin-bottom: 0; margin-top: 0">
<font face="Lucida Grande" size="3">Ger</font> </p>
<p style="margin-bottom: 0; margin-top: 0">
<br>
>>> Walter Landry <wlandry@caltech.edu> 6/10/2015 10:39 AM >>><br>Markus Demleitner <msdemlei@ari.uni-heidelberg.de> wrote:<br>> Hi Walter,<br>><br>> On Tue, Jun 09, 2015 at 04:53:26PM -0700, Walter Landry wrote:<br>>> 2) I do not understand the syntax for IN_UNIT().  Shouldn't there be<br>>>    three arguments (value, units_from, units_to) and not two?<br>><br>> No, the whole point is that query writers don't have to assume units<br>> in the query but let the database (or rather the translation layer)<br>> work it out for them.<br>><br>> There are two reasons I've proposed this:<br>><br>> (1) people get unit conversions wrong all the time, and the computer<br>> is much better reliably tracing units than humans are; also, it helps<br>> writing a bit more generic queries<br>><br>> (2) if people do manual unit conversions, there's no way a computer<br>> can reliably figure out the new unit, so your metadata is hosed.<br>><br>> To satisfy both cases, it really needs to be a two-arg function.<br><br>Now I am really confused.  If I, as a query writer, want to find all<br>stars with mass M < 10*solMass, would I write<br><br>  M < IN_UNIT(10,"solMass")<br><br>or<br><br>  IN_UNIT(M,"solMass") < 10<br><br>>> 4) Can we put the math and trig functions into the optional<br>>>    components?  Most of them are not implemented in sqlite.<br>><br>> ...but they're reasonably easy to retrofit, no?  In general, I'm<br>> against optional features, as they are a big liability on<br>> clients/users (that have to figure out where they are available).<br>> The code for adding trig to sqlite only needs to be written once, on<br>> the other hand (probably already has several times).<br><br>After a little wandering through the internet, I found<br><br>  <a href="http://sqlite.org/contrib/download/extension-functions.c?get=25">http://sqlite.org/contrib/download/extension-functions.c?get=25</a><br><br>which implements most of these functions.  A little more work for me<br>(grumble, grumble), but not so bad.<br><br>>> 5) Why are we making new function names BIT_AND, BIT_OR, etc?  Why not<br>>>    just use the operators?  It is what everyone but Oracle and<br>>>    Informix implement, and they use different names anyway.<br>><br>> ...but operators are harder to parse (precedence!  Left-recursive<br>> rules!), and it's easier for a machine to go from prefix notation to<br>> infix than the other way round.  I'm all for functions.<br><br>We have to parse the operators anyway.  And it is really not<br>that hard.<br><br>Cheers,<br>Walter Landry<br>
</p>
</body>
</html>