NULLs: theoretical problems?

#41

On 11 août, 16:14, Jan Hidders <hidd... (AT) gmail (DOT) com> wrote:

Quote:

On Aug 11, 3:59 am, Aloha Kakuikanu <aloha.kakuik... (AT) yahoo (DOT) com> wrote:

On Aug 10, 4:52 pm, "V.J. Kumar" <vjkm... (AT) gmail (DOT) com> wrote:

"David Portas" <REMOVE_BEFORE_REPLYING_dpor... (AT) acm (DOT) org> wrote innews:NM-dncYFOuhqBybb4p2dnAA (AT) giganews (DOT) com:

"paul c" <toledobythe... (AT) oohay (DOT) ac> wrote in message
news:JXLui.45171$rX4.26997 (AT) pd7urf2no (DOT) ..

(even though I'm not sure in "s{X} = t{X} implies s{Y} = t{Y}"
whether "implies" stands for logical implication.)

Good catch. It seems that logical implication is not well defined for
three-value logic.

It is not that three-valued implication is not 'well defined' whatever it
means. As a matter of fact, there are a few competing definitions to
choose from, Lukaciewicz's, Kleene's and someone else's whose name Ido
not recall. They define implication in the usual way, with the truth
table.

I wonder if 3-rd value logic interpretation is trivial. Take any
boolean algebra that is more than 2 valued, and partition its elements
into 3 equivalence classes. For example, one may define True as
maximal element, False as a minimal one, and combine all the rest into
Unknown. For four element BA we have:

00 -- False
01 -- Unknown
10 -- Unknown
11 -- True

Sure in this model formal implication "Unknown -> Unknown" evaluates
to True or Unknown:

"01 -> 01" = "01 \/ ~01" = "01 \/ 10" = "11" -- true

on the other hand

"01 -> 10" = "01 \/ ~10" = "01 \/ 01" = "01" -- unknown

So the problem is to make the partition of BA elements to respect BA
operations, so that the later can be defined consistently. Apparently,
one can have consistent 4 valued logic, but not 3 valued one. Am I
missing anything?

Yes. The problem is not that there is no consistent interpretation but
that there is more than one. Apart form the fact that with a truth
table approach you will always have the problem that (P \/ ~P) will
never evalutate to TRUE if P is not TRUE or FALSE. But that is of
course the usual trade off between "what we really want" and "what can
be efficiently computed".
Multiplication of theories is a consequence of subjective and

anthropomorphic characterization of database management. I liked a
debunked article once coming that exposed a new interpretation based
on 128 types of NULLS. The issue was precisely on that matter.

Quote:

-- Jan Hidders

#42

Aloha Kakuikanu <aloha.kakuikanu (AT) yahoo (DOT) com> wrote in
news:1186797598.242847.86560 (AT) q4g2000prc (DOT) googlegroups.com:

Quote:

On Aug 10, 4:52 pm, "V.J. Kumar" <vjkm... (AT) gmail (DOT) com> wrote:
"David Portas" <REMOVE_BEFORE_REPLYING_dpor... (AT) acm (DOT) org> wrote
innews:NM-dncYFOuhqBybb4p2dnAA (AT) giganews (DOT) com:

....

Quote:

It is not that three-valued implication is not 'well defined'
whatever it means. As a matter of fact, there are a few competing
definitions to choose from, Lukaciewicz's, Kleene's and someone
else's whose name I do not recall. They define implication in the
usual way, with the truth table.

I wonder if 3-rd value logic interpretation is trivial. Take any
boolean algebra that is more than 2 valued, and partition its elements
into 3 equivalence classes. For example, one may define True as
maximal element, False as a minimal one, and combine all the rest into
Unknown. For four element BA we have:

00 -- False
01 -- Unknown
10 -- Unknown
11 -- True

Firstly, strictly speaking, a multivalued logic is not of course
boolean. What you've defined is similar to Belnap's paraconsistent
logic where two additional truth values are 'both' and 'undefined'.
However, above, you've collapsed 'b' and 'u' to 'u' thus arriving to a
three valued logic.

Quote:

Sure in this model formal implication "Unknown -> Unknown" evaluates
to True or Unknown:

"01 -> 01" = "01 \/ ~01" = "01 \/ 10" = "11" -- true

on the other hand

"01 -> 10" = "01 \/ ~10" = "01 \/ 01" = "01" -- unknown

So the problem is to make the partition of BA elements to respect BA
operations, so that the later can be defined consistently. Apparently,
one can have consistent 4 valued logic, but not 3 valued one. Am I
missing anything?

You are missing the point that some multivalued logic may have multiple
interpretions. I am not sure what you mean by 'consistent 4 valued
logic'. A 3VL can admit an 'unknown' truth value interprtation as well
as a paraconsistent one depending on what 'designated' truth values are.

Quote:

#43

Quote:

Each relates to interpretation and to an abstract entity taken as a given.

Like numbers, points on a plane and all those other mathematical
constructs

?

NULLs have an "evolutionary lineage" in statistics which was worrying
about missing values long before computers. Computer science has had
its own problem with missing data. The Interim Report 75-02-08 to the
ANSI X3 (SPARC Study Group 1975) had 14 different kinds of incomplete
data that could appear as the result of queries or as attribute
values. These types included overflows, underflows, errors, and other
problems in trying to represent the real world within the limits of a
computer. I think the list is up to 20+ now.

#44

Quote:

The ANSI standard defines NULL as follows:
"null value: A special value that is used to indicate the

absence of any data value." <<

We needed to word it that for reasons of implementation. In Codd's
model there is only one NULL, a type-less marker. But hardware has to
allocate storage and therefore we had to allow for "CAST (NULL AS
<data type>)" to signal the SQL compiler about that column's storage.
There are some situations where the compiler cannot determine the data
type of a CASE expression without explicit CAST() help.

Does anyone seriously gripe about floating point numbers having gaps
in them because of implementation considerations? No, we just pick on
poor little NULL ...

#45

Quote:

As a matter of fact, there are a few competing definitions to choose from, Lukaciewicz's, Kleene's and someone else's whose name I do not recall.

You are probably thinking of Post, but there is more than that. "Many-
Valued Logics- Volume 1: Theoretical Foundations" by Bolc and Borowik,
1992, ISBN 978-3-540-55926-9 is filled with 2-3 page explanations of a
ton of such systems.

#46

On 2007-08-11, -CELKO- <jcelko212 (AT) earthlink (DOT) net> wrote:

Quote:

The ANSI standard defines NULL as follows:
"null value: A special value that is used to indicate the
absence of any data value."

We needed to word it that for reasons of implementation.

Proving that you did not know the difference between logical and
physical. Of course a NULL needs to be implemented, but it is _not_ a
value. Any possible implementation (and there are lots) will have to
be some sort of special case, but the language does not need to know.

Quote:

In Codd's model there is only one NULL, a type-less marker.
But hardware has to allocate storage and therefore we had to allow
for "CAST (NULL AS <data type>)" to signal the SQL compiler about
that column's storage.

What on earth does that mean?

Quote:

There are some situations where the compiler cannot determine the data
type of a CASE expression without explicit CAST() help.

I dont't know that I actually believe that.

Quote:

Does anyone seriously gripe about floating point numbers having gaps
in them because of implementation considerations? No, we just pick on
poor little NULL ...

But then floating-point numbers are values that are difficult
to represent, whereas NULL is _not_ a value, but is easy to
represent. The arguments are about what it means and whether we
really need it.

Eric
--
Beware of Hammer Syndrome!

#47

Quote:

Proving that you did not know the difference between logical and physical. Of course a NULL needs to be implemented, but it is _not_ a value. Any possible implementation (and there are lots) will have to be some sort of special case, but the language does not need to know.

I thihk it demonstrates that you have never worked on an ANSI or ISO
committee or written a compiler

You might want to look at the IEEE
Floating Point Standards and their "special values" -- +inf, -inf,
Nan, etc. Much more complex than a mere NULL! While IEEE does give
the "bits and bytes" for their special values, we left implementation
open but borrowed the accepted terminology from them.

Quote:

["CAST (NULL AS <data type>)" to signal the SQL compiler about that column's storage] What on earth does that mean?

I thought that was pretty clear. SQL stores data; data has a srong
data type in SQL; the compiler needs to know about it to make
decisions and allocations.

Quote:

[ CASE expression without explicit CAST() help] I dont't know that I actually believe that.

I will see if I can find one for you tomorrow -- I am babysitting my
niece's two year old tonight and have to use her Mac.

Quote:

But then floating-point numbers are values that are difficult to represent, whereas NULL is _not_ a value, but is easy to represent. The arguments are about what it means and whether we really need it.

Hey, I am just providing information about SQL. I happen to think
that NULLs can be hard to represent because they have to work with all
kinds of data types, whereas I can burn the IEEE rules into a Math Co-
processor at the hardware level.

#48

The world rejoiced as Hugo Kornelis <hugo (AT) perFact (DOT) REMOVETHIS.info.INVALID> wrote:

Quote:

On Wed, 8 Aug 2007 06:43:53 -0400, sinister wrote:

Many discussions point out one deficiency of NULLs: that they collapse
multiple, distinct concepts into one ("no value possible," "value missing,"
"value not available at this time", etc).

Hi sinister,

The deficiency in these discussions is that they fail to normalize the
design before starting to look at NULLs.

The ANSI standard defines NULL as follows:

"null value: A special value that is used to indicate the
absence of any data value."

Thus, the only concept collapsed into NULL is that of "no value here".

The concepts you mention are, indeed, various reasons why a value might
be missing. The specific reason might or might not be of interest to the
users of a database. If it's not, there's no need to let it bother us;
if it is, we need to properly model it.

Sidestep

How would you react if someone showed you a database model where the
contracts table had a single column to store both termination date and
the reason why the contract was terminated - I'm pretty sure that you'd
send the junior DBA who made that model back to class to study
normalisation rules, right?

How then would you react if you saw a model that tries to combine the
termination date and the reason why the contract is NOT terminated in a
single column?

/Sidestep

And yet, that is exactly what some people try to do in the discussion of
NULLs. They see that a value might be missing (NULL) for various
reasons, which is of course correct. They assume that the reason why the
value is missing should be somehow stored or encoded in the database,
which is not necessarily correct but might be requireed for some
applications. And then they go on to state that this reason should be
stored or encoded in the same column where the missing value should have
been - i.e. they want to use a single column to store both the
termination date of a terminated contract and the reason why there is no
termination date of a (probably not terminated, though that's not even
sure) contract. And that is of course a violation of 1NF.

Nicely put, and your example here characterizes why the "NULL problem"
is reasonable to be considered a problem.

I expect that this interpretation works well enough with various of
the possible interpretations of NULL to demonstrate that changing the
definition of NULL (e.g. - picking a formal system to change the
semantics) does not answer the underlying problem.

Quote:

Unfortunately, many database theorists, including Codd and Date, either
failed to see this basic flaw in the discussion or deliberately
sidestepped it for convenience. This has led to many pointless
discussions on using A-marks and I-marks, and how that would lead to
fourvalued logic and still not suffice, and so on....

It sounds like we're up to 21-valued logic, based on the count of how
many reasons have been discovered for data to be missing :-).

It is nice to have an example that can be easily applied to them all;
it suggests that perhaps the perceived problem truly is a problem :-).

Quote:

I made this same point, but in different words, about a month ago on my
blog:
http://sqlblog.com/blogs/hugo_kornel...lack-hole.aspx
--

wm(X,Y):-write(X),write('@'),write(Y). wm('cbbrowne','gmail.com').
http://linuxdatabases.info/info/slony.html
"Although Unix is more reliable, NT may become more reliable with
time" -- Ron Redman, deputy technical director of the Fleet
Introduction Division of the Aegis Program Executive Office, US Navy.

#49

Try this for the casting of NULLs to data types:

CREATE VIEW Foobar (a, b, c)
AS
VALUES (CAST (NULL AS INTEGER),CAST (NULL AS REAL), CAST (NULL AS
DATE));

There are several other place where you need this.

#50

On 2007-08-12, -CELKO- <jcelko212 (AT) earthlink (DOT) net> wrote:

Quote:

Proving that you did not know the difference between logical
and physical. Of course a NULL needs to be implemented, but
it is _not_ a value. Any possible implementation (and there
are lots) will have to be some sort of special case, but the
language does not need to know.

I thihk it demonstrates that you have never worked on an ANSI or ISO
committee or written a compiler

You might want to look at the IEEE
Floating Point Standards and their "special values" -- +inf, -inf,
Nan, etc. Much more complex than a mere NULL! While IEEE does give
the "bits and bytes" for their special values, we left implementation
open but borrowed the accepted terminology from them.

But that was the mistake, because a NULL need not be implemented as
a special value. It could be, but that is an implementation issue
only. A NULL is _not_ a value, whatever you use to implement it,
and you should not have called it one.

Quote:

["CAST (NULL AS <data type>)" to signal the SQL compiler about
that column's storage]
What on earth does that mean?

I thought that was pretty clear. SQL stores data; data has a srong
data type in SQL; the compiler needs to know about it to make
decisions and allocations.

Only if there is a situation where it can't work it out - I know,
this is the next point.

Quote:

[ CASE expression without explicit CAST() help] I dont't know
that I actually believe that.

I will see if I can find one for you tomorrow -- I am babysitting my
niece's two year old tonight and have to use her Mac.

Thankyou.

Quote:

But then floating-point numbers are values that are difficult
to represent, whereas NULL is _not_ a value, but is easy to
represent. The arguments are about what it means and whether we
really need it.

Hey, I am just providing information about SQL. I happen to think
that NULLs can be hard to represent because they have to work with all
kinds of data types, whereas I can burn the IEEE rules into a Math Co-
processor at the hardware level.

Which sort-of proves that NULLs and FP are not really comparable.

--
Eric