On 2017/10/08 11:30 PM, Keith Medcalf wrote:
>> If for example a = 0xA then !a might be 0x5 for a nibble, but it will be
>> 0xF5 for a byte, 0xFFF5 for a WORD, 0xFFFFFF5 for a 32bit INT, etc. etc.
> This is balderdash. There is no such thing as "meant", only "is". And you last sentence is discussing the COMPLEMENT operator, not the NOT operator.
> Cannot we please keep the discussion on topic?
The topic started as a request for an XOR operator. I've added a request
for a NOT operator. Both these are obviously possible by a little
work-around, as has been shown, but the single operator would still
be a nice-to-have.
I'm not sure I interpret correctly, but it seems to me you are saying
that the above description is of a COMPLEMENT operator rather than a NOT
operator, hence it is off-topic.
What would you call an operator that switches all bits in a byte? All
bits that were 0 become 1, and all that were 1 become 0. In my travels I
have come to know this as a NOT operation. If you call it COMPLEMENT
then good luck, but I don't see the relevance of re-issuing the name of
the concept and then calling it off-topic.
I have no interest in a contest of best-name-for-the-thing. Whatever you
would like to call an operation that switches all bits to the opposite
of what they were, that thing was the request. (I am no longer
requesting it btw., in fact the "balderdash" above was in reply to
another post, showing why it probably isn't feasible in SQLite, and this
reply is merely a clarification since a misunderstanding seemed afoot).
 - The signed value thing was discussed by Clemens, offering it as a
work-around to achieve not-ness while compensating for the sign inherent
to signed INTs (used in SQlite) - and it works fine.
> The topic started as a request for an XOR operator. I've added a request for a NOT operator.
SQLite does not have a byte type.
SQLite does not have any fixed-length integer type.
Given those two statements, what should NOT 1100 be ?
Should it be 11 ? Or 11110011 ? Or 1111111111110011 ? If you want to argue that the result should be 1 byte long, you will get the wrong result when you OR two different XOR results together. Are you going to argue that it should be 8 bytes long ? Why should a SQL programmer be expected to know details about how SQL stores numbers internally ?
Having one operator gives you the other. For example,
a XOR b == ( a IOR b ) AND (NOT ( a AND b ))
If you have difficulty in deciding how long the result of NOT should be, you have the same problem in deciding how long XOR should be. Again, deciding it should be one byte long is apparently wrong, but deciding it should be eight bytes long is arbitrary because it depends on an internal detail of SQLite not normally exposed to users.
On 10/8/17, R Smith <[hidden email]> wrote:
> On 2017/10/06 6:03 PM, Richard Hipp wrote:
>> On 10/6/17, R Smith <[hidden email]> wrote:
>>> I'd also like to see a Unary NOT operator, such that you can say: a = !b
>> In SQL and SQLite that would be: a = NOT b
> Apologies, I thought it obvious from the context that I meant a binary
> operation, not a Boolean operation NOT.
On 2017/10/09 3:07 AM, Richard Hipp wrote:
> Then you want: a = ~b
Wow, I missed this, and it works already. Thank you kindly!
May I suggest adding a small section to the binary/unary operators in
the documentation that names each operator and provide a short function
description (at least for those that are not covered already, even the
I never associated the ~ with NOT, and from the replies to this thread
it seems this knowledge may be useful to many.
>On 2017/10/09 3:07 AM, Richard Hipp wrote:
>> Then you want: a = ~b
> Wow, I missed this, and it works already. Thank you kindly!
> May I suggest adding a small section to the binary/unary operators in
> the documentation that names each operator and provide a short function
> description (at least for those that are not covered already, even the
> "obvious" ones)?