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

Dmitry A. Kazakov wrote:
[...]
> >> Neither it states *how* to construct union or intersection.
> >
> > That is correct, but the union axiom has a clear and intuitive
> > constructive interpretation that the powerset axiom lacks.
>
> It has a quite intuitive interpretation when sets are finite.

Go ahead and provide one in the first-order language.

[...]
>. What about (a, b, c, d ) <--> { a, b, c, d } ?

What about it ?

>
> I don't care about construction of a set, if I can denote the set.

If you do not care about constructing a structure, how do you intend to use something that you have not constructed in any programming language ?

> Example:
> 1.3 of R.

And this shows what exactly ?

>
> Interval numbers are not approximations, they are estimations.

Could you elaborate ?

>pi is also
> not an approximation, it is pi. I am free to choose a representation where
> pi were exact.

I'd be curious to see such representation.

 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.

For example ?

>
> >>>>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.
> >
> > They are, we just use prepackaged products (as any computational model
> > does),
>
> But that means that RM isn't based on set theory! It is on set theory
> *plus* some "prepackaged products."

That's a bizzare statemen akin to saying that functions, or any math structure for that matter, for are not based on the set theory because they are used ready-made.

>
> 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?

I am not going to start explaining where the difference is because it would be an exercise in futility. There is ample literature on the subject, network data model vs. relational might or might not ring a bell.

>
> >>> there is no need to
> >>> construct it. Besides, can you construct Z *anywhere* ?
> >>
> >> Any finite subset of, in any language that supports ADTs.
> >
> > Go ahead and oblige us with an example.
>
> Take bit strings, Algorithms for +, -, * can be found in any text book on
> computer design.

Could you elaborate ? I am not sure what you are trying to say here. You were supposed to construct integers as I recall.

>
> > [...]
> >>>>>> 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.
> >
> > What's that supposed to mean ?
>
> 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.
>

That is funny. Regardless of what you are doing with integers, you cannot do that as you do not have integers yet. You said that you'd 'inherit' integers from rationals, so rationals should be your primordial soup presumably. What's the point of inheriting integers from rationals if you already have them ? Besides you did not construct integers either. Please retry if you can.

> 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).

If you have 'abstract rationals' whtever that is, they are not really rationals one came to expect from one's school years, they are surely something else by virtue of being unusable since they are 'abstract'.

>
> --
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de
Received on Sun May 07 2006 - 01:18:03 CEST