Re: boolean datatype ... wtf?

On Sat, 2 Oct 2010 04:52:38 -0700 (PDT), Paul Mansour wrote:

(snip)
>You write above that “any column with two possible values is basically
>a boolean in disguise”. Contrast this a comment by Erwin above.
>Erwin writes about Gene’s post that in Genes’s case, his Boolean
>“really isn't just a Boolean”.

Hi Paul,

Upon rereading, I must admit that my statement was too bold. Not any two-valued domain is boolean. Whe I wrote this, I was thinking of examples I have come across where a two-values domain was indeed a boolean in disguise, but I forgot some other cases, such as gender.

The domain gender has two possible values, male and female. But in order to qualify as "boolean in disguise", it also has to support boolean operators. I can define NOT (NOT male = female, and vice versa), but I am stuck at AND and OR. What should the result of "male AND female" be? I can think of a lot of possible answers, but none of them falls in the domain {male, female}.

(Interesting - Erwin mentions the same gender domain in his reply, and a different but related test: he usees the implies operator rather than the and and or operators.)

Of course, one could model gender as an "is_female" attributem, which would be boolean. And when this attribute is implemented as a character column with its domain limited to 'yes' and 'no', it would be a boolean is disguise.

>This highlights something I was thinking about during this discussion.
>I wonder is it useful to make the distinction between truly Boolean
>and superficially Boolean? Consider what was I think Vadim’s original
>examply, IsCreditWorthy – truly a Boolean as it divides the world into
>two parts, credit worthy and not credit worthy (and as Vadim notes,
>computable, so you don’t need a column for it anyway). You can’t
>simply add another category without changing the meaning of the first
>two categories. Now consider a column Size with the two allowable
>values: “Small” and “Large”. Maybe this is just superficially
>Boolean? “Medium” is probably just around the corner, even if it was
>not part of the original requirements of the system. We can add it
>without changing the name of the column, or changing the meaning of
>the two existing values. Perhaps then if a column is superficially
>Boolean it should not be treated any differently than a column with n
>potential values. Or maybe I’m just talking nonsense.

Hmmmm, no. I don't think this is nonsense. I think this is yet another way to distinguish domains that just happen to have two values from domain that of course have two values because they're booleans in disguise.
If, as a result of some freaky genetic coincidence, children with a third possible gender start being born tomorrow, the "gender" column needs to have its domain expanded to a third value. But the "is_female" column can remain unchanged - a person is still either a female, or not (though in the latter case, one could now no longer automatically assume that the not female person is a male). The pseudo-boolean still has two values even after such a drastic change; the non-boolean does get a third possible value.

Best, Hugo Received on Tue Oct 05 2010 - 00:19:46 CEST