XOR operator

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

XOR operator

Alex Henrie
Dear SQLite developers,

I wanted to use the XOR operator in a query today, but then found out
that SQLite doesn't support it. MySQL and Microsoft SQL both have XOR.
Would you consider adding it to SQLite too?

-Alex
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: XOR operator

Clemens Ladisch
Alex Henrie wrote:
> I wanted to use the XOR operator in a query today, but then found out
> that SQLite doesn't support it.

For boolean values, "a XOR b" = "a <> b".
For binary values, "a XOR b" = "(a | b) - (a & b)".


Regards,
Clemens
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: XOR operator

nomad
On Fri Oct 06, 2017 at 09:28:08AM +0200, Clemens Ladisch wrote:
>
> For boolean values, "a XOR b" = "a <> b".

Is the <> operator documented somewhere? I can't find it in either of
these places:

    https://sqlite.org/search?s=d&q=%3C%3E
    https://sqlite.org/datatype3.html#comparison_expressions

> For binary values, "a XOR b" = "(a | b) - (a & b)".

The intention of the XOR is much clearer than the expansion, and easier
to write because of the precedence of '-', and ... I can only second
the feature request.

--
Mark Lawrence
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: XOR operator

Rowan Worth-2
On 6 October 2017 at 15:42, <[hidden email]> wrote:

> On Fri Oct 06, 2017 at 09:28:08AM +0200, Clemens Ladisch wrote:
> >
> > For boolean values, "a XOR b" = "a <> b".
>
> Is the <> operator documented somewhere? I can't find it in either of
> these places:
>

<> is SQL for "not equal to" (shout out to all the BASIC fans). It's
documented here:
https://sqlite.org/lang_expr.html#binaryops

-Rowan
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: XOR operator

Simon Slavin-3


On 6 Oct 2017, at 9:12am, Rowan Worth <[hidden email]> wrote:

> On 6 October 2017 at 15:42, <[hidden email]> wrote:
>
>> On Fri Oct 06, 2017 at 09:28:08AM +0200, Clemens Ladisch wrote:
>>>
>>> For boolean values, "a XOR b" = "a <> b".
>>
>> Is the <> operator documented somewhere? I can't find it in either of
>> these places:
>
> <> is SQL for "not equal to" (shout out to all the BASIC fans). It’s documented here:
> https://sqlite.org/lang_expr.html#binaryops

That page says that '<>' means 'non-equals'.  This is not the same as the binary operation 'XOR' since 'non-equals' can yield only two values: true and false.  Experimentation shows …

sqlite> SELECT 11 = 19;
0
sqlite> SELECT 11 <> 19;
1
sqlite> SELECT 11 | 19;
27
sqlite> SELECT 11 & 19;
3

… that even for binary values the documentation is correct and that '<>' does not mean 'XOR'.  However, '&' and '|' and '<<' and '>>' do not seem to be defined, either there or in

<https://www.sqlite.org/datatype3.html#operators>

I can’t find anywhere in SQLite’s own documentation that defines them.  Perhaps this should be remedied.

Simon.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: XOR operator

Andy Ling-2
On 6 Oct 2017, at 9:12am, Rowan Worth <[hidden email]> wrote:

> On 6 October 2017 at 15:42, <[hidden email]> wrote:
>
>> On Fri Oct 06, 2017 at 09:28:08AM +0200, Clemens Ladisch wrote:
>>>
>>> For boolean values, "a XOR b" = "a <> b".
>>
>> Is the <> operator documented somewhere? I can't find it in either of
>> these places:
>
> <> is SQL for "not equal to" (shout out to all the BASIC fans). It’s documented here:
> https://sqlite.org/lang_expr.html#binaryops

>That page says that '<>' means 'non-equals'.  This is not the same as the binary operation 'XOR' since 'non-equals' can yield only two values: true >and false.

Clemens said "For boolean values" So if a and b are limited to the values 0 & 1 not equals is the same as XOR.

sqlite> SELECT 0 <> 0;
0
sqlite> SELECT 0 <> 1;
1
sqlite> SELECT 1 <> 0;
1
sqlite> SELECT 1 <> 1;
0

Andy Ling

 
---------------------------------------------------------------------------------------
This email has been scanned for email related threats and delivered safely by Mimecast.
For more information please visit http://www.mimecast.com
---------------------------------------------------------------------------------------

_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: XOR operator

Darko Volaric
In reply to this post by Simon Slavin-3


> However, '&' and '|' and '<<' and '>>' do not seem to be defined, either there or in

Almost none of the operators are defined. All that section needs is a sentence at the start saying "The operators have the same meaning as ANSI C except as described below."



> On Oct 6, 2017, at 11:31 AM, Simon Slavin <[hidden email]> wrote:
>
>
>
> On 6 Oct 2017, at 9:12am, Rowan Worth <[hidden email]> wrote:
>
>> On 6 October 2017 at 15:42, <[hidden email]> wrote:
>>
>>> On Fri Oct 06, 2017 at 09:28:08AM +0200, Clemens Ladisch wrote:
>>>>
>>>> For boolean values, "a XOR b" = "a <> b".
>>>
>>> Is the <> operator documented somewhere? I can't find it in either of
>>> these places:
>>
>> <> is SQL for "not equal to" (shout out to all the BASIC fans). It’s documented here:
>> https://sqlite.org/lang_expr.html#binaryops
>
> That page says that '<>' means 'non-equals'.  This is not the same as the binary operation 'XOR' since 'non-equals' can yield only two values: true and false.  Experimentation shows …
>
> sqlite> SELECT 11 = 19;
> 0
> sqlite> SELECT 11 <> 19;
> 1
> sqlite> SELECT 11 | 19;
> 27
> sqlite> SELECT 11 & 19;
> 3
>
> … that even for binary values the documentation is correct and that '<>' does not mean 'XOR'.  However, '&' and '|' and '<<' and '>>' do not seem to be defined, either there or in
>
> <https://www.sqlite.org/datatype3.html#operators>
>
> I can’t find anywhere in SQLite’s own documentation that defines them.  Perhaps this should be remedied.
>
> Simon.
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: XOR operator

R Smith
In reply to this post by Simon Slavin-3

On 2017/10/06 11:31 AM, Simon Slavin wrote:

> On 6 Oct 2017, at 9:12am, Rowan Worth <[hidden email]> wrote:
> On 6 October 2017 at 15:42, <[hidden email]> wrote:
> On Fri Oct 06, 2017 at 09:28:08AM +0200, Clemens Ladisch wrote:
>>>> For boolean values, "a XOR b" = "a <> b".
>>> Is the <> operator documented somewhere? I can't find it in either of
>>> these places:
>> <> is SQL for "not equal to" (shout out to all the BASIC fans). It’s documented here:
>> https://sqlite.org/lang_expr.html#binaryops
> That page says that '<>' means 'non-equals'.  This is not the same as the binary operation 'XOR' since 'non-equals' can yield only two values: true and false.  Experimentation shows …
>
> sqlite> SELECT 11 = 19;
> 0
> sqlite> SELECT 11 <> 19;
> 1
> sqlite> SELECT 11 | 19;
> 27
> sqlite> SELECT 11 & 19;
> 3

He did say "Boolean" XOR, the tests above are for Binary (as in base-2
arithmetic, not 2-sided equations) XOR.  He did give a formula for
Binary XOR, which does work.

I agree the documentation could be clearer and it would be nice to have
an XOR operator in the way that & and | work...  Is there any character
left to use, or one that are regularly used as XOR in other languages? 
The $ sign seems to be free, but it would be nice to conform to some
standard. Perhaps a combined "<|" or such.

I'd also like to see a Unary NOT operator, such that you can say: a = !b
But, I guess that's only feasible in a strongly typed language.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: XOR operator

Richard Hipp-3
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

> But, I guess that's only feasible in a strongly typed language.

(1) I object to the characterization of SQLite not being "strongly
typed".  SQLite is "flexibly typed" in the sense that it provides the
application with a lot of flexibility with regard to what datatypes
are allowed to be stored in a particular column or participate in an
operation.  Other SQL database engines are "rigidly typed".  Those
other SQL implementations are much more judgmental about what you can
and cannot do with your data.

(2) Why is rigid typing required in order to implement boolean negation?
--
D. Richard Hipp
[hidden email]
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: XOR operator

Alex Henrie
In reply to this post by Clemens Ladisch
2017-10-06 1:28 GMT-06:00 Clemens Ladisch <[hidden email]>:
> Alex Henrie wrote:
>> I wanted to use the XOR operator in a query today, but then found out
>> that SQLite doesn't support it.
>
> For boolean values, "a XOR b" = "a <> b".
> For binary values, "a XOR b" = "(a | b) - (a & b)".

Thank you, I had forgotten that exclusive-or is equivalent to
not-equals for boolean values. Still, it would be a little nicer if I
could write a == b XOR c == d instead of (a == b) != (c == d). It
would be even more readable for non-boolean values: a XOR b instead of
(NOT NOT a) != (NOT NOT b).

Anyway, thanks for the help. I'd love to see boolean XOR in SQLite,
but if not, at least I have a solution now.

-Alex
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: XOR operator

Jens Alfke-2


> On Oct 6, 2017, at 9:25 AM, Alex Henrie <[hidden email]> wrote:
>
> Still, it would be a little nicer if I
> could write a == b XOR c == d instead of (a == b) != (c == d).

You can easily implement an “xor(a, b)” function in C. It’s maybe 20 lines of code including registering it.

—Jens
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: XOR operator

R Smith
In reply to this post by Richard Hipp-3
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.

i.e. 0xA (base16) = 1010 (base2) so that NOT 0xA = 0101 = 0x5... so if a
= 0xA then !a = 0x5, but that only works IF we are restricted to "a"
being 1 byte in size, which brings us to the following point:

>
>> But, I guess that's only feasible in a strongly typed language.
> (1) I object to the characterization of SQLite not being "strongly
> typed".  SQLite is "flexibly typed" in the sense that it provides the
> application with a lot of flexibility with regard to what datatypes
> are allowed to be stored in a particular column or participate in an
> operation.  Other SQL database engines are "rigidly typed".  Those
> other SQL implementations are much more judgmental about what you can
> and cannot do with your data.
>
> (2) Why is rigid typing required in order to implement boolean negation?

Answering (2): A strongly typed language that defines
INT/UINT/WORD/INT64/etc. as specifically a 32-bit or 64-bit
signed/unsigned representation, or "Byte" as a 8-bit unsigned
representation will be sensible to say a = not b; where a and b are both
typed as BYTE values. but if you don't know how many bits are "meant" to
be in "a", how to determine how many bits must be negated / "notted" /
changed to produce the result of "NOT b" in the way described up there.

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.

It's often used in masking bit flag sequences. a = (a & !0x3) would see
"a" being switched so that it's LSB's 0 and 1 gets switched off while
leaving the others in tact. Yes, I could have just said a = (a & (0xFF -
0x03)) or even work out what that result is and go a = (a & 0xFC), but
if the bits that get switched off lives in a variable (b), then a = (a &
!b) is just so much more sensible / elegant. I'm even ok with syntax
like a = (a & (not b))... but that's not how SQLite works, or can work,
unless it becomes strongly typed.


As to (1)... Cool, call it flexibly typed then, I'm ambivalent to the
terminology, my point is about the variable sizes not being set in stone.


_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: XOR operator

Roman Fleysher
The point is that terminology is chosen for a reason and can not be dismissed. "Flexibly typed" means it is typed. It means SQLite knows how many bytes: without knowing it would not be able to establish equality "IS".  Flexibly means columns can contain values of mixed types,  but each value still has a type. And this is a very very big advantage of SQLite.

Perhaps longer term is "flexibly strongly typed". Perhaps because "typed" implies "strongly" (what is a weak type?), strongly is redundant.

Roman




-------- Original message --------
From: R Smith <[hidden email]>
Date: 10/8/17 9:38 AM (GMT-05:00)
To: [hidden email]
Subject: Re: [sqlite] XOR operator

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.

i.e. 0xA (base16) = 1010 (base2) so that NOT 0xA = 0101 = 0x5... so if a
= 0xA then !a = 0x5, but that only works IF we are restricted to "a"
being 1 byte in size, which brings us to the following point:

>
>> But, I guess that's only feasible in a strongly typed language.
> (1) I object to the characterization of SQLite not being "strongly
> typed".  SQLite is "flexibly typed" in the sense that it provides the
> application with a lot of flexibility with regard to what datatypes
> are allowed to be stored in a particular column or participate in an
> operation.  Other SQL database engines are "rigidly typed".  Those
> other SQL implementations are much more judgmental about what you can
> and cannot do with your data.
>
> (2) Why is rigid typing required in order to implement boolean negation?

Answering (2): A strongly typed language that defines
INT/UINT/WORD/INT64/etc. as specifically a 32-bit or 64-bit
signed/unsigned representation, or "Byte" as a 8-bit unsigned
representation will be sensible to say a = not b; where a and b are both
typed as BYTE values. but if you don't know how many bits are "meant" to
be in "a", how to determine how many bits must be negated / "notted" /
changed to produce the result of "NOT b" in the way described up there.

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.

It's often used in masking bit flag sequences. a = (a & !0x3) would see
"a" being switched so that it's LSB's 0 and 1 gets switched off while
leaving the others in tact. Yes, I could have just said a = (a & (0xFF -
0x03)) or even work out what that result is and go a = (a & 0xFC), but
if the bits that get switched off lives in a variable (b), then a = (a &
!b) is just so much more sensible / elegant. I'm even ok with syntax
like a = (a & (not b))... but that's not how SQLite works, or can work,
unless it becomes strongly typed.


As to (1)... Cool, call it flexibly typed then, I'm ambivalent to the
terminology, my point is about the variable sizes not being set in stone.


_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: XOR operator

Peter da Silva
Generally, when you talk about whether a language is strongly or weakly typed, you're talking about the storage, not the content.

Pretty much every "weakly typed" language out there (there are a few exceptions, like Tcl) does have fully typed values. In many cases you can even interrogate the value with a "type of" operator. They just have storage locations (variables, array elements, hash targets) that can hold any type.

SQLite is, in common terminology, weakly typed.

> On 2017-10-08, at 08:56, Roman Fleysher <[hidden email]> wrote:
>
> The point is that terminology is chosen for a reason and can not be dismissed. "Flexibly typed" means it is typed. It means SQLite knows how many bytes: without knowing it would not be able to establish equality "IS".  Flexibly means columns can contain values of mixed types,  but each value still has a type. And this is a very very big advantage of SQLite.
>
> Perhaps longer term is "flexibly strongly typed". Perhaps because "typed" implies "strongly" (what is a weak type?), strongly is redundant.
>
> Roman
>
>
>
>
> -------- Original message --------
> From: R Smith <[hidden email]>
> Date: 10/8/17 9:38 AM (GMT-05:00)
> To: [hidden email]
> Subject: Re: [sqlite] XOR operator
>
> 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.
>
> i.e. 0xA (base16) = 1010 (base2) so that NOT 0xA = 0101 = 0x5... so if a
> = 0xA then !a = 0x5, but that only works IF we are restricted to "a"
> being 1 byte in size, which brings us to the following point:
>
>>
>>> But, I guess that's only feasible in a strongly typed language.
>> (1) I object to the characterization of SQLite not being "strongly
>> typed".  SQLite is "flexibly typed" in the sense that it provides the
>> application with a lot of flexibility with regard to what datatypes
>> are allowed to be stored in a particular column or participate in an
>> operation.  Other SQL database engines are "rigidly typed".  Those
>> other SQL implementations are much more judgmental about what you can
>> and cannot do with your data.
>>
>> (2) Why is rigid typing required in order to implement boolean negation?
>
> Answering (2): A strongly typed language that defines
> INT/UINT/WORD/INT64/etc. as specifically a 32-bit or 64-bit
> signed/unsigned representation, or "Byte" as a 8-bit unsigned
> representation will be sensible to say a = not b; where a and b are both
> typed as BYTE values. but if you don't know how many bits are "meant" to
> be in "a", how to determine how many bits must be negated / "notted" /
> changed to produce the result of "NOT b" in the way described up there.
>
> 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.
>
> It's often used in masking bit flag sequences. a = (a & !0x3) would see
> "a" being switched so that it's LSB's 0 and 1 gets switched off while
> leaving the others in tact. Yes, I could have just said a = (a & (0xFF -
> 0x03)) or even work out what that result is and go a = (a & 0xFC), but
> if the bits that get switched off lives in a variable (b), then a = (a &
> !b) is just so much more sensible / elegant. I'm even ok with syntax
> like a = (a & (not b))... but that's not how SQLite works, or can work,
> unless it becomes strongly typed.
>
>
> As to (1)... Cool, call it flexibly typed then, I'm ambivalent to the
> terminology, my point is about the variable sizes not being set in stone.
>
>
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: XOR operator

R Smith
In reply to this post by Roman Fleysher
On 2017/10/08 3:56 PM, Roman Fleysher wrote:
> The point is that terminology is chosen for a reason and can not be dismissed. "Flexibly typed" means it is typed. It means SQLite knows how many bytes: without knowing it would not be able to establish equality "IS".  Flexibly means columns can contain values of mixed types,  but each value still has a type. And this is a very very big advantage of SQLite.
>
> Perhaps longer term is "flexibly strongly typed". Perhaps because "typed" implies "strongly" (what is a weak type?), strongly is redundant.

The first paragraph is just not true.

The second one alludes to why the misunderstanding exists. Perhaps a
quick browse through the meanings of "weak" and "strong" typing would
clear that up. My quick google attempts yield:
http://wiki.c2.com/?WeakAndStrongTyping
https://en.wikipedia.org/wiki/Strong_and_weak_typing
http://www.i-programmer.info/programming/theory/1469-type-systems-demystified-part2-weak-vs-strong.html
https://en.wikipedia.org/wiki/Duck_typing

To be clear, I wasn't disagreeing with Richard on his point of naming it
"Flexibly strong typed", and my notion of "strongly typed language"
perhaps gave the impression that I thought the opposite of SQLite (i.e.
that is "weakly" typed), which isn't the case - I think it's closer to
Duck Typing (see the last link above). Most scripting languages prefer
the weakly typed model (maybe I should be careful and say "lean towards
the weakly typed model" rather), and most compiler languages lean
towards strongly typed. That isn't to say there's no confluence or
bridge-crossing, there is in fact a lot.

SQLite's typing system is great, but you can't tell me for certain the
predicted size of a column of integers. Some will take less bits than
others, based on the value of the actual Integer. Inside functions
SQlite will try interpret strings as numbers if the function expects a
number and vice versa - very useful, but the very definition of weakly
(read: Dynamically) typed languages. In other instances, SQLite behaves
much more like strongly/statically typed language needing a CAST() to
correctly handle values and the like.

Either way, a unary value-based NOT operator is not feasible because the
bit-size of an Integer value is not predetermined or specified. Unless
maybe it always returns a 64-bit value.


_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: XOR operator

Simon Slavin-3
On 8 Oct 2017, at 3:55pm, R Smith <[hidden email]> wrote:

> SQLite's typing system is great, but you can't tell me for certain the predicted size of a column of integers. Some will take less bits than others, based on the value of the actual Integer. Inside functions SQlite will try interpret strings as numbers if the function expects a number and vice versa - very useful, but the very definition of weakly (read: Dynamically) typed languages. In other instances, SQLite behaves much more like strongly/statically typed language needing a CAST() to correctly handle values and the like.

I agree with everybody.  SQLite is unusual in two ways: it is a weakly typed language but one which allows (and requires) CAST.  And also it uses different amounts of storage to store different numbers.

The second one isn’t as weird as it looks when you consider other languages use different amounts of storage to store different strings.

Meanwhile we do seem to have dealt with the concerns of the original poster.  There’s no binary XOR in SQLite.  Clemens Ladisch posted a simple alternative:

> For binary values, "a XOR b" = "(a | b) - (a & b)".

Simon.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: XOR operator

Clemens Ladisch
In reply to this post by R Smith
R Smith wrote:
> I meant a binary operation, not a Boolean operation NOT.

"NOT X" = "-X - 1"

> Answering (2): A strongly typed language that defines INT/UINT/WORD/
> INT64/etc. as specifically a 32-bit or 64-bit signed/unsigned
> representation, or "Byte" as a 8-bit unsigned representation will be
> sensible to say a = not b; where a and b are both typed as BYTE values.
> but if you don't know how many bits are "meant" to be in "a", how to
> determine how many bits must be negated / "notted" / changed to produce
> the result of "NOT b" in the way described up there.
>
> 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.

In SQLite, all integers are signed 64-bit values.

> It's often used in masking bit flag sequences. a = (a & !0x3) would
> see "a" being switched so that it's LSB's 0 and 1 gets switched off
> while leaving the others in tact.

When clearing bits, the additional bits in the mask do not matter:

  SELECT printf("%#x", 0xaf & (-0x03-1));
  0xac


Regards,
Clemens
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: XOR operator

Keith Medcalf
In reply to this post by R Smith

I do not see the problem.  A binary "NOT" operator simply inverts each and every bit and that only works on (unsigned/uncomplemented) bitfields.  The "binary NOT" operator to work on signed/complemented bitfields is called "COMPLEMENT" and is an entirely different beastly.

So you read the data using whatever API you want, padded (on the left) with as many 0 bits as you feel like having (perhaps based on the phase of the moon or something -- programmers amongst us would probably choose the native wordlength or something).  Invert all the bits one by each, then put the data back whence it came without further ado.

If the "coder" did not know what they are doing and get confused by the "Sign" bit, then that is their problem.  That is the difference between "programmers" and mere "coders".  Real programmers do not no stinking compiler globbedy glook that needs working around at every turn in order to do that which is needful (to use a quaint indian expression).

---
The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.


>-----Original Message-----
>From: sqlite-users [mailto:sqlite-users-
>[hidden email]] On Behalf Of R Smith
>Sent: Sunday, 8 October, 2017 07:38
>To: [hidden email]
>Subject: Re: [sqlite] XOR operator
>
>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.
>
>i.e. 0xA (base16) = 1010 (base2) so that NOT 0xA = 0101 = 0x5... so
>if a
>= 0xA then !a = 0x5, but that only works IF we are restricted to "a"
>being 1 byte in size, which brings us to the following point:
>
>>
>>> But, I guess that's only feasible in a strongly typed language.
>> (1) I object to the characterization of SQLite not being "strongly
>> typed".  SQLite is "flexibly typed" in the sense that it provides
>the
>> application with a lot of flexibility with regard to what datatypes
>> are allowed to be stored in a particular column or participate in
>an
>> operation.  Other SQL database engines are "rigidly typed".  Those
>> other SQL implementations are much more judgmental about what you
>can
>> and cannot do with your data.
>>
>> (2) Why is rigid typing required in order to implement boolean
>negation?
>
>Answering (2): A strongly typed language that defines
>INT/UINT/WORD/INT64/etc. as specifically a 32-bit or 64-bit
>signed/unsigned representation, or "Byte" as a 8-bit unsigned
>representation will be sensible to say a = not b; where a and b are
>both
>typed as BYTE values. but if you don't know how many bits are "meant"
>to
>be in "a", how to determine how many bits must be negated / "notted"
>/
>changed to produce the result of "NOT b" in the way described up
>there.
>
>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.
>
>It's often used in masking bit flag sequences. a = (a & !0x3) would
>see
>"a" being switched so that it's LSB's 0 and 1 gets switched off while
>leaving the others in tact. Yes, I could have just said a = (a &
>(0xFF -
>0x03)) or even work out what that result is and go a = (a & 0xFC),
>but
>if the bits that get switched off lives in a variable (b), then a =
>(a &
>!b) is just so much more sensible / elegant. I'm even ok with syntax
>like a = (a & (not b))... but that's not how SQLite works, or can
>work,
>unless it becomes strongly typed.
>
>
>As to (1)... Cool, call it flexibly typed then, I'm ambivalent to the
>terminology, my point is about the variable sizes not being set in
>stone.
>
>
>_______________________________________________
>sqlite-users mailing list
>[hidden email]
>http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users



_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: XOR operator

Keith Medcalf
In reply to this post by R Smith

>Answering (2): A strongly typed language that defines
>INT/UINT/WORD/INT64/etc. as specifically a 32-bit or 64-bit
>signed/unsigned representation, or "Byte" as a 8-bit unsigned
>representation will be sensible to say a = not b; where a and b are both
>typed as BYTE values. but if you don't know how many bits are "meant" to
>be in "a", how to determine how many bits must be negated / "notted" /
>changed to produce the result of "NOT b" in the way described up there.

>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?

Though I suppose it would be possible to have both a COMPLEMENT and a NOT operator, they are not the same thing.  I don't think there is any value in having the COMPLEMENT operator (which is probably why it disappeared from most machine instruction sets a couple of decades ago) since you will not that there is not a special set of AND / OR operators to deal with idjit coders who do not know what they are doing with the sign bit.

Why are you introducing problems and issues that simply do not exist in the real world?  (and if they do you need to hire a programmer rather than a $3.99/hour coder).

---
The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.


>-----Original Message-----
>From: sqlite-users [mailto:sqlite-users-
>[hidden email]] On Behalf Of R Smith
>Sent: Sunday, 8 October, 2017 07:38
>To: [hidden email]
>Subject: Re: [sqlite] XOR operator
>
>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.
>
>i.e. 0xA (base16) = 1010 (base2) so that NOT 0xA = 0101 = 0x5... so
>if a
>= 0xA then !a = 0x5, but that only works IF we are restricted to "a"
>being 1 byte in size, which brings us to the following point:
>
>>
>>> But, I guess that's only feasible in a strongly typed language.
>> (1) I object to the characterization of SQLite not being "strongly
>> typed".  SQLite is "flexibly typed" in the sense that it provides
>the
>> application with a lot of flexibility with regard to what datatypes
>> are allowed to be stored in a particular column or participate in
>an
>> operation.  Other SQL database engines are "rigidly typed".  Those
>> other SQL implementations are much more judgmental about what you
>can
>> and cannot do with your data.
>>
>> (2) Why is rigid typing required in order to implement boolean
>negation?
>
>Answering (2): A strongly typed language that defines
>INT/UINT/WORD/INT64/etc. as specifically a 32-bit or 64-bit
>signed/unsigned representation, or "Byte" as a 8-bit unsigned
>representation will be sensible to say a = not b; where a and b are
>both
>typed as BYTE values. but if you don't know how many bits are "meant"
>to
>be in "a", how to determine how many bits must be negated / "notted"
>/
>changed to produce the result of "NOT b" in the way described up
>there.
>
>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.
>
>It's often used in masking bit flag sequences. a = (a & !0x3) would
>see
>"a" being switched so that it's LSB's 0 and 1 gets switched off while
>leaving the others in tact. Yes, I could have just said a = (a &
>(0xFF -
>0x03)) or even work out what that result is and go a = (a & 0xFC),
>but
>if the bits that get switched off lives in a variable (b), then a =
>(a &
>!b) is just so much more sensible / elegant. I'm even ok with syntax
>like a = (a & (not b))... but that's not how SQLite works, or can
>work,
>unless it becomes strongly typed.
>
>
>As to (1)... Cool, call it flexibly typed then, I'm ambivalent to the
>terminology, my point is about the variable sizes not being set in
>stone.
>
>
>_______________________________________________
>sqlite-users mailing list
>[hidden email]
>http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users



_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: XOR operator

Keith Medcalf
In reply to this post by Peter da Silva

And the underlying processor has no such thing as a "type" -- it is simply a high level abstraction designed to keep the ill equipped from cutting their hands off by grabbing the wrong end of the knife...


---
The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.


>-----Original Message-----
>From: sqlite-users [mailto:sqlite-users-
>[hidden email]] On Behalf Of Peter Da Silva
>Sent: Sunday, 8 October, 2017 08:40
>To: SQLite mailing list
>Subject: Re: [sqlite] XOR operator
>
>Generally, when you talk about whether a language is strongly or
>weakly typed, you're talking about the storage, not the content.
>
>Pretty much every "weakly typed" language out there (there are a few
>exceptions, like Tcl) does have fully typed values. In many cases you
>can even interrogate the value with a "type of" operator. They just
>have storage locations (variables, array elements, hash targets) that
>can hold any type.
>
>SQLite is, in common terminology, weakly typed.
>
>> On 2017-10-08, at 08:56, Roman Fleysher
><[hidden email]> wrote:
>>
>> The point is that terminology is chosen for a reason and can not be
>dismissed. "Flexibly typed" means it is typed. It means SQLite knows
>how many bytes: without knowing it would not be able to establish
>equality "IS".  Flexibly means columns can contain values of mixed
>types,  but each value still has a type. And this is a very very big
>advantage of SQLite.
>>
>> Perhaps longer term is "flexibly strongly typed". Perhaps because
>"typed" implies "strongly" (what is a weak type?), strongly is
>redundant.
>>
>> Roman
>>
>>
>>
>>
>> -------- Original message --------
>> From: R Smith <[hidden email]>
>> Date: 10/8/17 9:38 AM (GMT-05:00)
>> To: [hidden email]
>> Subject: Re: [sqlite] XOR operator
>>
>> 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.
>>
>> i.e. 0xA (base16) = 1010 (base2) so that NOT 0xA = 0101 = 0x5... so
>if a
>> = 0xA then !a = 0x5, but that only works IF we are restricted to
>"a"
>> being 1 byte in size, which brings us to the following point:
>>
>>>
>>>> But, I guess that's only feasible in a strongly typed language.
>>> (1) I object to the characterization of SQLite not being "strongly
>>> typed".  SQLite is "flexibly typed" in the sense that it provides
>the
>>> application with a lot of flexibility with regard to what
>datatypes
>>> are allowed to be stored in a particular column or participate in
>an
>>> operation.  Other SQL database engines are "rigidly typed".  Those
>>> other SQL implementations are much more judgmental about what you
>can
>>> and cannot do with your data.
>>>
>>> (2) Why is rigid typing required in order to implement boolean
>negation?
>>
>> Answering (2): A strongly typed language that defines
>> INT/UINT/WORD/INT64/etc. as specifically a 32-bit or 64-bit
>> signed/unsigned representation, or "Byte" as a 8-bit unsigned
>> representation will be sensible to say a = not b; where a and b are
>both
>> typed as BYTE values. but if you don't know how many bits are
>"meant" to
>> be in "a", how to determine how many bits must be negated /
>"notted" /
>> changed to produce the result of "NOT b" in the way described up
>there.
>>
>> 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.
>>
>> It's often used in masking bit flag sequences. a = (a & !0x3) would
>see
>> "a" being switched so that it's LSB's 0 and 1 gets switched off
>while
>> leaving the others in tact. Yes, I could have just said a = (a &
>(0xFF -
>> 0x03)) or even work out what that result is and go a = (a & 0xFC),
>but
>> if the bits that get switched off lives in a variable (b), then a =
>(a &
>> !b) is just so much more sensible / elegant. I'm even ok with
>syntax
>> like a = (a & (not b))... but that's not how SQLite works, or can
>work,
>> unless it becomes strongly typed.
>>
>>
>> As to (1)... Cool, call it flexibly typed then, I'm ambivalent to
>the
>> terminology, my point is about the variable sizes not being set in
>stone.
>>
>>
>> _______________________________________________
>> sqlite-users mailing list
>> [hidden email]
>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-
>users
>> _______________________________________________
>> sqlite-users mailing list
>> [hidden email]
>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-
>users
>
>_______________________________________________
>sqlite-users mailing list
>[hidden email]
>http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users



_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
12