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