From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,61d8daec8bfa486e X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: An Example for Ada.Execution_Time Date: Fri, 31 Dec 2010 14:42:41 +0200 Organization: Tidorum Ltd Message-ID: <8o61e2FkdvU1@mid.individual.net> References: <1fb06tjt2dy1y$.1tkafcv9oya2w.dlg@40tude.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net 0KrKZw82pPB/7M0wxWPEjAFsTGfj+eC+CWPfKorvfYGT7Pc31T Cancel-Lock: sha1:COrQNyZzcqw498k6LaBw6ofG/DE= User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100328) In-Reply-To: <1fb06tjt2dy1y$.1tkafcv9oya2w.dlg@40tude.net> Xref: g2news1.google.com comp.lang.ada:16281 Date: 2010-12-31T14:42:41+02:00 List-Id: 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. > 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"). > I think this is the core of misunderstanding. The thing you have in mind is > "time interval since the task start according to the execution time clock." I agree with that. > It is not Ada.Execution_Time.Clock, It is, since: - by RM D.14 (17/2), Ada.Execution_Time.Clock returns the "current execution time" of the task, and - by RM D.14 (13/2), "the execution time value is set to zero at the creation of the task". Moreover, the range required of CPU_Time is "from the task start-up to 50 years of execution time later" (RM D.14 (20/2)). This, too, indicates that CPU_Time is not an absolute time point like Ada.Calendar.Time, but represents accumulated execution time (duration) from the creation of the task. However, the difference is irrelevant for the programmer, since the programmer can get visibly numeric values from CPU_Time only by computing the difference of two CPU_Time values as a Time_Span and then converting the Time_Span to a Duration. > it is: > > 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"). CPU_Time_First is just defined as the smallest value of CPU_Time, presumably according to the "<" operator. It might represent a negative execution time. The "range of mathematical integers" in D.14 (12/2) may include negative numbers -- at least nothing is said to exclude this possibility. I don't know why Ada.Execution_Time does not define a constant called CPU_Time_Zero; I think it should. Perhaps CPU_Time_First is meant to stand for zero, but this is not stated in D.14. Overall, I think there may be some confusion in D.14 regarding the interpretation of CPU_Time as absolute or relative to the task start. The fact that no CPU_Time_Zero is defined suggests that an "absolute" interpretation was meant, as does the absence of an operator that adds two CPU_Times to yield a CPU_Time sum. Other parts of D.14, such as the zero initialization at task creation, suggest the "relative to task start" meaning. 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. > Happy New Year, Also to all of you... -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .