Re: [sqlite] XOR operator

[fredericDelaporte]

R Smith wrote
> 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.

SQL-Server uses ^ for xor, PostgreSQL uses #, Firebird uses a function named
bin_xor, ... In HQL (at least the NHibernate HQL), it uses ^ for xor and by
default output ^ into resulting SQL.



--
Sent from: http://sqlite.1065341.n5.nabble.com/
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] XOR operator

[Kees Nuyt]

On Mon, 9 Oct 2017 13:35:28 +0200, R Smith 
wrote:

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

There's the obsolete wiki FAQ:
https://www.sqlite.org/cvstrac/wiki?p=SqliteWikiFaq
but it misses the ~ operator.

> I never associated the ~ with NOT, and from the replies to this thread 
> it seems this knowledge may be useful to many.
>
>Thanks,
>Ryan
>
>
>___
>sqlite-users mailing list
>sqlite-users@mailinglists.sqlite.org
>http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

-- 
Regards,

Kees Nuyt

___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] XOR operator

[R Smith]

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


I never associated the ~ with NOT, and from the replies to this thread 
it seems this knowledge may be useful to many.


Thanks,
Ryan


___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] XOR operator

[Richard Hipp]

On 10/8/17, R Smith  wrote:
> On 2017/10/06 6:03 PM, Richard Hipp wrote:
>> On 10/6/17, R Smith  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.

Then you want:   a = ~b
-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] XOR operator

[Simon Slavin]

On 9 Oct 2017, at 12:06am, R Smith  wrote:

> 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 0011 ?  Or 0011 ?  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.

Simon.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] XOR operator

[R Smith]

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, 0xFF5 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[1], 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).



Cheers,
$2.99 Coder


[1] - 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.


___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] XOR operator

[Keith Medcalf]

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-
>boun...@mailinglists.sqlite.org] 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
><roman.fleys...@einstein.yu.edu> 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 <rsm...@rsweb.co.za>
>> Date: 10/8/17 9:38 AM (GMT-05:00)
>> To: sqlite-users@mailinglists.sqlite.org
>> Subject: Re: [sqlite] XOR operator
>>
>> On 2017/10/06 6:03 PM, Richard Hipp wrote:
>>> On 10/6/17, R Smith <rsm...@rsweb.co.za> 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, 0xFF5 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 work

Re: [sqlite] XOR operator

[Keith Medcalf]

>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, 0xFF5 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-
>boun...@mailinglists.sqlite.org] On Behalf Of R Smith
>Sent: Sunday, 8 October, 2017 07:38
>To: sqlite-users@mailinglists.sqlite.org
>Subject: Re: [sqlite] XOR operator
>
>On 2017/10/06 6:03 PM, Richard Hipp wrote:
>> On 10/6/17, R Smith <rsm...@rsweb.co.za> 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, 0xFF5 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
>sqlite-users@mailinglists.sqlite.org
>http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users



___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] XOR operator

[Keith Medcalf]

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-
>boun...@mailinglists.sqlite.org] On Behalf Of R Smith
>Sent: Sunday, 8 October, 2017 07:38
>To: sqlite-users@mailinglists.sqlite.org
>Subject: Re: [sqlite] XOR operator
>
>On 2017/10/06 6:03 PM, Richard Hipp wrote:
>> On 10/6/17, R Smith <rsm...@rsweb.co.za> 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, 0xFF5 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
>sqlite-users@mailinglists.sqlite.org
>http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users



___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] XOR operator

[Clemens Ladisch]

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, 0xFF5 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
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] XOR operator

[Simon Slavin]

On 8 Oct 2017, at 3:55pm, R Smith  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
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] XOR operator

[R Smith]

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
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 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 <roman.fleys...@einstein.yu.edu> 
> 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 <rsm...@rsweb.co.za>
> Date: 10/8/17 9:38 AM (GMT-05:00)
> To: sqlite-users@mailinglists.sqlite.org
> Subject: Re: [sqlite] XOR operator
> 
> On 2017/10/06 6:03 PM, Richard Hipp wrote:
>> On 10/6/17, R Smith <rsm...@rsweb.co.za> 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, 0xFF5 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
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 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 <rsm...@rsweb.co.za>
Date: 10/8/17 9:38 AM (GMT-05:00)
To: sqlite-users@mailinglists.sqlite.org
Subject: Re: [sqlite] XOR operator

On 2017/10/06 6:03 PM, Richard Hipp wrote:
> On 10/6/17, R Smith <rsm...@rsweb.co.za> 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, 0xFF5 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
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] XOR operator

[R Smith]

On 2017/10/06 6:03 PM, Richard Hipp wrote:

On 10/6/17, R Smith  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, 0xFF5 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
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] XOR operator

[Jens Alfke]

> On Oct 6, 2017, at 9:25 AM, Alex Henrie  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
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] XOR operator

[Alex Henrie]

2017-10-06 1:28 GMT-06:00 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)".

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
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] XOR operator

[Richard Hipp]

On 10/6/17, R Smith  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
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] XOR operator

[R Smith]

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

On 6 Oct 2017, at 9:12am, Rowan Worth  wrote:
On 6 October 2017 at 15:42,  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
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] XOR operator

[Darko Volaric]

> 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  wrote:
> 
> 
> 
> On 6 Oct 2017, at 9:12am, Rowan Worth  wrote:
> 
>> On 6 October 2017 at 15:42,  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
> 
> 
> 
> I can’t find anywhere in SQLite’s own documentation that defines them.  
> Perhaps this should be remedied.
> 
> Simon.
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] XOR operator

[Andy Ling]

On 6 Oct 2017, at 9:12am, Rowan Worth  wrote:

> On 6 October 2017 at 15:42,  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
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] XOR operator

[Simon Slavin]

On 6 Oct 2017, at 9:12am, Rowan Worth  wrote:

> On 6 October 2017 at 15:42,  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



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

Simon.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] XOR operator

[Rowan Worth]

On 6 October 2017 at 15:42,  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
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 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=%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
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 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
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] 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
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users