Two-valued logic

"Dawn M. Wolthuis" <dwolt.DeleteThis@tincat-group.com> wrote in message news:bsnp6q$fdn$1@news.netins.net...
 > I work with a model that uses a two-valued logic. A NULL value under this
 > scenario can be handled logically as a null set value. With this model, a
 > NULL then = a NULL because a null set equals a null set..

I'm not sure I understand. Are you saying that your model includes
the empty set? That seems sound if unremarkable.


 > My impression from reading Date and others is that the three-valued logic of
 > SQL that is proliferated in RDBMS's does not have a lot of fans. However, I
 > don't know if that is really the case or if I just happen to be reading the
 > pro-two-valued logic folks.

Most of the authors I've come across are critical of SQL nulls.


 > Who is out there that will still defend three-valued logic within databases
 > and suggest that it is a better strategy than using a two-valued approach?
 > Would it be accurate to state that most database theorists agree that a
 > two-valued logic provides significant benefits?

The one person I respect who defends nulls is Lee Fesperman. He
has a web site for his RDBMS product; there are whitepapers
there that cover his reasoning.

His website:
<a style='text-decoration: underline;' href="http://firstsql.com/" target="_blank">http://firstsql.com/</a>

"In Defense of Nulls"
<a style='text-decoration: underline;' href="http://firstsql.com/idefend.htm" target="_blank">http://firstsql.com/idefend.htm</a>

For myself, I dislike 3VL, since I think it adds tremendous complexity
but little expressiveness. The expressiveness it does add would be
better dealt with in the type system, and not in the logic system.


Marshall<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Two-valued logic 

"Marshall Spight" <mspight.RemoveThis@dnai.com> wrote in message
news:_sKHb.502995$275.1414945@attbi_s53...
 > "Dawn M. Wolthuis" <dwolt.RemoveThis@tincat-group.com> wrote in message
news:bsnp6q$fdn$1@news.netins.net...
  > > I work with a model that uses a two-valued logic. A NULL value under
this
  > > scenario can be handled logically as a null set value. With this model,
a
  > > NULL then = a NULL because a null set equals a null set..
 >
 > I'm not sure I understand. Are you saying that your model includes
 > the empty set? That seems sound if unremarkable.
 >

Yes, it is both sound and unremarkable (quite like the rest of the model --
it just "thinks" the way a regular person -- me, for example -- suspects it
will). The two-valued logic definitely provides challenges when one chooses
to issue SQL commands via ODBC or JDBC, however, rather than using a
language that works with two-valued data and perceives nulls as a value
rather than the lack of a value.

<snip>
 > The one person I respect who defends nulls is Lee Fesperman. He
 > has a web site for his RDBMS product; there are whitepapers
 > there that cover his reasoning.
 >
 > His website:
<font color=purple> > <a style='text-decoration: underline;' href="http://firstsql.com/</font" target="_blank">http://firstsql.com/</font</a>>
 >
 > "In Defense of Nulls"
<font color=purple> > <a style='text-decoration: underline;' href="http://firstsql.com/idefend.htm</font" target="_blank">http://firstsql.com/idefend.htm</font</a>>
 >
 > For myself, I dislike 3VL, since I think it adds tremendous complexity
 > but little expressiveness. The expressiveness it does add would be
 > better dealt with in the type system, and not in the logic system.
 >
 >
 > Marshall

A very helpful and much appreciated response, Marshall. Thanks! --dawn<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Two-valued logic 

Dawn M. Wolthuis wrote:

 > I work with a model that uses a two-valued logic. A NULL value under this
 > scenario can be handled logically as a null set value. With this model, a
 > NULL then = a NULL because a null set equals a null set..

Is your use of the indefinite article ('a two-valued logic')
significant - that is, does the model you work with use one of a
number of possible two-valued logics, but by implication not the
familiar Boolean (Aristotelean) logic? (I'm just nit-picking, unless
the answer is that 'a' is significant - but then I'm very puzzled!)

I don't dispute that null sets are equal. What does puzzle me is how
you are storing a null set (as an alternative to some sort of NULL
marker) in a single-valued attribute. Or are all attributes in
relations actually set valued?

 > My impression from reading Date and others is that the three-valued logic of
 > SQL that is proliferated in RDBMS's does not have a lot of fans. However, I
 > don't know if that is really the case or if I just happen to be reading the
 > pro-two-valued logic folks.

Date would argue that SQL DBMS are not RDBMS (or, at any rate, not
TRDBMS, where the T stands for True). However, that's nit-picking, again.

I don't like 3-valued logic; it is harder to do right than 2-valued
logic. There are undeniably occasions when the value represented in
SQL as a NULL would be better represented by an empty set.

If you want to find a proponent of 3-valued logic, look at some of Don
Chamberlain's books on DB2/UDB -- at least one of them contains a
defense of 3-valued logic as found in SQL, and it is moderately
clearly a riposte to some of Date's arguments.

 > Who is out there that will still defend three-valued logic within databases
 > and suggest that it is a better strategy than using a two-valued approach?

Not me.

 > Would it be accurate to state that most database theorists agree that a
 > two-valued logic provides significant benefits?

The proponents of 3-valued logic argue that the performance benefits
claimed for 2-valued logic over 3-valued logic are over-stated. I've
not done the experimentation to justify that. The clarity of 2-valued
logic is better than 3-valued logic. The rules (and things like
tautologies) are more familiar, so people would probably make fewer
mistakes using a 2-valued logic. And when an empty set is appropriate
as the 'unknown' answer, using an empty set instead of a third logic
value would be a lot more sensible.

--
Jonathan Leffler #include <disclaimer.h>
Email: jleffler.DeleteThis@earthlink.net, jleffler.DeleteThis@us.ibm.com
Guardian of DBD::Informix v2003.04 -- <a style='text-decoration: underline;' href="http://dbi.perl.org/" target="_blank">http://dbi.perl.org/</a><!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Two-valued logic 

"Jonathan Leffler" <jleffler DeleteThis @earthlink.net> wrote in message
news:3M9Ib.11648$lo3.1065@newsread2.news.pas.earthlink.net...
 > Dawn M. Wolthuis wrote:
 >
  > > I work with a model that uses a two-valued logic. A NULL value under
this
  > > scenario can be handled logically as a null set value. With this model,
a
  > > NULL then = a NULL because a null set equals a null set..
 >
 > Is your use of the indefinite article ('a two-valued logic')
 > significant - that is, does the model you work with use one of a
 > number of possible two-valued logics, but by implication not the
 > familiar Boolean (Aristotelean) logic? (I'm just nit-picking, unless
 > the answer is that 'a' is significant - but then I'm very puzzled!)

Sorry for the lack of precision -- I was just talking to a mathematics
historian who is writing about Boole and told me that associating Boole with
two-valued logic is not accurate (or something like that). In order to
avoid any discussion about whether two-valued logic should be termed
Boolean, I avoided that, but YES, what I meant was two-valued Boolean logic.

 >
 > I don't dispute that null sets are equal. What does puzzle me is how
 > you are storing a null set (as an alternative to some sort of NULL
 > marker) in a single-valued attribute. Or are all attributes in
 > relations actually set valued?

In this model (Nelson-Pick), one can consider every value a set, thus a null
value can stand for the null set and the value of "12345" can stand for
{"12345"}. This is simply one way to model it, but it is the one that makes
it the most clear to relational theorists why it is OK to view null as a
value such that null = null.

  > > My impression from reading Date and others is that the three-valued
logic of
  > > SQL that is proliferated in RDBMS's does not have a lot of fans.
However, I
  > > don't know if that is really the case or if I just happen to be reading
the
  > > pro-two-valued logic folks.
 >
 > Date would argue that SQL DBMS are not RDBMS (or, at any rate, not
 > TRDBMS, where the T stands for True). However, that's nit-picking, again.
 >
 > I don't like 3-valued logic; it is harder to do right than 2-valued
 > logic. There are undeniably occasions when the value represented in
 > SQL as a NULL would be better represented by an empty set.
 >
 > If you want to find a proponent of 3-valued logic, look at some of Don
 > Chamberlain's books on DB2/UDB -- at least one of them contains a
 > defense of 3-valued logic as found in SQL, and it is moderately
 > clearly a riposte to some of Date's arguments.
 >
  > > Who is out there that will still defend three-valued logic within
databases
  > > and suggest that it is a better strategy than using a two-valued
approach?
 >
 > Not me.
 >
  > > Would it be accurate to state that most database theorists agree that a
  > > two-valued logic provides significant benefits?
 >
 > The proponents of 3-valued logic argue that the performance benefits
 > claimed for 2-valued logic over 3-valued logic are over-stated. I've
 > not done the experimentation to justify that. The clarity of 2-valued
 > logic is better than 3-valued logic. The rules (and things like
 > tautologies) are more familiar, so people would probably make fewer
 > mistakes using a 2-valued logic. And when an empty set is appropriate
 > as the 'unknown' answer, using an empty set instead of a third logic
 > value would be a lot more sensible.

Agreed! --dawn

 > --
 > Jonathan Leffler #include <disclaimer.h>
 > Email: jleffler DeleteThis @earthlink.net, jleffler DeleteThis @us.ibm.com
<font color=purple> > Guardian of DBD::Informix v2003.04 -- <a style='text-decoration: underline;' href="http://dbi.perl.org/</font" target="_blank">http://dbi.perl.org/</font</a>>
 ><!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Two-valued logic 

"Marshall Spight" <mspight RemoveThis @dnai.com> wrote in message
news:_sKHb.502995$275.1414945@attbi_s53...
<snip>
 > "In Defense of Nulls"
<font color=purple> > <a style='text-decoration: underline;' href="http://firstsql.com/idefend.htm</font" target="_blank">http://firstsql.com/idefend.htm</font</a>>
 >
 > For myself, I dislike 3VL, since I think it adds tremendous complexity
 > but little expressiveness. The expressiveness it does add would be
 > better dealt with in the type system, and not in the logic system.
 >
<snip>
Good article on nulls. I agree with him in defending nulls. However, I
agree with you that there is not good enough reason to complicate things
with 3VL. So, using Boolean logic with null treated as the null set seems
like a very good approach. It makes it easiest for the average end-user to
understand and query the data.

<musings>
Since the old, but useful model I'm working with right now (Nelson-Pick) was
developed in order to make it easy for the military in Viet Nam to query and
understand their data without any DBA's or IT professionals in their midst,
it is very pragmatic this way. This model seems to have good solutions to
questions such as whether or not to use multivalued logic without having
considered all options by thinking in terms of what would be most useful to
their customers..

With Nelson-Pick, I'm backing into a model based on the highly usable
implementations, whereas with RDBMS's, the database implementations are
basedon the relational model. What I'm finding is that there are likely to
be flaws (mismatches) in the model for Nelson-Pick just as there are
mismatches in the implementations of the relational model. However, just as
the relational model "works" well on paper, the Nelson-Pick implementations
work well in practice.

My goal is still to get a good handle on why the theory I've read
(relational database theory) and the experiences I've had (with many types
of databases) are not in step. The Nelson-Pick model has yielded the more
productive software development teams I've worked with, with the RDBMS's
yielding the poorest productivity (seemingly worse than IMS and other older
models). This is simply my experience, but I have anecdotal evidence that
many others have seen the same disparity.

Both the hierarchical and Nelson-Pick databases pre-date the relational
model. I'm certain we have gained something with RDBMS's, but it is really
obvious to me that we have lost something as well -- developer productivity,
ease of software maintenance = what are currently termed "agility".

</musings>

--dawn<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Two-valued logic 

"Dawn M. Wolthuis" <dwolt.DeleteThis@tincat-group.com> wrote in message
news:bsslkh$2la$1@news.netins.net...
 > This model seems to have good solutions to
 > questions such as whether or not to use multivalued logic without having
 > considered all options by thinking in terms of what would be most useful
to
 > their customers..

Oh, please. Praying for the customer benefits doesn't automatically give you
insight into superior solution.<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Two-valued logic 

"Mikito Harakiri" <mikharakiri.TakeThisOut@iahu.com> wrote in message
news:oilIb.10$7S6.193@news.oracle.com...
 > "Dawn M. Wolthuis" <dwolt.TakeThisOut@tincat-group.com> wrote in message
 > news:bsslkh$2la$1@news.netins.net...
  > > This model seems to have good solutions to
  > > questions such as whether or not to use multivalued logic without having
  > > considered all options by thinking in terms of what would be most useful
 > to
  > > their customers..
 >
 > Oh, please. Praying for the customer benefits doesn't automatically give
you
 > insight into superior solution.
 >

You are absolutely correct. In fact I would suggest that starting with a
solid model and implementing it would be the better approach. If I had not
seen it with my own two eyes, I would have expected projects that employ
relational databases to excel in at least software maintenance productivity,
but, alas, that is not the experience I have had. To be certain that my 25
years in this profession were not simply abberant in this regard, I have
"asked around" and there seems to be a significant number of professionals
with similar stories.

So, if you have other theories of why so many folks (especially those who
are paying) who have used both RDBMS solutions and other non-RDBMS database
implementations have favored the non-RDBMS efforts, I'm all ears. I'm sure
there are folks who have had the opposite experience as well, but my
interest right now is in determining why the Nelson-Pick databases have had
such a significant following for so many years (birthdate is considered
around 1965), including companies considering it their secret weapon against
competitors. But still it has no backing from the academic community (not
even taught in colleges) and generally sits below the radar.

When I first saw PICK (in the form of Pr1me Information) as a manager
starting a new job, I remarked "that's not a database!" and was then
overwhelmed by the productivity my new team had when using this "not a
database" as a means for storing and retrieving data. I'm trying to figure
out why this is the case and to square up database theories with
experiences.

Thanks. --dawn<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Two-valued logic 

  >> However, I don't know if that is really the case or if I just
happen to be reading the pro-two-valued logic folks. <<

Yep, you are. The entire SQL world is on 3VL and if Cood had his way,
it would be a 4VL (TRUE, FALSE, "attribute exists for the entity, but
value not known" and "attribute does not exists for the entity, so
value cannot exist")

In fact, there is a whole area of "missing data" theory in the
literature. Statistics have all kinds of "missing data" values, for
example.<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Two-valued logic 

"--CELKO--" <joe.celko RemoveThis @northface.edu> wrote in message <news:a264e7ea.0401030843.6b17ecd2@posting.google.com>...

   > >> However, I don't know if that is really the case or if I just
 > happen to be reading the pro-two-valued logic folks. <<
 >
 > Yep, you are. The entire SQL world is on 3VL and if Cood had his way,
 > it would be a 4VL (TRUE, FALSE, "attribute exists for the entity, but
 > value not known" and "attribute does not exists for the entity, so
 > value cannot exist")

And there are claims that even 4VL will be insufficient:

URL:http://home.btconnect.com/SiliconDale/silicon10.htm

(The proposed "mark concept" is reminiscent of IEEE floating-point
Martians, such as +/-INF, NAN, etc.)

 > In fact, there is a whole area of "missing data" theory in the
 > literature. Statistics have all kinds of "missing data" values, for
 > example.

And all kinds of ways of dealing with "missing data". Should the
relational model bake in support for all of them, or if not, then
which ones, exactly?

URL:http://pfc.forestry.ca/profiles/wulder/mvstats/missdata_e.html

--
Joe Foster <mailto:jlfoster%40znet.com> Wanna buy a Bridge? <http://xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Two-valued logic 

"--CELKO--" <joe.celko.RemoveThis@northface.edu> wrote in message <news:a264e7ea.0401030843.6b17ecd2@posting.google.com>...

   > >> However, I don't know if that is really the case or if I just
 > happen to be reading the pro-two-valued logic folks. <<
 >
 > Yep, you are. The entire SQL world is on 3VL and if Cood had his way,
 > it would be a 4VL (TRUE, FALSE, "attribute exists for the entity, but
 > value not known" and "attribute does not exists for the entity, so
 > value cannot exist")

And there are claims that even 4VL will be insufficient:

URL:http://home.btconnect.com/SiliconDale/silicon10.htm

(The proposed "mark concept" is reminiscent of IEEE floating-point
Martians, such as +/-INF, NAN, etc.)

 > In fact, there is a whole area of "missing data" theory in the
 > literature. Statistics have all kinds of "missing data" values, for
 > example.

And all kinds of ways of dealing with "missing data". Should the
relational model bake in support for all of them, or if not, then
which ones, exactly?

URL:http://pfc.forestry.ca/profiles/wulder/mvstats/missdata_e.html

--
Joe Foster <mailto:jlfoster%40znet.com> Wanna buy a Bridge? <http://xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Two-valued logic 

"--CELKO--" <joe.celko DeleteThis @northface.edu> wrote in message
news:a264e7ea.0401030843.6b17ecd2@posting.google.com...
   > >> However, I don't know if that is really the case or if I just
 > happen to be reading the pro-two-valued logic folks. <<
 >
 > Yep, you are. The entire SQL world is on 3VL and if Cood had his way,
 > it would be a 4VL (TRUE, FALSE, "attribute exists for the entity, but
 > value not known" and "attribute does not exists for the entity, so
 > value cannot exist")
 >
 > In fact, there is a whole area of "missing data" theory in the
 > literature. Statistics have all kinds of "missing data" values, for
 > example.

Thanks, yes good points. I have read the historic information and am well
aware (too well aware!) of the 3VL of SQL since I have had to map a 2VL data
store to it. Also, the issue of missing data is definitely swirled into
this, along with the definition of a "NULL" value/no-value.

However, the more recent writings, including those of Date & Darwin IIRC
indicate that a 2VL would be preferable. I agree that a 2VL is preferable,
while still retaining a NULL value for missing data (treated as a null set
so that it truely is a value).

--dawn<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Two-valued logic 

  >> ... And all kinds of ways of dealing with "missing data". Should
the relational model bake in support for all of them, or if not, then
which ones, exactly? <<

You ought to be able to do something for missing data; it is a fact of
life. Date's tricks for avoiding it just don't work. He had a
soluton to an old SQL puzzle of mine on <a style='text-decoration: underline;' href="http://www.dbdebunk.com" target="_blank">www.dbdebunk.com</a> where we
wanted the current salary date and the previous salary, but a new-hire
(i.e. no previous data) ws to show up as a NULL. He used an actual
date for a missing date (1900-01-01 or something); this implied that
there was a loooooong time between raises for some personnel.

Well, the solution we came up in SQL with is the NULL. The advantage
is that it has known characteristics, is pretty minimal and has
built-in support. The dis-advantage is that missing data depends on
the datatype -- those IEEE floating point thingies you just mentioned
for numerics, versus strings, versus temporal data (+/- eternity,
etc.)<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Two-valued logic 

"--CELKO--" <joe.celko.TakeThisOut@northface.edu> wrote in message <news:a264e7ea.0401051727.71254790@posting.google.com>...

   > >> ... And all kinds of ways of dealing with "missing data". Should
 > the relational model bake in support for all of them, or if not, then
 > which ones, exactly? <<
 >
 > You ought to be able to do something for missing data; it is a fact of
 > life. Date's tricks for avoiding it just don't work. He had a
 > soluton to an old SQL puzzle of mine on <a style='text-decoration: underline;' href="http://www.dbdebunk.com" target="_blank">www.dbdebunk.com</a> where we
 > wanted the current salary date and the previous salary, but a new-hire
 > (i.e. no previous data) ws to show up as a NULL. He used an actual
 > date for a missing date (1900-01-01 or something); this implied that
 > there was a loooooong time between raises for some personnel.

Where can I find the original text of the puzzle? I knocked
together a few possible solutions in Access SQL (yeah, yeah)
which hork up 'N/A' for any missing dates or salary amounts,
both with and without resorting to IIf() or other functions.

 > Well, the solution we came up in SQL with is the NULL. The advantage
 > is that it has known characteristics, is pretty minimal and has
 > built-in support. The dis-advantage is that missing data depends on
 > the datatype -- those IEEE floating point thingies you just mentioned
 > for numerics, versus strings, versus temporal data (+/- eternity,
 > etc.)

However, NULL is one of the biggest headaches for just about
everyone who actually works with SQL databases. Sometimes
NULL appears to be equal to NULL, and sometimes it doesn't!
Won't slaying the NULL beast require user-defined domains,
supporting user-defined "special values" such as 'N/A' with
user-defined semantics on a domain-by-domain basis, calling
for user-defined comparison operators, etc., etc., etc.?

--
Joe Foster <mailto:jlfoster%40znet.com> Sign the Check! <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Two-valued logic