Re: An Example for Ada.Execution_Time

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

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