comp.lang.ada
 help / color / mirror / Atom feed
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Subject: Re: An Example for Ada.Execution_Time
Date: Fri, 31 Dec 2010 15:15:07 +0100
Date: 2010-12-31T15:15:05+01:00	[thread overview]
Message-ID: <1jmysfv0ifrrj$.h84gfj1gv0ht.dlg@40tude.net> (raw)
In-Reply-To: 8o61e2FkdvU1@mid.individual.net

On Fri, 31 Dec 2010 14:42:41 +0200, Niklas Holsti wrote:

> Dmitry A. Kazakov wrote:
>> On Thu, 30 Dec 2010 18:51:30 -0500, BrianG wrote:
>> 
>>> Since D.16 defines CPU_Time as if it were a numeric value, is it too 
>>> much to ask why a conversion to some form of numeric value wasn't 
>>> provided?
>> 
>> But time is not a number and was not defined as if it were.
> 
> You keep saying that, Dmitri, but your only argument seems to be the 
> absence of some operators like addition for CPU_Time. Since CPU_Time is 
> private, we cannot tell if this absence means that the D.14 authors 
> considered the type non-numeric, or just considered the operators 
> unnecessary for the intended uses.

No, the argument is that time is a state of some recurrent process, like
the position of an Earth's meridian relatively to the Sun. This state is
not numeric, it could be numeric though. That depends on the nature of the
process. 

>> It is the time
>> differences which are numeric. RM D.14 defines differences of CPU_Time as
>> Time_Span. Time_Span is numeric.
> 
> CPU_Time is logically numeric, since its "values correspond one-to-one 
> with a .. range of mathematical integers" by RM D.14 (12/2). Moreover, 
> RM D.14 (13/2) uses the symbol "I" to stand for a value of CPU_Time, and 
> then uses "I" as a factor that multiplies a floating-point number. So 
> "I" clearly stands for a number (one of the "mathematical integers").

No, this stands only for countability. Time is not a number, it can be
represented in the form Epoch + n * Interval, where n is a number.

> - by RM D.14 (13/2), "the execution time value is set to zero at the 
> creation of the task".

I agree that here RM is sloppy. They should rather talk about an "epoch"
rather than "zero," if they introduced CPU_Time as a time.
 
>>    Ada.Execution_Time.Clock - CPU_Time_First
> 
> No. There is no rule in D.14 that makes CPU_Time_First equal to the 
> CPU_Time at the start of a task (which by D.14 (13/2) is "zero"). 

OK, I agree with that. Correction:

   Ada.Execution_Time.Clock - Ada.Execution_Time.Time_Of (0)

> As far as I can tell, the only sure way to get the task's execution time 
> as a Time_Span or Duration is to read and store the value of 
> Ada.Execution_Time.Clock at the start of the task, and then use that in 
> Dmitry's subtraction formula instead of CPU_Time_First.

I suppose Time_Of (0) is the time when the task started because of D.14
(13/2).

Happy New Year,

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



  reply	other threads:[~2010-12-31 14:15 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-27 18:26 An Example for Ada.Execution_Time anon
2010-12-28  2:31 ` BrianG
2010-12-28 13:43   ` anon
2010-12-29  3:10   ` Randy Brukardt
2010-12-30 23:51     ` BrianG
2010-12-31  9:11       ` Dmitry A. Kazakov
2010-12-31 12:42         ` Niklas Holsti
2010-12-31 14:15           ` Dmitry A. Kazakov [this message]
2010-12-31 18:57             ` Niklas Holsti
2011-01-01 13:39               ` Dmitry A. Kazakov
2011-01-01 20:25                 ` Niklas Holsti
2011-01-03  8:50                   ` Dmitry A. Kazakov
2010-12-31 13:05         ` Simon Wright
2010-12-31 14:14           ` Dmitry A. Kazakov
2010-12-31 14:24           ` Robert A Duff
2010-12-31 22:40           ` Simon Wright
2011-01-01  0:07       ` Randy Brukardt
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox