Re: Temporal database - no end date

From: DBMS_Plumber <paul_geoffrey_brown_at_yahoo.com>
Date: 21 Jan 2007 19:40:07 -0800
Message-ID: <1169437207.634391.135760_at_38g2000cwa.googlegroups.com>


NENASHI, Tegiri wrote:
> If you talk of how present the Planck constant, one can use units of
> needed exactness. You cannot say in serious that one cannot present the
> Planck constant with the exactness of any number of digits that one can
> demand. The exactness of the Planck constant is a problem of measurement
> not presentation.

 Yes. This is what I am saying.

> Your argument is also without foundation in practice. It is hard to find
> the application in practice that needed the granularity of the Planck
> time. And if the application had needed the exactness of less than the
> Planck time, one can very simply take the granularity of the
> Planck_time/1000000 or even more granular. What is the problem ?

 Jeebus in a freakin donkey.

 Small words.

 We are talking about logical models. Model number 1 says - "There is a smallest size. We may not represent or reason about stuff smaller than the smaller size." Model number 2 says - "There is no smallest size."

 Take Planck_time/1000000 as your unit of granularity. Calculate the mean of a number of things represtented using the Planck_time/1000000 as your unit of granularity. There will be a residual that is smaller than Planck_time/1000000 as your unit of granularity. This residual you are obliged to discard.

  It Isn't Elephants All The Way Down!

> >> I work on Oracle

 Well. There's your problem right there.

> >> and I can affirm that the DATE in Oracle is one
> >> second of granularity. You say that 0.8 of the quantum is
> >> impossible, 0.8 of the day is impossible but 0.8 of 24*3600 is
> >> possible. 1/7 of 1000 is not exact (142) but the error is < 0.1 per
> >> cent. Why one can not select the granularity of chronon to achieve
> >> the exactness ? You can say, go and use floating point, but
> >> floating point is not exact too.
> >
> > The DDL book makes no claims about implementation. Nor should it.
> > It's a book that describes a logical model.
>
> What implementation ?

  There is no implementation, then. We agree. So, let's stop talking about one.

> It is the statement that I do not understand. What model ? I said that
> Oracle has the chronon of one second only like the illustration of the
> fact that the chronon of one secod is used by people with success for
> decades in Oracle. In the cases where the quantum of time must be more
> granular people develop the "chronon" by hand, and not use the
> automatic type of DATE.

 I thought we agreed not to talk about implementations? Why must you bring it up again?
>
> >
> >> I read about Snodgrass, and Snodgrass, he uses the name of chronon
> >> too. I want to know why you think that the chronon is bad in
> >> mathematic sense.
> >
> > Quanta are not 'bad'. They are not 'good'. The argument I am making
> > is merely that 'time quanta' (as described in the DDL book) represent
> > an innappropriate model for temporal reasoning because modeling time
> > as a continuum and temporal phenomenon using intervals over the
> > continuum is more general.
>
> Why it is an inappropriate model ?

  Please look up the word "because". Please attend a remedial course on english comprehension.

> Please give one example. I think
> your "mean" example is not good because you choosed a chronon of bad
> granularity.

  Pick ANY granularity. Find the mean of a set of values represented using that granularity. Then try to express your answer using the original granularity.

  Plan B. Don't pick a granularity. Pick a UNIT.

> If you think your "mean" example is good I do not have anymore to say
> because the problem is very very simple and you either do a hoax, pull
> the leg, or do not have simple mathematic knowledge to understand the
> simple problem.
>
>
> The model of chronons can have problems but the granularity, it is
> certainly not a problem.

   So it is elephants all the way down, then? Received on Mon Jan 22 2007 - 04:40:07 CET

Original text of this message