Re: Storing data and code in a Db with LISP-like interface

On 6 May 2006 06:02:40 -0700, vc wrote:

> Dmitry A. Kazakov wrote:

>> On 5 May 2006 09:54:03 -0700, vc wrote:
>>
>>> Dmitry A. Kazakov wrote:
>>>> On 5 May 2006 04:18:44 -0700, vc wrote:
>>>>
>>>>> Dmitry A. Kazakov wrote:
>>>>> [...]
>>>>>>But ADTs have far less problems with set theory as the application
>>>>>> domain than RM. Trivial examples are:
>>>>>>
>>>>>> 1. Power set operation
>>>>>> 2. Set complement in an infinite universal set
>>>>>> 3. Infinite sets modeled by finite classes of equivalences
>>>>>
>>>>> The paragraph above does make any obvious sense.  Could you elaborate ?
>>>>
>>>> Above are set operations. Take SQL, and create power set of a table column,
>>>> row, table, set of tables.
>>>
>>> That's a silly request since it's widely know that ZFC does not state
>>> *how* to construct a powerset,
>>
>> Neither it states *how* to construct union or intersection.

It has a quite intuitive interpretation when sets are finite.

>>> and constructive set theories do not
>>> even have the powerset axiom (Martin-Lof).
>>
>> Ah, but to create {A} from a given set A is definitely constructive. Yet,
>> you cannot this either. The problem is not in the number of elements, and
>> sets we consider are finite anyway.

I'm glad to hear that. What about (a, b, c, d ) <--> { a, b, c, d } ?

>>>  What about (2) and (3) ?
>>
>> 2. I don't have problems with A - B, because I am not required to present
>> all elements of the set. To some extend I can go non-constructive.

I don't care about construction of a set, if I can denote the set. Example: 1.3 of R.

>> 3. I can construct floating-point numbers [intervals with rational bounds],
>> for example. I can do things symbolically. I don't need to present pi as a
>> set to be able to perform some operations on it.

Interval numbers are not approximations, they are estimations. pi is also not an approximation, it is pi. I am free to choose a representation where pi were exact. But anyway, approximate value + error bounds gives an infinite set. I can deal with. In a pure set-based model I have to present the set.

>>>>Can you create Z in RM?
>>>
>>> In RM, Z is a predefined elementary type,
>>
>> Why do you need elementary types? Set theory does not need them. If you
>> guys claim that 1) set theory is everything one needs, 2) your RM perfectly
>> embodies the theory, then a naive listener (like me) could come a
>> conclusion that 1 & 2 => integers, floats, strings are all constructed
>> using sets.

But that means that RM isn't based on set theory! It is on set theory *plus* some "prepackaged products."

Now, don't make mistakes, don't argue that these products can be reduced to set theory. Because: firstly, they might be, but not in RM, and secondly, whatever "prepackaged products" OO might have, they can be reduced to set theory in exactly same sense. So where is any difference?

>>> there is no need to
>>> construct it.  Besides,  can you construct Z *anywhere* ?
>>
>> Any finite subset of, in any language that supports ADTs.

Take bit strings, Algorithms for +, -, * can be found in any text book on computer design.

> [...]

>>>>>>  In mathematics you can go either way. Is integer
>>>>>> number rational? How different pairs (1,1),(6,6) can both be 1?
>>>>>
>>>>> You are confused, amigo.  In the secondary school algebra,  one learns
>>>>> that an integer number ain't no rational.
>>>>
>>>> That depends on construction, they could well be. In the secondary school
>>>> one learns that this does *not* matter.
>>>
>>> What does not matter ? What alternative rationals do you have in mind ?
>>
>> I can add new elements to Z instead of constructing a set of pairs and then
>> choosing subsets there.

Take Z. Add elements denoted as "1/p", for each p, prime number. Postulate them as multiplicative inverses for p. Add all: 1/pq, where p>=q, prime. Postulate. Do same with 3, 4, 5, etc primes. When finished start to add elements which are "multiplies" of new elements to primes. Use only multiplies of primes not used in the denominator. Add an additive inverse for each new element. Done.

[Basically you just need to choose some canonical form for each rational.]

>>>> That mumbo-jumbo expresses algebraic properties. Integer is a subtype of
>>>> Rational in the same sense as a ring exists in a field.
>>>
>>> So using your favourite OOP mumbo-jumbo,  how would you go about
>>> constructing rationals?
>>
>> I am free to consider integers a subtype of rationals regardless their
>> construction (=representation.) Important here is only that integer
>> inherits +, -, * which I wish to reuse as well as the programs written for
>> rationals in terms of these operations.

See above.

> Surely, they must be constructed first so that you could
> inherit integers then.

Not necessarily. You need not to inherit each implementation. In particular, you don't need to inherit data representation, because it is not "is-a" anymore. Both can have completely different representations. You can even have rational abstract (i.e. no representation at all).

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de