Search Postgresql Archives

Re: Bitmask trickiness

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jul 22, 2010 at 1:02 PM, Scott Marlowe <scott.marlowe@xxxxxxxxx> wrote:


>>
>> Why on Earth would I want to store this sort of stuff in a bit string?!
>
> Because you are manipulating bits and not integers?  I guess there are
> 10 kinds of people, those who like think in binary and those who
> don't.
>
>> I don't know about you, but I find looking at 21205 a darn'd site
>> easier than staring blankly at 101001011010101!!
>
> If the fifth bit means one thing, and the 7th bit means something
> else, quick which of the following have the fifth bit set and the 7th
> bit off:
>
> 01001101 (base2)
> or
> 77 (base 10)
>
>
>> And, fundamentally,
>> they mean precisely the same thing.
>
> Of course.  But that wasn't my point, and by my example above, one is
> much easier to figure out than the other if you're interested in bit
> twiddling.
>
>> And the '&' function works as
>> nicely with boring old decimals as it does with long-winded binaries,
>> so I really don't see the point of making it more complicated than it
>> needs to be -but I'm open to be enlightened on the matter!
>
> I fail to see how storing a binary as a binary and showing it as a
> binary makes things more complicated.  But I'm open to someone showing
> me how that's true.  At least hex or octal have direct and simple
> conversions where each hex or octal digit represents 4 or 3 bits
> respectively.  Decimal does not.
>
>> Thanks for the second link though. I hadn't realised that PostgreSQL
>> was so richly-endowed with bitwise functions. Specifically, it's got
>> the bitwise XOR I was thinking it would be nice to have in these sorts
>> of situations:
>>
>> ims=# select * from coloursample where colour # 10 = 0;
>>  recid | colour |     descript
>> -------+--------+-------------------
>>     1 |     10 | Yellow and Orange
>> (1 row)
>>
>> Not quite sure how to apply that to my more realistic example just
>> yet, but I think this will be very helpful, so thank you!
>
> Note you can cast integer to bitstring, but there may be some odd
> behaviour for sign bits and such.  Which is again why I'd use the
> right type for the job, bit string.  But it's your project.
>

Quoting...

> Because you are manipulating bits and not integers?  I guess there are
> 10 kinds of people, those who like think in binary and those who
> don't.

Er, no. 21205 is not an integer. It's an encoded bit of magic.


> quick which of the following have the fifth bit set and the 7th
>bit off:

>01001101 (base2)
>or
>77 (base 10)

I'll give you that one (except that the fifth bit isn't set and the
7th bit is on!!). Now repeat for 10 million records and see how
you get on.

Really, I don't have to visually inspect a record to work this stuff
out! So what is easier on your eye for one record is completely
irrelevant as far as my code is concerned!

>one is
>much easier to figure out than the other if you're interested in bit
>twiddling.

As I say, take an incredibly simple example and everything looks, er,
simple. Point of fact, I happen to know that the '1' bit is set in
21205 simply by looking at the last digit and spotting that it's not
even. Fat lot of good that does me when fetching 350,000 records that
happen to match 'insurance claim'.

>I fail to see how storing a binary as a binary and showing it as a
>binary makes things more complicated

Because it's NOT binary. It's an encoding. Whether that encoding is
displayed in binary, fluent hebrew or klingon or imaginary numbers is
really irrelevant to me. It happens that I can look at a decimal
number and work out most things (if the number is 29438, it's a fair
chance the 16384 bit is set, for example; if it's 4098, I know it's
4096 + 2. And so on.). If you're happier working with fancifully long
strings of 1s and 0s, good on you: but it doesn't alter the fact that
I'm working with encoded meanings, not binary digits and I prefer a
nice, compact display of that encoding which doesn't involve
hieroglyphics.

>But it's your project.

Indeed.

Doesn't mean I can do it all on my own, of course. But if it's simply
a question of personal preference, I'll take mine over yours, for
projects I work on, if that's OK. No hard feelings! :-)

Regards
HJR

-- 
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux