* An Example for Ada.Execution_Time @ 2010-12-27 18:26 anon 2010-12-28 2:31 ` BrianG 0 siblings, 1 reply; 17+ messages in thread From: anon @ 2010-12-27 18:26 UTC (permalink / raw) You ask for an example. Here is an example for packages (Tested using MaRTE): Ada.Execution_Time -- Defines Time type and main operations as -- well as the primary Clock for this type Ada.Execution_Time.Timers -- Links to Timers Altering this example one could use a number of timers to be set using different times. Or testing a number of algorithms using the timer. Also, I do have a Real_Time non-Task version that this example was based on. ------------------------------- -- Work.adb -- Main program with Ada.Integer_Text_IO ; with Ada.Text_IO ; with Work_Algorithm ; -- Contains worker algorithm with Work_Execution_Time ; -- Contains execution Timing routines procedure Work is use Ada.Integer_Text_IO ; use Ada.Text_IO ; use Work_Execution_Time ; Task_0 : Work_Task ; begin -- Work Initialize ( Work_Algorithm'Access ) ; Task_0.Start ( False ) ; -- Prints results of Test New_Line ; Put ( "Event occured " ) ; Put ( Item => Counter, Width => 3 ) ; Put_Line ( " Times." ) ; New_Line ; end Work ; ------------------------------- -- Work_Algorithm.ads procedure Work_Algorithm ; ------------------------------- -- Work_Algorithm.adb with Ada.Integer_Text_IO ; with Ada.Text_IO ; procedure Work_Algorithm is use Ada.Integer_Text_IO ; use Ada.Text_IO ; begin for Index in 0 .. 15 loop Put ( "Paused =>" ) ; Put ( Index ) ; New_Line ; delay 1.0 ; end loop ; end Work_Algorithm ; ------------------------------- -- Work.Execution_Time.ads with Ada.Execution_Time ; with Ada.Real_Time ; package Work_Execution_Time is type Algorithm_Type is access procedure ; task type Work_Task is entry Start ( Active : in Boolean ) ; end Work_Task ; Counter : Natural ; procedure Initialize ( A : in Algorithm_Type ) ; private Algorithm : Algorithm_Type ; Start_Time : Ada.Execution_Time.CPU_Time ; At_Time : Ada.Execution_Time.CPU_Time ; In_Time : Ada.Real_Time.Time_Span ; end Work_Execution_Time ; ------------------------------- -- Work_Execution_Time ; with Ada.Integer_Text_IO ; with Ada.Text_IO ; with Ada.Execution_Time ; with Ada.Execution_Time.Timers ; with Ada.Real_Time ; with Ada.Task_Identification ; package body Work_Execution_Time is use Ada.Execution_Time ; use Ada.Real_Time ; use Timers ; package D_IO is new Ada.Text_IO.Fixed_IO ( Duration ) ; package S_IO is new Ada.Text_IO.Integer_IO ( Ada.Real_Time.Seconds_Count ) ; protected Handlers is -- Handler: Single Event procedure Handler_1 ( TM : in out Timer ) ; -- Handler: Multple Event procedure Handler_2 ( TM : in out Timer ) ; end Handlers ; task body Work_Task is use Ada.Task_Identification ; ID : aliased Task_Id := Current_Task ; TM : Timers.Timer ( ID'Access ) ; Cancelled : Boolean := False ; begin Counter := 0 ; loop select Accept Start ( Active : in Boolean ) do if Active then Start_Time := Ada.Execution_Time.Clock ; At_Time := Start_Time + Milliseconds ( 5 ) ; Set_Handler ( TM, AT_Time, Handlers.Handler_2'Access ) ; else Start_Time := Ada.Execution_Time.Clock ; In_Time := Milliseconds ( 10 ) ; Set_Handler ( TM, In_Time, Handlers.Handler_2'Access ) ; end if ; Algorithm.all ; -- Execute Test algorithm Timers.Cancel_Handler ( TM, Cancelled ) ; end Start ; or terminate ; end select ; end loop ; end Work_Task ; -- -- Timer Event Routines -- protected body Handlers is -- Handler: Single Event procedure Handler_1 ( TM : in out Timer ) is Value : Time_Span ; Cancelled : Boolean ; begin Value := Time_Remaining ( TM ) ; Ada.Text_IO.Put ( "Timing Event Occured at " ) ; D_IO.Put ( To_Duration ( Value ) ) ; Ada.Text_IO.New_Line ; Counter := Counter + 1 ; Cancel_Handler ( TM, Cancelled ) ; end Handler_1 ; -- Handler: Multple Event procedure Handler_2 ( TM : in out Timer ) is Value : Time_Span ; begin Value := Time_Remaining ( TM ) ; Ada.Text_IO.Put ( "Timing Event Occured at " ) ; D_IO.Put ( To_Duration ( Value ) ) ; Ada.Text_IO.New_Line ; Counter := Counter + 1 ; Start_Time := Ada.Execution_Time.Clock ; In_Time := Ada.Real_Time.Milliseconds ( 10 ) ; Set_Handler ( TM, In_Time, Handlers.Handler_2'Access ) ; end Handler_2 ; end Handlers ; -- Initialize: Set Algorithm and Counter procedure Initialize ( A : in Algorithm_Type ) is begin Algorithm := A ; Counter := 0 ; end Initialize ; end Work_Execution_Time ; ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: An Example for Ada.Execution_Time 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 0 siblings, 2 replies; 17+ messages in thread From: BrianG @ 2010-12-28 2:31 UTC (permalink / raw) anon@att.net wrote: > You ask for an example. I'll assume I am the "you". (Since you don't specify and didn't relate it to the original thread.) I asked for: >> An algorithm comparison program might look like: >> >> with Ada.Execution_Time ; >> with Ada.Execution_Time.Timers ; >Given the below program, please add some of the missing details to >show how this can be useful without also "with Ada.Real_Time". >Neither Execution_Time or Execution_Time.Timers provides any value >that can be used directly. > >> >> procedure Compare_Algorithm is >...] You provided: > > Here is an example for packages (Tested using MaRTE): ... > with Ada.Execution_Time ; > with Ada.Real_Time ; ... > with Ada.Execution_Time ; > with Ada.Execution_Time.Timers ; > with Ada.Real_Time ; ... As the extracts show, you could not do what I asked for. You said in the original post you could do it with only the 2 Execution_Time 'with's. My entire point in this thread is that Execution_Time, as defined, is useless by itself. --BrianG ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: An Example for Ada.Execution_Time 2010-12-28 2:31 ` BrianG @ 2010-12-28 13:43 ` anon 2010-12-29 3:10 ` Randy Brukardt 1 sibling, 0 replies; 17+ messages in thread From: anon @ 2010-12-28 13:43 UTC (permalink / raw) In <ifbi5c$rqt$1@news.eternal-september.org>, BrianG <briang000@gmail.com> writes: >anon@att.net wrote: >> You ask for an example. >I'll assume I am the "you". (Since you don't specify and didn't relate >it to the original thread.) > >I asked for: > >> An algorithm comparison program might look like: > >> > >> with Ada.Execution_Time ; > >> with Ada.Execution_Time.Timers ; > >Given the below program, please add some of the missing details to > >show how this can be useful without also "with Ada.Real_Time". > >Neither Execution_Time or Execution_Time.Timers provides any value > >that can be used directly. > > > >> > >> procedure Compare_Algorithm is > >...] > >You provided: >> >> Here is an example for packages (Tested using MaRTE): >.... >> with Ada.Execution_Time ; >> with Ada.Real_Time ; >.... >> with Ada.Execution_Time ; >> with Ada.Execution_Time.Timers ; >> with Ada.Real_Time ; >.... > >As the extracts show, you could not do what I asked for. You said in >the original post you could do it with only the 2 Execution_Time >'with's. My entire point in this thread is that Execution_Time, as >defined, is useless by itself. > >--BrianG I changed the title so there was no need for reference lines Since 2006, a number of people have ask about Ada.Execution_Time package and no one has given a true example that uses that package for what it was created for. Until now! I gave you a simple example that can be easily modified to a more complex program. Problem: may be whats the maximum number of timers that can be allocated. and for your info (changes in work.adb) Task_0 : Work_Task ; Task_1 : Work_Task ; Task_2 : Work_Task ; Task_3 : Work_Task ; begin Initialize ( Work_Algorithm'Access ) ; Task_0.Start ( False ) ; Task_1.Start ( False ) ; Task_2.Start ( True ) ; -- just for a change Task_3.Start ( True ) ; ... will gives four tasks with four different timers. 2 timers that have the same interval 2 timers that changes the interval All that is needed is protect the Counter variable for each task and change the Counter print routine. And I will let others do that modification. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: An Example for Ada.Execution_Time 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 1 sibling, 1 reply; 17+ messages in thread From: Randy Brukardt @ 2010-12-29 3:10 UTC (permalink / raw) "BrianG" <briang000@gmail.com> wrote in message news:ifbi5c$rqt$1@news.eternal-september.org... ... > I asked for: > >> An algorithm comparison program might look like: > >> > >> with Ada.Execution_Time ; > >> with Ada.Execution_Time.Timers ; > >Given the below program, please add some of the missing details to > >show how this can be useful without also "with Ada.Real_Time". > >Neither Execution_Time or Execution_Time.Timers provides any value > >that can be used directly. This seems like a totally silly question. There are a lot of well-designed packages in Ada that don't do anything useful without at least one or more other packages. Indeed, if you consider "Standard" to be a separate package (and it is), there are hardly any packages that *don't* require some other package to be useful. More to the point, you probably need Ada.IO_Exceptions to use Ada.Directories effectively (use of any package without error handling is toy use); Ada.Streams.Stream_IO require use of Ada.Streams (a separate package, which you will need separate use clauses for even if you get it imported automatically); Ada.Strings.Maps aren't useful for anything unless you combine them with one of the string handling packages, and so on. Perhaps you would have been happier if Ada.Execution_Time had been a child of Ada.Real_Time (exactly as in the string case), but this wouldn't change anything. The odd thing is that Duration is defined in Standard, rather than some more appropriate package. Giving this some sort of religious importance is beyond silly... Randy. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: An Example for Ada.Execution_Time 2010-12-29 3:10 ` Randy Brukardt @ 2010-12-30 23:51 ` BrianG 2010-12-31 9:11 ` Dmitry A. Kazakov 2011-01-01 0:07 ` Randy Brukardt 0 siblings, 2 replies; 17+ messages in thread From: BrianG @ 2010-12-30 23:51 UTC (permalink / raw) Randy Brukardt wrote: > "BrianG" <briang000@gmail.com> wrote in message > news:ifbi5c$rqt$1@news.eternal-september.org... > ... >> >Neither Execution_Time or Execution_Time.Timers provides any value >> >that can be used directly. > > This seems like a totally silly question. > > Giving this some sort of religious importance is beyond > silly... > > Randy. Apparently, asking how a package, defined in the standard, was intended to be used is now a silly question, and asking for an answer to the question I originally asked (which was to clarify a previous response, not to provide an example of use) is a religious debate. I need to revise my definitions. I won't claim to be an expert on the RM, but I don't recall any other package (I did look at the ones you mention) that define a private type but don't provide operations that make that type useful (for some definition of 'use'). Ada.Directories doesn't require Ada.IO_Exceptions to use Directory_Entry_Type or Search_Type; Ada.Streams.Stream_IO doesn't require Ada.Streams (or Ada.Text_IO) to Create/Open/Read/etc. a File_Type. The only thing provided from a CPU_Time is a count in seconds, or another private type. 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? Perhaps either a "-" or To_Duration (and before anyone mentions duplicating the existing function, look at all of the Open/Close/Create/etc. for all the *_IO File_Types)? I wasn't asking for anything to be changed, merely "why" - because I originally thought there might be some use that I hadn't foreseen. Apparently not. (Give the RM definition, making it a child of Real_Time might make it seem more logical, I guess, but since CPU_Time is not really a time, and is not related to "real time" that doesn't seem to make any sense. I would think that would be all the more reason not to relate it to Ada.Real_Time.) --BrianG -- don't ask me -- I'm just improvising -- my illusion of careless flight -- can't you see -- my temperature's rising -- I radiate more heat than light ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: An Example for Ada.Execution_Time 2010-12-30 23:51 ` BrianG @ 2010-12-31 9:11 ` Dmitry A. Kazakov 2010-12-31 12:42 ` Niklas Holsti 2010-12-31 13:05 ` Simon Wright 2011-01-01 0:07 ` Randy Brukardt 1 sibling, 2 replies; 17+ messages in thread From: Dmitry A. Kazakov @ 2010-12-31 9:11 UTC (permalink / raw) 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. It is the time differences which are numeric. RM D.14 defines differences of CPU_Time as Time_Span. Time_Span is numeric. 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." It is not Ada.Execution_Time.Clock, it is: Ada.Execution_Time.Clock - CPU_Time_First There is a direct correspondence between two, yet they are conceptually different things. Happy New Year, -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: An Example for Ada.Execution_Time 2010-12-31 9:11 ` Dmitry A. Kazakov @ 2010-12-31 12:42 ` Niklas Holsti 2010-12-31 14:15 ` Dmitry A. Kazakov 2010-12-31 13:05 ` Simon Wright 1 sibling, 1 reply; 17+ messages in thread From: Niklas Holsti @ 2010-12-31 12:42 UTC (permalink / raw) 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 . @ . ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: An Example for Ada.Execution_Time 2010-12-31 12:42 ` Niklas Holsti @ 2010-12-31 14:15 ` Dmitry A. Kazakov 2010-12-31 18:57 ` Niklas Holsti 0 siblings, 1 reply; 17+ messages in thread From: Dmitry A. Kazakov @ 2010-12-31 14:15 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: An Example for Ada.Execution_Time 2010-12-31 14:15 ` Dmitry A. Kazakov @ 2010-12-31 18:57 ` Niklas Holsti 2011-01-01 13:39 ` Dmitry A. Kazakov 0 siblings, 1 reply; 17+ messages in thread From: Niklas Holsti @ 2010-12-31 18:57 UTC (permalink / raw) Dmitry A. Kazakov wrote: > 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. This is your view of what the English word "time" means. It is not based on any text in the RM, as far as I can see. (And I don't see what "recurrent process" has to do with it. Time could also be measured by radioactive decay, for example, which is not recurrent. Or by water clocks, also not recurrent as long as the water lasts. Using recurrent processes like oscillators, rotators, or orbiters is just a good way to measure time accurately by counting periods.) I have also tried to understand D.14 by interpreting its English words, like "time", but Randy says that this is "reading stuff that is not there". I don't entirely agree with him. For CPU_Time I think that D.14 shows sufficiently clearly that it has a numeric meaning. >> - 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. So, here the RM disagrees with your view that CPU_Time is not numeric, and your conclusion is that the RM is wrong? I am not convinced. > I suppose Time_Of (0) is the time when the task started because of D.14 > (13/2). Good point, I did not think of Time_Of (0) as a replacement for the (missing) CPU_Time_Zero constant. So, even if we don't agree on the numeric or non-numeric nature of CPU_Time, we do agree on how to use Ada.Execution_Time.Clock to compute the execution time. Good! -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: An Example for Ada.Execution_Time 2010-12-31 18:57 ` Niklas Holsti @ 2011-01-01 13:39 ` Dmitry A. Kazakov 2011-01-01 20:25 ` Niklas Holsti 0 siblings, 1 reply; 17+ messages in thread From: Dmitry A. Kazakov @ 2011-01-01 13:39 UTC (permalink / raw) On Fri, 31 Dec 2010 20:57:54 +0200, Niklas Holsti wrote: > Dmitry A. Kazakov wrote: >> 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. > > This is your view of what the English word "time" means. The English word "time" it has many meanings. > It is not based on any text in the RM, as far as I can see. It is based on the fact that RM always introduces a distinct type, when it means duration, time interval, period, e.g.: Duration, Time_Span. When RM uses a type named "time," it does not mean duration. This why it does not declare it numeric. It does not provide addition of times or multiplication by a scalar, which were appropriate if time were numeric or had the meaning duration. CPU_Time is handled accordingly. D.14 reuses Time_Span for intervals of CPU_Time, which stresses the difference. If this is not clean, then, not because CPU_Time is duration, it is because CPU_Time can be (and is) unrelated to the source of Ada.Real_Time.Time. Thus reusing Time_Span for its intervals questionable. It would be better to introduce a separate type for this, e.g. CPU_Time_Interval. Furthermore, the CPU_Time type should be local to the task, preventing its usage anywhere outside the task, while CPU_Time_Interval could be same for all tasks. >>> - 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. > > So, here the RM disagrees with your view that CPU_Time is not numeric, No it does not. "Zero" is not a numeric term, it denotes a specific element of a group (an additive identity element), zero object (an initial element). The number named "zero" is a special case, when the group is numeric. RM is consistent here, but, as I said, sloppy, because the zero element of a time system has a specific name: "epoch." RM uses this term in D.8, so should it do here. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: An Example for Ada.Execution_Time 2011-01-01 13:39 ` Dmitry A. Kazakov @ 2011-01-01 20:25 ` Niklas Holsti 2011-01-03 8:50 ` Dmitry A. Kazakov 0 siblings, 1 reply; 17+ messages in thread From: Niklas Holsti @ 2011-01-01 20:25 UTC (permalink / raw) Dmitry A. Kazakov wrote: > On Fri, 31 Dec 2010 20:57:54 +0200, Niklas Holsti wrote: > >> Dmitry A. Kazakov wrote: >>> 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. >> This is your view of what the English word "time" means. > > The English word "time" it has many meanings. Yes indeed.... Dmitry, I think we are arguing this point -- whether Ada.Execution_Time.CPU_Time has "numeric" values -- from different personal definitions of what "numeric" means, so we are not going to agree, and should stop. Meanwhile, I was reminded that the Ada RM actually defines "numeric type" as an integer or real type (RM 3.5(1)). Since CPU_Time and Time_Span etc. are all private types, and the RM does not say if they are implemented as integer or real types, we cannot know if they are "numeric types" using RM terms. Let's stop here, OK? > It is based on the fact that RM always introduces a distinct type, when it > means duration, time interval, period, e.g.: Duration, Time_Span. When RM > uses a type named "time," it does not mean duration. Yes, I agree that this is the RM principle, but I also think it is a different question. You may remember that Randy said that the ARG had discussions about type names for Ada.Execution_Time, and were not very happy with the name "CPU_Time" (as I understood Randy, at least). Note that RM D.14 does not say that CPU_Time is a "time type" as "time types" are defined in RM 9.6. In contrast, Ada.Real_Time.Time is a "time type". > D.14 reuses Time_Span for > intervals of CPU_Time, which stresses the difference. If this is not clean, > then, not because CPU_Time is duration, it is because CPU_Time can be (and > is) unrelated to the source of Ada.Real_Time.Time. I definitely don't agree that CPU_Time can be unrelated to the source of Ada.Real_Time.Time in an Ada system that is useful for real-time programming. Execution time may be measured with a different clock or timer than Ada.Real_Time.Time but the rates of the two times must be very closely the same while one task is executing. Otherwise Ada.Execution_Time would be useless. Perhaps you mean that CPU_Time is unrelated to Ada.Real_Time.Time over longer periods during which the task is sometimes executing, sometimes not. Then I agree that the two times increase at different rates, of course. > Thus reusing Time_Span for its intervals questionable. It would > be better to introduce a separate type for this, e.g. CPU_Time_Interval. I strongly disagree, because that would abandon the commensurability of CPU_Time (or its intervals) with real time and would destroy the usefulness of Ada.Execution_Time in real-time systems. > Furthermore, the CPU_Time type should be local to the task, It could be reasonable to have different CPU_Time types for each task. I can't immediately think of any reason for comparing or subtracting CPU_Time values across tasks. But I don't think this can be implemented in Ada. > preventing its usage anywhere outside the task, This would prevent or hamper the implementation of scheduling algorithms that monitor the execution times of several tasks. I object to it. > while CPU_Time_Interval could be same for all tasks. Definitely. And it must be the same as Ada.Real_Time.Time_Span or Duration for real-time scheduling purposes. > RM is consistent here, but, as I said, sloppy, because the zero element of > a time system has a specific name: "epoch." RM uses this term in D.8, so > should it do here. Manfully resisting the strong temptation to continue to argue about the "numeric" issue, based on your statements about "zero", I want to comment on this "epoch" thing. One of the differences between Ada.Real_Time.Time and Ada.Execution_Time.CPU_Time is that the epoch for the former is not specified in the RM. It follows that even if Ada.Real_Time.Time had a visibly numeric value, its meaning would be unknown to the program. In contrast, the epoch for CPU_Time is specified in the RM: the creation of the task, a point in real time known to the program. This brings CPU_Time closer to the meaning of Duration or Time_Span. If CPU_Time had a visibly numeric value, its meaning would be known: the total execution time of the task since the program created the task. I think the main reason why RM D.14 defines a specific type CPU_Time, instead of directly using Duration or Time_Span, is the large range required of CPU_Time: up to 50 years. Time_Span is required to hold only +- 1 hour, and Duration only +- 1 day. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: An Example for Ada.Execution_Time 2011-01-01 20:25 ` Niklas Holsti @ 2011-01-03 8:50 ` Dmitry A. Kazakov 0 siblings, 0 replies; 17+ messages in thread From: Dmitry A. Kazakov @ 2011-01-03 8:50 UTC (permalink / raw) On Sat, 01 Jan 2011 22:25:30 +0200, Niklas Holsti wrote: > Perhaps you mean that CPU_Time is unrelated to Ada.Real_Time.Time over > longer periods during which the task is sometimes executing, sometimes > not. I mean that 1. The corresponding clocks can be different. Ada cannot influence this. 2. The clocks are not synchronized, i.e. T1 on the Ada.Real_Time.Clock cannot be translated into T2 on the Ada.Execution_Time.Clock. > One of the differences between Ada.Real_Time.Time and > Ada.Execution_Time.CPU_Time is that the epoch for the former is not > specified in the RM. It follows that even if Ada.Real_Time.Time had a > visibly numeric value, its meaning would be unknown to the program. > > In contrast, the epoch for CPU_Time is specified in the RM: the creation > of the task, a point in real time known to the program. That does not define it either. An epoch cannot be defined otherwise than in terms of other clock. The task start time according to Ada.Real_Time.Time or Ada.Calendar.Time is unknown. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: An Example for Ada.Execution_Time 2010-12-31 9:11 ` Dmitry A. Kazakov 2010-12-31 12:42 ` Niklas Holsti @ 2010-12-31 13:05 ` Simon Wright 2010-12-31 14:14 ` Dmitry A. Kazakov ` (2 more replies) 1 sibling, 3 replies; 17+ messages in thread From: Simon Wright @ 2010-12-31 13:05 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > 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. It is the time > differences which are numeric. RM D.14 defines differences of CPU_Time as > Time_Span. Time_Span is numeric. This is certainly true. However, I remain surprised that .. even delving back to v1.2 of the AI .. the proposer found it necessary to have this type CPU_Time. The concept being looked for is the number of seconds during which *this* task was executing, still sounds like a Duration (OK, Time_Span if you must) to me. > 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." It is not Ada.Execution_Time.Clock, it is: > > Ada.Execution_Time.Clock - CPU_Time_First I don't _think_ that CPU_Time_First is actually defined as the value of Clock when the task starts (is initialized, put on the ready queue, whatever). D14(13/2) says "For each task, the execution time value is set to zero at the creation of the task."; however, zero is clearly not a value of CPU_Time, so I don't know what is meant. > There is a direct correspondence between two, yet they are > conceptually different things. I have no idea what's meant by CPU_Time, then! Seems to me it's a giant bug waiting to happen. It's clear that the CPU_Time of one task is incommensurate with the CPU_Time of another. Given that, what's it _for_? Of course, I competely understand that the Standard is what it is, and no one's going to change it at this point. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: An Example for Ada.Execution_Time 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 2 siblings, 0 replies; 17+ messages in thread From: Dmitry A. Kazakov @ 2010-12-31 14:14 UTC (permalink / raw) On Fri, 31 Dec 2010 13:05:06 +0000, Simon Wright wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > >> 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. It is the time >> differences which are numeric. RM D.14 defines differences of CPU_Time as >> Time_Span. Time_Span is numeric. > > This is certainly true. However, I remain surprised that .. even delving > back to v1.2 of the AI .. the proposer found it necessary to have this > type CPU_Time. The concept being looked for is the number of seconds > during which *this* task was executing, still sounds like a Duration > (OK, Time_Span if you must) to me. Yes, since the epoch is unambiguous: the task start. It does not make much sense to introduce execution time. Maybe a reason was that introducing clock returning time span or duration could be strange. > D14(13/2) says "For each task, the execution time value is set to zero > at the creation of the task."; however, zero is clearly not a value of > CPU_Time, so I don't know what is meant. Yes, Time_Of (0) seem to be the epoch. >> There is a direct correspondence between two, yet they are >> conceptually different things. > > I have no idea what's meant by CPU_Time, then! Seems to me it's a giant > bug waiting to happen. It's clear that the CPU_Time of one task is > incommensurate with the CPU_Time of another. Given that, what's it > _for_? That does not manifest any bug. Except that each task should have had its own CPU_Time type! Technically, it would be possible to inject an implicit declaration of a CPU_Time type in the declaration scope of each task. We could have a task-local "Standard/System" package encapsulating this and similar stuff. Though, nobody would care to do this. BTW, you could use CPU_Time as a simulation time within the task. E.g. you could have subtasks scheduled by the task. The scheduler would use the CPU_Time in order to activate/deactivate/re-schedule them, periodically according to the CPU_Time, rather than the system time. Happy New Year, -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: An Example for Ada.Execution_Time 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 2 siblings, 0 replies; 17+ messages in thread From: Robert A Duff @ 2010-12-31 14:24 UTC (permalink / raw) Simon Wright <simon@pushface.org> writes: > Of course, I competely understand that the Standard is what it is, and > no one's going to change it at this point. I haven't followed most of this (long!) discussion, but if somebody reports a bug to ada-comment, and the ARG agrees that it's sufficiently broken, then the standard will get changed. (Eventually. ARG is just a bunch of volunteers, who only meet for about 8 days per year.) - Bob ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: An Example for Ada.Execution_Time 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 2 siblings, 0 replies; 17+ messages in thread From: Simon Wright @ 2010-12-31 22:40 UTC (permalink / raw) Simon Wright <simon@pushface.org> writes: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: >> 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." It is not Ada.Execution_Time.Clock, it is: >> >> Ada.Execution_Time.Clock - CPU_Time_First > > I don't _think_ that CPU_Time_First is actually defined as the value > of Clock when the task starts (is initialized, put on the ready queue, > whatever). I think (from having had a look at GNAT GPL 2010's sources) that you are right to suggest Time_Of (0) in place of CPU_Time_First (in GNAT's implementation, the latter is Duration'First!). Or Niklas's suggestion of the missing CPU_Time_Zero. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: An Example for Ada.Execution_Time 2010-12-30 23:51 ` BrianG 2010-12-31 9:11 ` Dmitry A. Kazakov @ 2011-01-01 0:07 ` Randy Brukardt 1 sibling, 0 replies; 17+ messages in thread From: Randy Brukardt @ 2011-01-01 0:07 UTC (permalink / raw) "BrianG" <briang000@gmail.com> wrote in message news:ifj5u9$rr5$1@news.eternal-september.org... > Randy Brukardt wrote: >> "BrianG" <briang000@gmail.com> wrote in message >> news:ifbi5c$rqt$1@news.eternal-september.org... >> ... >>> >Neither Execution_Time or Execution_Time.Timers provides any value >>> >that can be used directly. >> >> This seems like a totally silly question. Giving this some sort of >> religious importance is beyond silly... >> >> Randy. > > > Apparently, asking how a package, defined in the standard, was intended to > be used is now a silly question, and asking for an answer to the question > I originally asked (which was to clarify a previous response, not to > provide an example of use) is a religious debate. I need to revise my > definitions. But you didn't ask how a package defined in the standard was intended to be used. You asked why you have to use another package (Ada.Real_Time) in order for it to be useful. And you've repeated that over and over and over like it was meaningful in some way. But that is pretty much the definition of a silly question. It's just the way the package was defined, and it doesn't matter beyond having to add one additional "with" clause. And that's pretty much irrelevant. In real Ada programs, there are many with clauses in the average compilation unit. In Janus/Ada, the number of withs averages 20 or so, and Claw programs are much higher than that. One could reduce those numbers by putting everything into a few massive packages, but those would be unweldy, poorly encapuslated, and close to unmaintainable. The need to add one extra with to use a real-time package just falls into the noise. Probably it would have been better to offer the option of retrieving a value in terms of Duration, but it is just not a significant difference. The answer to the "how do you use" question is simple and has been provided many times: use "-" to get a Time_Span, operate on that, and why that would be a problem to you or anyone else is beyond my comprehension. > I won't claim to be an expert on the RM, but I don't recall any other > package (I did look at the ones you mention) that define a private type > but don't provide operations that make that type useful (for some > definition of 'use'). Ada.Directories doesn't require Ada.IO_Exceptions > to use Directory_Entry_Type or Search_Type; Ada.Streams.Stream_IO doesn't > require Ada.Streams (or Ada.Text_IO) to Create/Open/Read/etc. a File_Type. > The only thing provided from a CPU_Time is a count in seconds, or another > private type. Here I completely disagree. If you plan to do anything *practical* with the Ada.Directories types, you'll have to use another package (at least Ada.Text_IO) to do something with the results. (Indeed, that is true of *all* Ada packages -- you have to do I/O somewhere or the results are irrelevant. And you are wrong about Stream_IO.Read; you have to use a Stream_Element_Array in order to do that, and that is in Ada.Streams, not in Stream_IO. In any case, I'm done wasting my time answering this question. It's obvious that you have lost you mind vis-a-vis this question, and there is no reason to waste any more time if/until you get it back. Do not feed the troll (even if the troll is someone that is otherwise reasonable). Randy. ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2011-01-03 8:50 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox