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