Re: Temporal database - no end date
From: paul c <toledobythesea_at_oohay.ac>
Date: Fri, 19 Jan 2007 12:08:38 GMT
Message-ID: <ax2sh.703881$5R2.114283_at_pd7urf3no>
>
>
> Some computer algebra systems work this way, but
> programming languages? I can't think of a single one.
> (And I can probably name more programming languages
> than most people you know.) In programming languages we
> pretty much universally use the nearest double precision
> floating point number instead of an abstract token. And
> that usually gives us a lot more precision than we're
> going to need.
>
>
>
>
>
> IEEE floating point numbers *are* symbols. You
> probably meant algebraic manipulations. And I wouldn't
> say they are "as good"; they are better, if you are
> talking about precision. However for the vast
> majority of use cases, the extra precision isn't
> worth the trouble.
>
>
>
>
>
> I have thought about it plenty, and my mindset
> is not the problem. The difficulties in handling a
> continuum are fundamental and intrinsic, and not
> a failure of imagination.
>
>
>
>
>
> Only two?
>
> nat = zero | succ(nat)
>
>
>
>
>
> Nothing in the last two paragraphs has any relevance to modeling
> continua that I can detect. Again, we model the reals with floating
> point, and it works just fine, even though the reals have the power
> of the continuum and floating point doesn't. If we want to bring it
> back to time, then we have to consider that time in the computer
> has a machine-defined resolution, and that makes time in the computer
> discrete, regardless of anything Einstein said about the real world.
> Java models time with a 64 bit int, and that gives you millisecond
> resolution over half a billion year span. That's good enough for my
> apps.
>
>
> Marshall
>
Date: Fri, 19 Jan 2007 12:08:38 GMT
Message-ID: <ax2sh.703881$5R2.114283_at_pd7urf3no>
Marshall wrote:
> On Jan 18, 9:14 pm, "-CELKO-" <jcelko..._at_earthlink.net> wrote:
>
>>>> All of your continuum-based arguments are irrelevant to digital >>> >>>computers; they can't handle a continuum anyway. >> >>Things like pi and e are handled in many programming languages with >>tokens, much like the NaN.
>
>
> Some computer algebra systems work this way, but
> programming languages? I can't think of a single one.
> (And I can probably name more programming languages
> than most people you know.) In programming languages we
> pretty much universally use the nearest double precision
> floating point number instead of an abstract token. And
> that usually gives us a lot more precision than we're
> going to need.
>
>
>
>> **Symbolic** manipulations like you do on >>paper are just as good as computational ones!!
>
>
> IEEE floating point numbers *are* symbols. You
> probably meant algebraic manipulations. And I wouldn't
> say they are "as good"; they are better, if you are
> talking about precision. However for the vast
> majority of use cases, the extra precision isn't
> worth the trouble.
>
>
>
>>Your mindset is >>limiting the computer! Think about it.
>
>
> I have thought about it plenty, and my mindset
> is not the problem. The difficulties in handling a
> continuum are fundamental and intrinsic, and not
> a failure of imagination.
>
>
>
>>There are two ways to define a set: (1) enumeration >>(2) characteristic function.
>
>
> Only two?
>
> nat = zero | succ(nat)
>
>
>
>>This is important. Enumeration must list ALL of the values -- >>impossible in an infinite set. Characteristic functions must always be >>able to return TRUE or FALSE .. well, there are set that cannot have >>such functions, but ingore the graduate level math for now that puts in >>the 3VL that Chris Date hates so much >> >>The half-open interval is a (2) method and the Chronons are a (1) >>methods. Let's say that we have one DB with a precision of days like >>Chris Date and another DB tha tworeks on weeks start on Monday. What >>do we do about Tuesday? In model (1), we freak out and say there is no >>such element in this domain. In model (2) we see that it falls after >>Monday and before Wednesday because we have a test.
>
>
> Nothing in the last two paragraphs has any relevance to modeling
> continua that I can detect. Again, we model the reals with floating
> point, and it works just fine, even though the reals have the power
> of the continuum and floating point doesn't. If we want to bring it
> back to time, then we have to consider that time in the computer
> has a machine-defined resolution, and that makes time in the computer
> discrete, regardless of anything Einstein said about the real world.
> Java models time with a 64 bit int, and that gives you millisecond
> resolution over half a billion year span. That's good enough for my
> apps.
>
>
> Marshall
>
Marshall, shame on you. I believe Bob B has scolded you in the past for crediting Celko's bumpf with a response. It will only invite more mumbo-jumbo in the form of seemingly erudite terms he'll throw at you without establishing any useful context whatsoever. It is pretty flagrant when even I can recognize it. Oops, looks like I just did the same. Oh well, at least we can thank the people who made such a mess of SQL - if they'd done it right, he might be doing his damage in a more consequential field such as medicine or nuclear fusion.
p Received on Fri Jan 19 2007 - 13:08:38 CET