Re: The BOOLEAN data type - What is really Boolean and what is not?
Date: 21 Apr 2003 08:07:35 -0700
Message-ID: <61c84197.0304210707.2eeee80a_at_posting.google.com>
bruce.rennie_at_shell.com.au (Bruce Rennie) wrote in message news:<8d821729.0304210230.59072938_at_posting.google.com>...
> pkl_at_mailme.dk (Peter Koch Larsen) wrote in message news:<61c84197.0304180715.23ded92b@posting.google.com>...
> > Costin Cozianu <c_cozianu_at_hotmail.com> wrote in message news:<b7ncgr$2odsj$1_at_ID-152540.news.dfncis.de>...
> > > --CELKO-- wrote:
> >
> > [large snip]
> >
> [Snipped]
> > >
> > > Using a decent type system , I can define a three valued logic boolean,
> > > in 5 lines of code and reuse it all over the place where I need. If I
> > > really need to I can dfine a fuzzy boolean data type in a hadnful of
> > > code and reuse it all over the place.
> >
> > Yes - not that difficult.
>
> In fact - IMPOSSIBLE. Boolean algebras require either 2 or an integer
> power of 2 number of values in the domain. Check any good
> combinatorics text for how this works. So at a minimum you will have
>
> True or False ( 2 distinct values )
>
> or you could have
>
> True A B False ( 4 distinct values ) or 8, 16, etc
>
> where both A and B are part way between True and False.
>
> This leads to the correct logic tables.
A "nullable" boolean is not a boolean, of course. But using three
valued logic is never the less feasible.
>
> Since three valued logic is not Boolean ( there are a number of
> different ways the logic operations can be written ( for 3VL-AND and
> 3VL-OR and 3VL-NOT )), you have to decide on the particular operations
> that you will allow and how the results will be calculated. Therefore,
> the normal Boolean operations of AND and OR and NOT cannot and do not
> work with three value domains.
I am not sure I understand you.
>
> Allowing another value in the Boolean (2VL) domain forces it to no
> longer be Boolean. Problems arise. For further research, look at the
> Russian TERNARY computer from the 1950's. This was not a Boolean logic
> based machine.
I do agree it's not boolean anymore but fail to see any problems. Reverting to plain old C++, here is a class that implements three valued logic (partly pseudo-code, but I'm sure you will get the idea):
class nullable_boolean
{
boolean isnull;
boolean value;
public:
nullable_boolean(): isnull(true) {}
nullable_boolean(boolean val): isnull(false),value(val) {}
operator boolean() { return !isnull && val; }
operator or(nullable_boolean rhs)
{
if (rhs.isnull) return myself;
if (rhs) return true;
return value;
}
};
Three-valued logic implemented in a handfull of lines - probably Haskell could do it in much simpler way.
>
> > >
> >
> > The to me fundamental problem is how to cope with missing values. I
> > agree that You have no need for them in base tables, but what happens
> > in the situation where you have an outer join? If outer joins are to
> > be provided by the DBMS - and I believe they are to useful to be let
> > out - there must be some means of denoting that a field has no value.
> > There are three ways to go:
>
> If the value is missing, then provide a way in the design of the
> database that allows you NOT to store information without resorting to
> the use of NULLS. An appropriate redesign/rethink of the questions
> being asked of the DBMS on the database will give rise to sensible
> answers. Too many times I've been required to provide answers to the
> wrong questions - so - teach the questioners to ask the right
> questions - not always easy, but doable. It allows correct information
> to be given instead of wrong/partially correct that is generally
> given now (statement is stated this way deliberately - think carefully
> the implications).
So you argue that the outer join is not necesarry? If you are right, the discussion is over of course, but my premise was exactly that the outer join is here to stay.
[snip]
Kind, albeit ateistic regards
Peter
Received on Mon Apr 21 2003 - 17:07:35 CEST