Re: [sqlite] XOR operator

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

Re: [sqlite] XOR operator

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

Re: [sqlite] XOR operator

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,

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

Re: [sqlite] XOR operator

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 >

Re: [sqlite] XOR operator

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

Re: [sqlite] XOR operator

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

Re: [sqlite] XOR operator

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

Re: [sqlite] XOR operator

>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

Re: [sqlite] XOR operator

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

Re: [sqlite] XOR operator

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

Re: [sqlite] XOR operator

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