• Trivial question: how to avoid confusing sec, min, hour and day in a pr

    From reinert@21:1/5 to All on Sat Sep 4 23:56:43 2021
    Anybody with good ideas on how (in a simplest possible way) to avoid to confuse between representation of time as seconds, minutes, hours and days in an Ada program? Standardize on internal representation of time as seconds (Float)? I will delay to use
    complex approaches for physical units.

    It is somewhere in my program natural/human to think in seconds whereas minutes or hours feels more natural at other places (so the numerics is "human"). Example to illustrate: heart rate is "natural" to give in number per minute (not in number per
    second, hour or day). Time on work is normally given by hours (not seconds) etc..

    reinert

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dmitry A. Kazakov@21:1/5 to reinert on Sun Sep 5 09:27:38 2021
    On 2021-09-05 08:56, reinert wrote:
    Anybody with good ideas on how (in a simplest possible way) to avoid to confuse between representation of time as seconds, minutes, hours and days in an Ada program?

    Just use the standard type Duration.

    It is somewhere in my program natural/human to think in seconds whereas minutes or hours feels more natural at other places (so the numerics is "human"). Example to illustrate: heart rate is "natural" to give in number per minute (not in number per
    second, hour or day). Time on work is normally given by hours (not seconds) etc..

    The user interface is responsible to convert anything to Duration and back.

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Niklas Holsti@21:1/5 to Dmitry A. Kazakov on Sun Sep 5 15:42:49 2021
    On 2021-09-05 10:27, Dmitry A. Kazakov wrote:
    On 2021-09-05 08:56, reinert wrote:
    Anybody with good ideas on how (in a simplest possible way) to avoid
    to confuse between representation of time as seconds, minutes, hours
    and days in an Ada program?

    Just use the standard type Duration.


    But note that:

    - Duration is a fixed-point type, not floating point, so it has a fixed resolution, Duration'Small.

    - The resolution and range of Duration are implementation-defined, and
    the standard does not guarantee much. RM 9.6(27) says:

    "The implementation of the type Duration shall allow representation of
    time intervals (both positive and negative) up to at least 86400 seconds
    (one day); Duration'Small shall not be greater than twenty milliseconds."

    (Aside: I wonder why this paragraph is not in RM A.1, "The Package
    Standard", where the Duration type is introduced.)

    If you want your code to be portable, define your own type for "time in seconds", choosing the properties your application needs.

    That said, I believe that GNAT versions typically provide a 64-bit
    Duration type that has enough precision and range for most applications
    dealing with times on human scales. But perhaps not on nuclear,
    geological or astrophysical scales.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From ldries46@21:1/5 to All on Mon Sep 6 09:20:27 2021
    Op 5-9-2021 om 9:27 schreef Dmitry A. Kazakov:
    On 2021-09-05 08:56, reinert wrote:
    Anybody with good ideas on how (in a simplest possible way) to avoid
    to confuse between representation of time as seconds, minutes, hours
    and days in an Ada program?

    Just use the standard type Duration.

    It is somewhere in my program natural/human to think in seconds
    whereas  minutes or hours feels more natural at other places (so the
    numerics is "human"). Example to illustrate: heart rate is "natural"
    to give in number per minute (not in number per second, hour or day).
    Time on work is normally given by hours (not seconds) etc..

    The user interface is responsible to convert anything to Duration and
    back.

    I agree with Dimitry but I think the problem  is far bigger and not only
    in Ada but in every computer language. You cannot use packages written
    by others if you do not know the dimensions they use. For instance in mechanical engineering in Europe there is a general use of cm while in
    other countries they use inches and in aircraft engineering they use in
    Europe mostly mm.
    In general the use of dimensioning system ( f.i. cgs -cm gram second) is different for different countries and application area's. Some factors
    used within calculations are even dependant in the dimensioning system.
    It would be a good idea if a package was developed that can solve all
    these problems for instance by doing the calculations in one of the
    possible dimensioning systems automagically presenting the results in
    the dimension you choose.
    Such a system must exist of a record for every value, that exist of at
    least  real values for the standard dimensioning system and the value in
    the dimensioning system you want, the factor between the two systems and
    the string containing the dimension, perhaps even more.
    There should be functions for "+", "-", "*", "/" and sqrt. The
    calculation should be done for the value in the standard dimension while
    the input and output must be in the wanted system. Also the strings and
    factors must be changed when necessary.
    I have already been thinking how but the problem are mostly in the
    strings and the fact that there are also dimensions that have  a lower
    limit (temperature) or have an offset (degrees Celcius, Reamur or
    Fahrenheit) or exist of several integer values (time).
    I think that the potential of Ada of being independent of an operating
    system can be extended that way to independent of the dimensioning system.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dmitry A. Kazakov@21:1/5 to All on Mon Sep 6 11:47:52 2021
    On 2021-09-06 09:20, ldries46 wrote:
    Op 5-9-2021 om 9:27 schreef Dmitry A. Kazakov:
    On 2021-09-05 08:56, reinert wrote:
    Anybody with good ideas on how (in a simplest possible way) to avoid
    to confuse between representation of time as seconds, minutes, hours
    and days in an Ada program?

    Just use the standard type Duration.

    It is somewhere in my program natural/human to think in seconds
    whereas  minutes or hours feels more natural at other places (so the
    numerics is "human"). Example to illustrate: heart rate is "natural"
    to give in number per minute (not in number per second, hour or day).
    Time on work is normally given by hours (not seconds) etc..

    The user interface is responsible to convert anything to Duration and
    back.

    I agree with Dimitry but I think the problem  is far bigger and not only
    in Ada but in every computer language. You cannot use packages written
    by others if you do not know the dimensions they use. For instance in mechanical engineering in Europe there is a general use of cm while in
    other countries they use inches and in aircraft engineering they use in Europe mostly mm.

    Why do you need that? If written in Ada, the value is of some separate
    numeric type you could not mix with other types.

    In general the use of dimensioning system ( f.i. cgs -cm gram second) is different for different countries and application area's. Some factors
    used within calculations are even dependant in the dimensioning system.
    It would be a good idea if a package was developed that can solve all
    these problems for instance by doing the calculations in one of the
    possible dimensioning systems automagically presenting the results in
    the dimension you choose.

    If calculations are involved, they are performed in SI, because
    otherwise you need factors in all formulae. And SI means no mm, but m,
    no km/h, but m/s etc.

    Such a system must exist of a record for every value, that exist of at least  real values for the standard dimensioning system and the value in
    the dimensioning system you want, the factor between the two systems and
    the string containing the dimension, perhaps even more.
    There should be functions for "+", "-", "*", "/" and sqrt.

    http://www.dmitry-kazakov.de/ada/units.htm

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From ldries46@21:1/5 to All on Mon Sep 6 15:06:17 2021
    Op 6-9-2021 om 11:47 schreef Dmitry A. Kazakov:
    On 2021-09-06 09:20, ldries46 wrote:
    Op 5-9-2021 om 9:27 schreef Dmitry A. Kazakov:
    On 2021-09-05 08:56, reinert wrote:
    Anybody with good ideas on how (in a simplest possible way) to
    avoid to confuse between representation of time as seconds,
    minutes, hours and days in an Ada program?

    Just use the standard type Duration.

    It is somewhere in my program natural/human to think in seconds
    whereas  minutes or hours feels more natural at other places (so
    the numerics is "human"). Example to illustrate: heart rate is
    "natural" to give in number per minute (not in number per second,
    hour or day). Time on work is normally given by hours (not seconds)
    etc..

    The user interface is responsible to convert anything to Duration
    and back.

    I agree with Dimitry but I think the problem  is far bigger and not
    only in Ada but in every computer language. You cannot use packages
    written by others if you do not know the dimensions they use. For
    instance in mechanical engineering in Europe there is a general use
    of cm while in other countries they use inches and in aircraft
    engineering they use in Europe mostly mm.

    Why do you need that? If written in Ada, the value is of some separate numeric type you could not mix with other types.

    I do need that because you can use the same packages in different
    trades. If you want to calculate the inertia of a construction dependent
    on the location or the trade you are working in you use different
    dimension systems. Indeed you can use SI but most mechanical engineers
    use the cm as a basic unit while aeronautical engineers use the mm as
    there basic unit and the result differ with 4 zero's. In the USA they
    probably use inches which differ some incredible factors. if an American
    uses a European standard HE100 element in his calculations he has first
    to recalculate all inertia values. This will lead to greater error possibilities.

    In general the use of dimensioning system ( f.i. cgs -cm gram second)
    is different for different countries and application area's. Some
    factors used within calculations are even dependant in the
    dimensioning system.
    It would be a good idea if a package was developed that can solve all
    these problems for instance by doing the calculations in one of the
    possible dimensioning systems automagically presenting the results in
    the dimension you choose.

    If calculations are involved, they are performed in SI, because
    otherwise you need factors in all formulae. And SI means no mm, but m,
    no km/h, but m/s etc.
    Sorry but It should perhaps be so but it is not. Programs made primarily
    for Aircraft engineering (f.i. CATIA 5/6) do use mm and your velocity
    clock in your car shows km/h and it registers the distance in km (in
    England and the USA mph and miles) In aircraft the Speed is often still measured in Knots (Nautical miles per hour). Maybe French aircraft will possibly show km/h. It is to hazardous to change this


    Such a system must exist of a record for every value, that exist of
    at least  real values for the standard dimensioning system and the
    value in the dimensioning system you want, the factor between the two
    systems and the string containing the dimension, perhaps even more.
    There should be functions for "+", "-", "*", "/" and sqrt.

       http://www.dmitry-kazakov.de/ada/units.htm


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From ldries46@21:1/5 to All on Mon Sep 6 16:13:36 2021
    Op 6-9-2021 om 15:43 schreef J-P. Rosen:
    Le 06/09/2021 à 15:06, ldries46 a écrit :
    If calculations are involved, they are performed in SI, because
    otherwise you need factors in all formulae. And SI means no mm, but
    m, no km/h, but m/s etc.
    Sorry but It should perhaps be so but it is not. Programs made
    primarily for Aircraft engineering (f.i. CATIA 5/6) do use mm and
    your velocity clock in your car shows km/h and it registers the
    distance in km (in England and the USA mph and miles) In aircraft the
    Speed is often still measured in Knots (Nautical miles per hour).
    Maybe French aircraft will possibly show km/h. It is to hazardous to
    change this

    Do not confuse computations with input/output. I agree with Dmitry,
    all computations should be performed in SI, with a (user selectable)
    choice of units for input and display.

    What I tried to say is just what J-P Rosen says. But in my experience
    (41 years in aircraft engineering) that is not so, every time you have
    to realise what the system your working with and you are forced to even
    use systems parallel. One of the points I made the mechanical
    engineering which often uses cm has standard profiles using mm HE110B is
    100mm high. That is the reason that I ask for a package which solves
    this problem for once and always and still gives the user the
    possibility to use all kind of dimesions

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From J-P. Rosen@21:1/5 to All on Mon Sep 6 15:43:45 2021
    Le 06/09/2021 à 15:06, ldries46 a écrit :
    If calculations are involved, they are performed in SI, because
    otherwise you need factors in all formulae. And SI means no mm, but m,
    no km/h, but m/s etc.
    Sorry but It should perhaps be so but it is not. Programs made primarily
    for Aircraft engineering (f.i. CATIA 5/6) do use mm and your velocity
    clock in your car shows km/h and it registers the distance in km (in
    England and the USA mph and miles) In aircraft the Speed is often still measured in Knots (Nautical miles per hour). Maybe French aircraft will possibly show km/h. It is to hazardous to change this

    Do not confuse computations with input/output. I agree with Dmitry, all computations should be performed in SI, with a (user selectable) choice
    of units for input and display.

    --
    J-P. Rosen
    Adalog
    2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
    Tel: +33 1 45 29 21 52
    https://www.adalog.fr

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dennis Lee Bieber@21:1/5 to All on Mon Sep 6 11:10:49 2021
    On Mon, 6 Sep 2021 16:13:36 +0200, ldries46 <bertus.dries@planet.nl>
    declaimed the following:

    100mm high. That is the reason that I ask for a package which solves
    this problem for once and always and still gives the user the
    possibility to use all kind of dimesions

    So... a reimplementation of the HP-48 UNITS module... Which requires all values to have a unit designation attached (eg: 1.6_km) and internally probably tracks the input unit but converts to base (SI) units for computations, then remaps to user input units for display.


    --
    Wulfraed Dennis Lee Bieber AF6VN
    wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From AdaMagica@21:1/5 to Dmitry A. Kazakov on Mon Sep 6 08:55:57 2021
    Dmitry A. Kazakov schrieb am Montag, 6. September 2021 um 11:47:54 UTC+2:
    http://www.dmitry-kazakov.de/ada/units.htm

    http://archive.adaic.com/tools/CKWG/Dimension/Dimension.html

    You might try to improve one of those packages for your needs.

    Don't know what HE110B is.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Shark8@21:1/5 to All on Wed Sep 8 15:00:44 2021
    On Monday, September 6, 2021 at 1:22:03 AM UTC-6, ldries46 wrote:
    It would be a good idea if a package was developed that can solve all
    these problems for instance by doing the calculations in one of the
    possible dimensioning systems automagically presenting the results in
    the dimension you choose.
    There's this package[-set] -- http://archive.adaic.com/tools/CKWG/Dimension/SI.html
    which is really pretty nice, and addresses the concern.

    I have already been thinking how but the problem are mostly in the strings
    Strings are terrible, avoid thinking in strings; be about the data first and foremost.
    Strings should, inasmuch as possible, be used only in your UI; e.g. given a MVC structure only the VIEW should deal with Strings.

    I think that the potential of Ada of being independent of an operating
    system can be extended that way to independent of the dimensioning system.
    Possibly, the problem is addressed interestingly in VHDL via "physical units" where you can define a type and then use units with a conversion factor.
    Example:

    Type Avoirdupois_Weight is range 0 to 1E9 units
    Grain;
    Dram = 27.34375 Grain;
    Ounce = 16.0 Dram;
    Pound = 16.0 Ounce;
    Ton = 2_000.0 Pound
    end units Avoirdupois_Weight;

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From reinert@21:1/5 to All on Sat Oct 23 23:52:17 2021
    Ada seems to guarantee that Duration covers 24 hours (?). What you do when you need to represent for example 5 years?

    reinert

    søndag 5. september 2021 kl. 09:27:41 UTC+2 skrev Dmitry A. Kazakov:
    On 2021-09-05 08:56, reinert wrote:
    Anybody with good ideas on how (in a simplest possible way) to avoid to confuse between representation of time as seconds, minutes, hours and days in an Ada program?
    Just use the standard type Duration.
    It is somewhere in my program natural/human to think in seconds whereas minutes or hours feels more natural at other places (so the numerics is "human"). Example to illustrate: heart rate is "natural" to give in number per minute (not in number per
    second, hour or day). Time on work is normally given by hours (not seconds) etc..
    The user interface is responsible to convert anything to Duration and back.

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From J-P. Rosen@21:1/5 to All on Sun Oct 24 09:24:46 2021
    Le 24/10/2021 à 08:52, reinert a écrit :
    Ada seems to guarantee that Duration covers 24 hours (?). What you do when you need to represent for example 5 years?
    Ada /guarantees/ at least 24 hours, since subtype Day_Duration
    corresponds to one day.

    In practice, Duration is much bigger. There is no requirement for it,
    since it obviously depends on the implementation. With Gnat, the
    following program:

    with Text_Io; use Text_Io;
    procedure Test_Duration is
    package Duration_Io is new Fixed_Io (Duration);
    use Duration_Io;
    begin
    null;
    Put ("duration'last:"); Put (Duration'Last); New_Line;
    Put ("days:") ; Put (Duration'Last / 86400); New_Line;
    Put ("years:") ; Put (Duration'Last / 86400 / 365.25); New_Line;
    end;

    gives:
    duration'last: 9223372036.854775807
    days: 106751.991167300
    years: 292.271023045

    --
    J-P. Rosen
    Adalog
    2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
    Tel: +33 1 45 29 21 52
    https://www.adalog.fr

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From G.B.@21:1/5 to reinert on Sun Oct 24 12:08:12 2021
    On 24.10.21 08:52, reinert wrote:
    Ada seems to guarantee that Duration covers 24 hours (?). What you do when you need to represent for example 5 years?

    The computing apparatus running the program might not always be on.
    "Always" is a reference to real time. So when it's turned off,
    a duration object in the program would incur lost time.

    So, some form of persistent storage is needed. I'd use values of types
    that allow computing offsets in time. Store these every now and then,
    e.g., as representing time passed.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jeffrey R.Carter@21:1/5 to J-P. Rosen on Sun Oct 24 12:39:34 2021
    On 10/24/21 09:24, J-P. Rosen wrote:

       Put ("years:") ;  Put (Duration'Last / 86400 / 365.25); New_Line;

    Still using the Julian calendar? In the Common calendar, the average
    length of a year is 365.2425 days (97 leap years every 400 years).

    years:        292.271023045

    Should be 292.277024627

    --
    Jeff Carter
    "Any extraterrestrials reported are always
    described as essentially human in form,
    which is so unlikely a possibility that we
    can dismiss it out of hand."
    Extraterrestrial Civilizations
    168

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon Wright@21:1/5 to reinert on Sun Oct 24 11:48:24 2021
    reinert <reinkor@gmail.com> writes:

    Ada seems to guarantee that Duration covers 24 hours (?). What you do
    when you need to represent for example 5 years?

    This must depend on your use case.

    I'd imagine you want to arrange for some event to happen 5 years in the
    future. The 'natural' way to do this might be, in a task,

    delay until Ada.Calendar.Clock + Duration'({5 years});

    but this comes up against two problems: first, as you note, that long a duration might not work, and second, the computer is almost certain to
    have been restarted by then, losing this task.

    The second problem could be solved by, e.g., keeping a backed-up
    time-ordered queue of events to be processed, with a task that delays
    until the next event is due.

    As for the first -- I think you may need to make an appropriate
    Duration'Last part of your compiler selection criteria.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Bj=c3=b6rn_Lundin?=@21:1/5 to All on Sun Oct 24 14:09:30 2021
    Den 2021-10-24 kl. 08:52, skrev reinert:
    Ada seems to guarantee that Duration covers 24 hours (?). What you do when you need to represent for example 5 years?

    we use a types of our own at work

    subtype Year_Type is Integer_2 range 1901 .. 2099;
    subtype Month_Type is Integer_2 range 01 .. 12;
    subtype Day_Type is Integer_2 range 01 .. 31;
    subtype Hour_Type is Integer_2 range 00 .. 23;
    subtype Minute_Type is Integer_2 range 00 .. 59;
    subtype Second_Type is Integer_2 range 00 .. 59;
    subtype Millisecond_Type is Integer_2 range 000 .. 999;

    subtype Week_Type is Integer_2 range 1 .. 53;
    subtype Year_Day_Type is Integer_2 range 1 .. 366;
    type Week_Day_Type is (
    Monday,
    Tuesday,
    Wednesday,
    Thursday,
    Friday,
    Saturday,
    Sunday);

    subtype Interval_Day_Type is Integer_4 range 0 .. Integer_4'Last;
    subtype Seconds_Type is Integer_4 range 0 .. Integer_4'Last;




    type Time_Type is tagged record
    Year : Year_Type;
    Month : Month_Type;
    Day : Day_Type;
    Hour : Hour_Type;
    Minute : Minute_Type;
    Second : Second_Type;
    Millisecond : Millisecond_Type;
    end record;

    and


    type Interval_Type is tagged record
    Days : Interval_Day_Type;
    Hours : Hour_Type;
    Minutes : Minute_Type;
    Seconds : Second_Type;
    Milliseconds : Millisecond_Type;
    end record;


    with functions and conversion to handle

    "+" "-" and some more ( Time - Time results in duration)


    we have a limited need of dates from the past and into the future, and
    ms is usually enough granularity.
    (This was designed in the late 80:ies but still usefull)

    This is to cover the needs of our administrative system


    The user interface is responsible to convert anything to Duration and back. >>
    --
    Regards,
    Dmitry A. Kazakov
    http://www.dmitry-kazakov.de

    and Dmitry is right in saying the user interface should convert to the
    units the user likes


    --
    Björn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)