Re: 4 the Faq: Strengths and Weaknesses of Data Models

From: Costin Cozianu <c_cozianu_at_hotmail.com>
Date: Wed, 13 Oct 2004 17:26:44 -0700
Message-ID: <2t5vehF1pk833U1_at_uni-berlin.de>


Mikito Harakiri wrote:

> "Costin Cozianu" <c_cozianu_at_hotmail.com> wrote in message
> news:2t5n2uF1sgejuU1_at_uni-berlin.de...
>

>>Most mathematical models are complicated,
>>complex, unintuitive, not easy to make derivations with, ugly

>
>
> You probably have meant CS models, not Math ones. Beginning with the mother
> of all CS models -- Turing Machine. As far as Math is concerned,
> Mathematical Logic and Set Theory objects are among the least pretty ones.
>

Actually Turing Machine is not quite that bad for the purpose for which it was designed -- and it wasn't designed for programming. It's true that some teachers subject their students to useless tortures like for example them implementing integer addition on TMs.

> (I somehow feel that this 2-cents correction is necessary:-).
>
>

Of course, I meant to refer primarily to mathematical models behind programming concepts. I don't believe there are CS models as such, all models used in CS, including TM are mathematical in their very essence.

But neither are all "pure Math" theories filled with beauty. However, in "pure Math" activities without some degree of elegance, any model will stand little chance of being published, much less embraced and adopted. Whereas in our "mathematical engineering" activity we do suffer from collective hallucination (UML anyone ?).

Speaking of ugly models, we need to make matters clearer by way of examples:

A rather extreme os a mathematical model for boolean algebra (it's in Scheme, but it is basically lambda calculus):

(define _true_ (lambda (x y) x))
(define _false_ (lambda (x y) y))

(define _NOT_ (lambda (f) (f _false_ _true_)))

(define _AND_ (lambda (f1 f2) (f1 (f2 (_true_ _false_)) _false_)))
(define _OR_ (lambda (f1 f2) (f1 (_true_ (f2 (_true_ _false_)) )))
(define _IF_ (lambda (f x y) (f x y)))
(define _IMPLIES_ (lambda (f1 f2) (f1 (f2 _true_ _false_)_true_)))

Now imagine how easy one would reason about tautologies in the model above. The fact that something is mathematical says precious little.

And speaking of inadequacy the same can be said about D&D's treatment of NULL. It is very much mathematical, but now the simple:

  PERS_INFO(

	ID NUMBER NOT NULL,
	NAME VARCHAR NOT NULL,
	JOB VARCHAR,
	SALARY NUMBER)

becomes (in
http://web.onetel.com/~hughdarwen/TheThirdManifesto/Missing-info-without-nulls.pdf ):

  WITH (EXTEND JOB_UNK ADD ‘Job unknown’ AS Job_info) AS T1,

	 (EXTEND UNEMPLOYED ADD ‘Unemployed’ AS Job_info) AS T2,
	 (DOES_JOB RENAME (Job AS Job_info)) AS T3,
	 (EXTEND SALARY_UNK ADD ‘Salary unknown’ AS Sal_info) AS T4,
	 (EXTEND UNSALARIED ADD ‘Unsalaried’ AS Sal_info) AS T5,
	 (EXTEND EARNS ADD CHAR(Salary) AS Sal_info) AS T6,
	 (T6 { ALL BUT Salary }) AS T7,
	 (UNION ( T1, T2, T3 )) AS T8,
	 (UNION ( T4, T5, T7 )) AS T9,
	 (JOIN ( CALLED, T8, T9 )) AS PERS_INFO :
  PERS_INFO Where definition for base tables and corresponding constraints have been removed for the sake of brevity and reducing the exposure of the reader. One can say everything about the math of it, but any mathematician will tell you right away that the results can only be qualified as: *ugly* (brrr....).

That's what one gets when "mathematical" is no longer a tool to be used smartly, but an end in itself.

Costin Received on Thu Oct 14 2004 - 02:26:44 CEST

Original text of this message