* Another Idea for Ada 20XX @ 2001-12-02 16:01 James Rogers 2001-12-02 16:38 ` Preben Randhol ` (5 more replies) 0 siblings, 6 replies; 26+ messages in thread From: James Rogers @ 2001-12-02 16:01 UTC (permalink / raw) In scientific terms a measurement is done in terms of some unit. For instance, distance is in meters, microns, feet or furlongs. Speed is then calculated as a distance per unit time. Acceleration is the second derivative of speed. I would like to have this notion of measurement units and their relationships supported in a language. This would require the language to perform unit analysis while performing static or run-time calculations. Because of the added computational overhead, there must be a way to choose or reject unit analysis for defined types. Perhaps a new keyword for unit-analyzed types could be introduced, along the lines of the keyword "tagged" added to Ada 95. A unit- analyzed type would carry its own unit description tag to facilitate unit analysis. Any numeric type without such a tag would not be subject to unit analysis. Possible declarative syntax might be: type Meters is unit range (0.0..1.0E380); type Hours is unit range (0.0..9.99E30); type Speed is unit(Meters / Hours); The advantage for the software developer is in the usage: Vehicle_Speed : Speed; Track_Distance : Meters; Lap_Time : Hours; Speed := Track_Distance / Lap_Time; This approach would allow the appropriate mixing of data types, which is currently forbidden by Ada, in a meaningful and correct manner. I know this proposal places a heavy burden upon compiler writers. I also suspect it would be very useful for ensuring the correctness of programs, particularly in embedded systems. Note that a lot of the unit analysis could be performed statically. This would allow minimal performance penalty at run time. Jim Rogers Colorado Springs, Colorado USA ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Another Idea for Ada 20XX 2001-12-02 16:01 Another Idea for Ada 20XX James Rogers @ 2001-12-02 16:38 ` Preben Randhol 2001-12-02 22:26 ` James Rogers 2001-12-02 21:19 ` Patrick Hohmeyer ` (4 subsequent siblings) 5 siblings, 1 reply; 26+ messages in thread From: Preben Randhol @ 2001-12-02 16:38 UTC (permalink / raw) On Sun, 02 Dec 2001 16:01:22 GMT, James Rogers wrote: > type Meters is unit range (0.0..1.0E380); > type Hours is unit range (0.0..9.99E30); > type Speed is unit(Meters / Hours); Shouldn't these also be allowed to be negative? Preben -- () Join the worldwide campaign to protect fundamental human rights. '||} {||' http://www.amnesty.org/ ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Another Idea for Ada 20XX 2001-12-02 16:38 ` Preben Randhol @ 2001-12-02 22:26 ` James Rogers 0 siblings, 0 replies; 26+ messages in thread From: James Rogers @ 2001-12-02 22:26 UTC (permalink / raw) Preben Randhol wrote: > > On Sun, 02 Dec 2001 16:01:22 GMT, James Rogers wrote: > > type Meters is unit range (0.0..1.0E380); > > type Hours is unit range (0.0..9.99E30); > > type Speed is unit(Meters / Hours); > > Shouldn't these also be allowed to be negative? Under certain circumstances units do make sense as negative values. Sometimes they do not. I simply tried to supply a possible syntax example, not all possible examples. Jim Rogers Colorado Springs, Colorado USA ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Another Idea for Ada 20XX 2001-12-02 16:01 Another Idea for Ada 20XX James Rogers 2001-12-02 16:38 ` Preben Randhol @ 2001-12-02 21:19 ` Patrick Hohmeyer 2001-12-02 21:26 ` Lutz Donnerhacke ` (3 subsequent siblings) 5 siblings, 0 replies; 26+ messages in thread From: Patrick Hohmeyer @ 2001-12-02 21:19 UTC (permalink / raw) James Rogers wrote : > In scientific terms a measurement is done in terms of some unit. > For instance, distance is in meters, microns, feet or furlongs. > Speed is then calculated as a distance per unit time. Acceleration > is the second derivative of speed. Acceleration is the second derivative of *distance*. ;-) > The advantage for the software developer is in the usage: > > Vehicle_Speed : Speed; > Track_Distance : Meters; > Lap_Time : Hours; > > Speed := Track_Distance / Lap_Time; > > This approach would allow the appropriate mixing of data types, which > is currently forbidden by Ada, in a meaningful and correct manner. > Hmm, this can very easly be achived with overloading of "/" : function "/" (Dist : Meters; Time : Hours) return Speed is --... And I have a huge problem with the name of the type Speed. Speed is not a unit, but an concept. Would be more interesting : type Distance is basic concept with basic unit Meters; type Time is basic concept with basic unit Seconds; type Speed is concept (Distance / Time); Vehicle_Speed : Speed; -- ok Track_Distance1 : Meters; -- ok Track_Distance2 : Meters := 12.5; -- ok Lap_Time1 : Time; -- ok Lap_Time2 : Time := Seconds(34.3); -- ok Lap_Time3 : Time := 34.3; -- 2 possibles reactions : -- 1. won't compile as the unit isn't specified !!! (my favor) -- 2. uses the basic unit for the concept (Seconds) -- (but generates a compiler warning) Vehicle_Speed := Track_Distance1 / Lap_Time1; --ok Internally a concept type would be something as record Value : Double; Unit : Unit_type; end record; Unit somehow describes how we can transform the value into a value in the basic units. (an access to a function?) and vice-versa. The great part are unit extentions : type Hours is Time unit 3600 Seconds; S : Seconds := 3954.3; H : Hours := S; And the compiler would automagicly put 3954.3 / 3600 into H. As would the cast Hours(S) return 3954.3 / 3600; Especially for Space programs between US and Europe this would be a *huge* benefit. Just declare : type Inchs is Distance unit x Meters; and the compiler will do all unit conversions for you. And of course : type Temperature is basic concept with basic unit Kelvin; type Celsius is Temperature unit 1 Kelvin + 273.15; And a non-basic concept : type Mass is basic concept with basic unit Kilogram; type Acceleration is concept Speed / Time; type Force is concept Mass * Acceleration; type Newton is Force unit 1 (Kilogram * Meters * Seconds**(-2)); (Note that : type Newton is Force unit 1 (Kilogram * Meters * Seconds**(-1) * Hours**(-1)); would also be syntaxly correct, you can mix 2 time units in a composed unit.) I think that this could be fun, but may be to complicated to implement and if you really need it, can already be done with a record and an access to fonction for the unit type, and a lot of overloaded functions. But what do you think ? -- Patrick Hohmeyer ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Another Idea for Ada 20XX 2001-12-02 16:01 Another Idea for Ada 20XX James Rogers 2001-12-02 16:38 ` Preben Randhol 2001-12-02 21:19 ` Patrick Hohmeyer @ 2001-12-02 21:26 ` Lutz Donnerhacke 2001-12-02 23:49 ` Patrick Hohmeyer 2001-12-03 0:21 ` Robert C. Leif, Ph.D. ` (2 subsequent siblings) 5 siblings, 1 reply; 26+ messages in thread From: Lutz Donnerhacke @ 2001-12-02 21:26 UTC (permalink / raw) * James Rogers wrote: >In scientific terms a measurement is done in terms of some unit. >For instance, distance is in meters, microns, feet or furlongs. >Speed is then calculated as a distance per unit time. Acceleration >is the second derivative of speed. >Note that a lot of the unit analysis could be performed statically. >This would allow minimal performance penalty at run time. http://www.iks-jena.de/mitarb/lutz/ada/units/ I�m going to provide automatic unit optimization. Please stay tuned. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Another Idea for Ada 20XX 2001-12-02 21:26 ` Lutz Donnerhacke @ 2001-12-02 23:49 ` Patrick Hohmeyer 2001-12-03 6:06 ` Wilhelm Spickermann ` (2 more replies) 0 siblings, 3 replies; 26+ messages in thread From: Patrick Hohmeyer @ 2001-12-02 23:49 UTC (permalink / raw) And Lutz Donnerhacke has spoken : > * James Rogers wrote: > >In scientific terms a measurement is done in terms of some unit. > >For instance, distance is in meters, microns, feet or furlongs. > >Speed is then calculated as a distance per unit time. Acceleration > >is the second derivative of speed. > > >Note that a lot of the unit analysis could be performed statically. > >This would allow minimal performance penalty at run time. > > http://www.iks-jena.de/mitarb/lutz/ada/units/ > > I�m going to provide automatic unit optimization. Please stay tuned. Interesting approach, but at first glance I dont see how you'll solve the Celsius = Kelvin + 273.15 problem. This solution seams only to work with units where zero in one unit equals zero in the other as well. I think an approach : type Conversion is access function(value : Accuracy) return Accuracy; type Unit_Description is record toSI : Conversion; fromSI : Conversion; -- some text ??? end record; type Quantity is tagged record value : Accuracy; Unit : Unit_Description; end record; offers more flexibility than your idea of a Dimension. -- Patrick Hohmeyer ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Another Idea for Ada 20XX 2001-12-02 23:49 ` Patrick Hohmeyer @ 2001-12-03 6:06 ` Wilhelm Spickermann 2001-12-03 8:58 ` Lutz Donnerhacke 2001-12-03 13:40 ` Thomas Koenig 2 siblings, 0 replies; 26+ messages in thread From: Wilhelm Spickermann @ 2001-12-03 6:06 UTC (permalink / raw) To: comp.lang.ada --On Sunday, December 02, 2001 18:49:24 -0500 Patrick Hohmeyer <pi3_1415926536@yahoo.ca> wrote: > Interesting approach, but at first glance I dont see how > you'll solve the Celsius = Kelvin + 273.15 problem. > > This solution seams only to work with units where zero in one > unit equals zero in the other as well. This problem is not a programming problem -- and it has been solved already. Units in physics may not carry any offset information as they are not capable to do this. Doing it would destroy the fundamental concept of equality being a replacement permission: "The outside temperature is 10 degrees celsius, that´s 10 degrees celsius less than the temperature of my room.". If 10 Degrees Celsius would be equal to 283.15 Kelvin, it would have to be possible to replace *both* occurences. Giving: "The outside temperature is 283.15 Kelvin, that´s 283.15 Kelvin less than the temperature of my room." Wow, too hot for me. The solution is (IFAIR it´s from the International Conference on Measurements and Units... in 1972): "The temperature is 10 Degrees Celsius" is just a lax abbreviation for: "The celsiustemperature is 10 Kelvin". So it´s a different physical value with the same unit and not the same physical value with a different unit. Note that the conversion between celsius temperature and absolute temperature can now be expressed in a simple equation: TC = TA + 273.15 K The same holds for pseudo units like the old german "atü" (car tires) and "Vss"(TV electronics). So it´s not a problem of unit conversion, but a problem occuring in the user interface, where you will have to deal with pseudo units. Wilhelm ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Another Idea for Ada 20XX 2001-12-02 23:49 ` Patrick Hohmeyer 2001-12-03 6:06 ` Wilhelm Spickermann @ 2001-12-03 8:58 ` Lutz Donnerhacke 2001-12-03 13:40 ` Thomas Koenig 2 siblings, 0 replies; 26+ messages in thread From: Lutz Donnerhacke @ 2001-12-03 8:58 UTC (permalink / raw) * Patrick Hohmeyer wrote: >And Lutz Donnerhacke has spoken : >> I�m going to provide automatic unit optimization. Please stay tuned. > >Interesting approach, but at first glance I dont see how >you'll solve the Celsius = Kelvin + 273.15 problem. Calculation is only possible in SI. >I think an approach : [Conversion] Work in progress. But using a sligthly different approach. A new html version is only generated if the program runs all the tests successfully. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Another Idea for Ada 20XX 2001-12-02 23:49 ` Patrick Hohmeyer 2001-12-03 6:06 ` Wilhelm Spickermann 2001-12-03 8:58 ` Lutz Donnerhacke @ 2001-12-03 13:40 ` Thomas Koenig 2 siblings, 0 replies; 26+ messages in thread From: Thomas Koenig @ 2001-12-03 13:40 UTC (permalink / raw) Patrick Hohmeyer <pi3_1415926536@yahoo.ca> wrote: >And Lutz Donnerhacke has spoken : >> I�m going to provide automatic unit optimization. Please stay tuned. >Interesting approach, but at first glance I dont see how >you'll solve the Celsius = Kelvin + 273.15 problem. I don't think that this is a problem that wants solving as badly as the case of normal units. Define Celsius as a separate type, and provide conversion functions to and from Kelvin. ^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: Another Idea for Ada 20XX 2001-12-02 16:01 Another Idea for Ada 20XX James Rogers ` (2 preceding siblings ...) 2001-12-02 21:26 ` Lutz Donnerhacke @ 2001-12-03 0:21 ` Robert C. Leif, Ph.D. 2001-12-03 0:35 ` Robert Dewar 2001-12-03 14:56 ` Another Idea for Ada 20XX Mark Lundquist 5 siblings, 0 replies; 26+ messages in thread From: Robert C. Leif, Ph.D. @ 2001-12-03 0:21 UTC (permalink / raw) To: comp.lang.ada From: Bob Leif To: James Rogers et al. A package to do this, A Broad-Based Environment for Test (ABBET), was created by William A Whitaker, Ph.D. There is also a collection of packages by Dmitry A. Kazakov. I believe that it might be possible to have either the compiler optimize away the unit checking for objects where the units are constant and/or create a class of assertions that are only checked at compile time. Fresh ideas on this subject should have a high priority for Ada 200X. -----Original Message----- From: comp.lang.ada-admin@ada.eu.org [mailto:comp.lang.ada-admin@ada.eu.org]On Behalf Of James Rogers Sent: Sunday, December 02, 2001 8:01 AM To: comp.lang.ada@ada.eu.org Subject: Another Idea for Ada 20XX In scientific terms a measurement is done in terms of some unit. For instance, distance is in meters, microns, feet or furlongs. Speed is then calculated as a distance per unit time. Acceleration is the second derivative of speed. I would like to have this notion of measurement units and their relationships supported in a language. This would require the language to perform unit analysis while performing static or run-time calculations. Because of the added computational overhead, there must be a way to choose or reject unit analysis for defined types. Perhaps a new keyword for unit-analyzed types could be introduced, along the lines of the keyword "tagged" added to Ada 95. A unit- analyzed type would carry its own unit description tag to facilitate unit analysis. Any numeric type without such a tag would not be subject to unit analysis. Possible declarative syntax might be: type Meters is unit range (0.0..1.0E380); type Hours is unit range (0.0..9.99E30); type Speed is unit(Meters / Hours); The advantage for the software developer is in the usage: Vehicle_Speed : Speed; Track_Distance : Meters; Lap_Time : Hours; Speed := Track_Distance / Lap_Time; This approach would allow the appropriate mixing of data types, which is currently forbidden by Ada, in a meaningful and correct manner. I know this proposal places a heavy burden upon compiler writers. I also suspect it would be very useful for ensuring the correctness of programs, particularly in embedded systems. Note that a lot of the unit analysis could be performed statically. This would allow minimal performance penalty at run time. Jim Rogers Colorado Springs, Colorado USA ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Another Idea for Ada 20XX 2001-12-02 16:01 Another Idea for Ada 20XX James Rogers ` (3 preceding siblings ...) 2001-12-03 0:21 ` Robert C. Leif, Ph.D. @ 2001-12-03 0:35 ` Robert Dewar 2001-12-03 1:33 ` James Rogers 2001-12-03 14:56 ` Another Idea for Ada 20XX Mark Lundquist 5 siblings, 1 reply; 26+ messages in thread From: Robert Dewar @ 2001-12-03 0:35 UTC (permalink / raw) James Rogers <jimmaureenrogers@worldnet.att.net> wrote in message news:<3C0A5054.E74A82E7@worldnet.att.net>... > I would like to have this notion of measurement units and > their relationships supported in a language. James, if you are interested in proposing something here, you need first to do some homework. This subject has been *extensively* discussed in the past, including the analysis and discussion of several different schemes for getting units analysis of the kind you are proposing within the current language. I suggest you study these existing schemes first, to see whether a) they meet your requirements b) if they do not, exactly why not There have also been proposals for language extensions that have been thoroughly discussed in the past, and you should dig up these discussions. I realize that there are many new players on CLA who don't necesarily have the history here, but this is definitely an area where it makes no sense to start another discussion from scratch. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Another Idea for Ada 20XX 2001-12-03 0:35 ` Robert Dewar @ 2001-12-03 1:33 ` James Rogers 2001-12-03 12:34 ` Dirk Dickmanns 0 siblings, 1 reply; 26+ messages in thread From: James Rogers @ 2001-12-03 1:33 UTC (permalink / raw) Robert Dewar wrote: > > James, if you are interested in proposing something here, > you need first to do some homework. This subject has been > *extensively* discussed in the past, including the analysis > and discussion of several different schemes for getting units analysis > of the kind you are proposing within the > current language. Thank you for the notice. I hoped that someone had already done work in this area. I will look into the histories as well as current language proposals. Again, thank you. > I realize that there are many new players on CLA who don't > necesarily have the history here, but this is definitely an area where > it makes no sense to start another discussion > from scratch. Jim Rogers Colorado Springs, Colorado USA ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Another Idea for Ada 20XX 2001-12-03 1:33 ` James Rogers @ 2001-12-03 12:34 ` Dirk Dickmanns 2001-12-04 19:02 ` Unit handling (was: Another Idea for Ada 20XX) Wilhelm Spickermann 0 siblings, 1 reply; 26+ messages in thread From: Dirk Dickmanns @ 2001-12-03 12:34 UTC (permalink / raw) James Rogers schrieb: > I will look into the histories as well as current language proposals. Besides the work of Lutz, I have: http://users.erols.com/whitaker/iss_418.htm http://www.dmitry-kazakov.de/ada/units.htm Regards, Dirk -- Dirk.Dickmanns@BMW.de, Dr.rer.nat. xx49-89-382-46422, Fax -44988 Computer Vision and Sensor Data Fusion BMW Group, Vehicle Research, EV-20, D-80788 Munich ^ permalink raw reply [flat|nested] 26+ messages in thread
* Unit handling (was: Another Idea for Ada 20XX) 2001-12-03 12:34 ` Dirk Dickmanns @ 2001-12-04 19:02 ` Wilhelm Spickermann 0 siblings, 0 replies; 26+ messages in thread From: Wilhelm Spickermann @ 2001-12-04 19:02 UTC (permalink / raw) To: comp.lang.ada --On Monday, December 03, 2001 13:34:09 +0100 Dirk Dickmanns <Dirk.Dickmanns@BMW.de> wrote: ... > Besides the work of Lutz, I have: > http://users.erols.com/whitaker/iss_418.htm > http://www.dmitry-kazakov.de/ada/units.htm > May I add some of my ideas here? They could be realized as an optional ASIS program checker or as a compiler component and would not have any execution time penalty or require the tools to be available to do the compilation. As unit consistency is a program property, it´s not really necessary to have the tool on every platform and every site. The idea is to define the basic SI-Units as named numbers with value 1.0 and using values like "5.7 * meter / second" in the program. (The compiler can easily optimize such expressions.) A pragma for use by ASIS (or the compiler) defines which Units are to be viewed as basic. Every variable, constant, parameter or named number will be associated with a derived unit upon the first assignment seen, by tracking the operations down to the basic units and all following assignments will be required to lead to the same result. Additionally all operations will be checked for consistency. (As others have already pointed out, there are not too many operations to be considered, as operations like taking the logarithm of something can never be applied to something having a unit) An additional ASIS-pragma can assign a derived unit to a variable or parameter where the unit is not associated implicitly by an initial or default value. A first sketch using SI as an example: package Units is -- The 7 SI units: Meter : constant := 1.0; ... pragma Define_Unit (Meter, Kilogram, Second, Ampere, Kelvin, Candela, Mole); ... -- SI derived units: Newton : constant := Meter * Kilogram / Second**2; ... -- SI accepted derived units: Liter : constant := 1.0e-3 * Meter**3; ... end Units; (No special handling for the child units needed, they just collect some definitions and try to convince programmers, that that it´s a bad idea to define a factor "Billion" etc.) package Units.More is -- Defined (not experimentally determined) units. Foot : constant := 0.3048 * Meter; Foot_US_Survey : constant := Foot / 0.999998; ... -- experimentally determined units / constants Electron_Volt : constant := 1.602_177_33e-19 * Joule; ... end Units.More; package Units.Factors is ... Kilo : constant := 1.0E3; ... Billion_US_FR : constant := 1.0E9; Billion_OTH : constant := 1.0E12; ... Kilo_Binary : constant := 2.0**10; ... end Units.Factors; I think this notation is readable and could be helpful even without any tool to do the checks. It does not create any runtime penalties. It should be possible to implement the checker in ASIS or as an additional compiler component which may be switched on or off. It´s not meant as a proposal for Ada 20XX, but if someone would like to view it as one: it would only introduce conflicts in the two new pragma names. (It will however not be able to handle units like "decibels" or "degrees celsius". I view these as pseudo units which only make mathematical reasoning impossible. They should occur only in the user interface as common expressions, but I´ve written that in another mail.) Wilhelm ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Another Idea for Ada 20XX 2001-12-02 16:01 Another Idea for Ada 20XX James Rogers ` (4 preceding siblings ...) 2001-12-03 0:35 ` Robert Dewar @ 2001-12-03 14:56 ` Mark Lundquist 2001-12-03 15:12 ` Lutz Donnerhacke 2001-12-03 17:00 ` Another Idea for Ada 20XX chris.danx 5 siblings, 2 replies; 26+ messages in thread From: Mark Lundquist @ 2001-12-03 14:56 UTC (permalink / raw) Yes. Units do need to be primitive. I've been thinking about this for a while too, but haven't had the chance to write it up. The idea frankly never occurred to me until Ehud suggested it in a post a few months back. At first I thought "that's nuts". But it isn't :-)... We now have type-safe programming in Ada. But there are two things wanting: (1) unit-safe programming, and (2) automatic unit conversion. These cannot be provided without augmenting the language. (Note: "automatic" does not mean "implicit", it means the compiler does the work for you). This would really complete Ada's support for scalar abstraction. "James Rogers" <jimmaureenrogers@worldnet.att.net> wrote in message news:3C0A5054.E74A82E7@worldnet.att.net... > [snip...] > > Possible declarative syntax might be: > > type Meters is unit range (0.0..1.0E380); > type Hours is unit range (0.0..9.99E30); Something like that. I don't think this is going to cut it, but you're on the right track.... Unit declarations need to be independent of types. Then a dimensioned type would be created by combining a unit with a representation later on, in the type definition. You need to defer the "binding" of a type to a unit in order to achieve the right level of abstraction. > type Speed is unit(Meters / Hours); I think the correct approach would involve declaring a unit (but not a type) in terms of Meters and Hours (in your example). The programmer would want to call this unit "Meters_Per_Hour", not "Speed". Mark Lundquist ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Another Idea for Ada 20XX 2001-12-03 14:56 ` Another Idea for Ada 20XX Mark Lundquist @ 2001-12-03 15:12 ` Lutz Donnerhacke 2001-12-03 21:13 ` Dimensionality Checking (Ada 20XX) Nick Roberts 2001-12-03 17:00 ` Another Idea for Ada 20XX chris.danx 1 sibling, 1 reply; 26+ messages in thread From: Lutz Donnerhacke @ 2001-12-03 15:12 UTC (permalink / raw) * Mark Lundquist wrote: >> type Speed is unit(Meters / Hours); > >I think the correct approach would involve declaring a unit (but not a type) >in terms of Meters and Hours (in your example). The programmer would want >to call this unit "Meters_Per_Hour", not "Speed". I beg to differ. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Dimensionality Checking (Ada 20XX) 2001-12-03 15:12 ` Lutz Donnerhacke @ 2001-12-03 21:13 ` Nick Roberts 2001-12-04 14:00 ` Dmitry A. Kazakov 0 siblings, 1 reply; 26+ messages in thread From: Nick Roberts @ 2001-12-03 21:13 UTC (permalink / raw) I really like this idea. I'd like to throw in a suggestion. I think probably the facility should only be applied to fixed-point types. All floating-point types would remain 'undimensioned' and there would be conversions and other operations between all floating-point, integer, and fixed-point types as usual (whose results would be undimensioned). There would be a new package, Ada.Physics, in which the following types and constants would be declared: type Physical_Dimension is (Mass, Distance, Time); type Dimensionality is array (Physical_Dimension) of Integer; Meter_Dimensionality: constant Dimensionality := (1,0,0); Metre_Dimensionality: constant Dimensionality := (1,0,0); Second_Dimensionality: constant Dimensionality := (0,0,1); -- etc. A programmer may then construct a package with unit declarations appropriate to a specific application domain, e.g.: package My_Physics is Foot_Dimensionality: constant Ada.Physics.Dimensionality := (1,0,0); generic type Feet is delta <>; type Meters is delta <>; function Generic_Feet_to_Meters (X: in Feet) return Meters; pragma Inline(Generic_Feet_to_Meters); -- etc. end; Then, in application code, the following could be used: -- TURD: Traditional Ultrasonic Ranging Device type TURD_Distance is delta 17.0/16200 range 1.0/12 .. 17.0; -- in feet pragma Dimensionality ( Type_Name => TURD_Distance, Dimensions => My_Physics.Foot_Dimensionality ); By supplying a Dimensionality pragma for the type T, dimension checking would then be applied to the "+", "-", "*", "/", and "**" operations of T as appropriate. The dimensionality of the result would be checked against: in an assignment, the target object; for an actual parameter, the corresponding formal. Of these operations, if either actual parameter (apart from the righthand one of "**") is undimensioned, no check would be applied (and the result is undimensioned). The checks would be entirely static. The pragma must occur before the type is frozen. The value of the Dimensions parameter must be static, and of type Ada.Physics.Dimensionality. These facilities could be defined in an optional annex. If a program which uses dimensionality checking were to be ported to a compiler which doesn't support it, the program should still compile and work as before, except only that the dimensionality checking would not be done. I would suggest that scaling and offset are done using existing Ada facilities. -- Nick Roberts ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Dimensionality Checking (Ada 20XX) 2001-12-03 21:13 ` Dimensionality Checking (Ada 20XX) Nick Roberts @ 2001-12-04 14:00 ` Dmitry A. Kazakov 2001-12-06 19:52 ` Britt Snodgrass 0 siblings, 1 reply; 26+ messages in thread From: Dmitry A. Kazakov @ 2001-12-04 14:00 UTC (permalink / raw) On Mon, 3 Dec 2001 21:13:38 -0000, "Nick Roberts" <nickroberts@adaos.worldonline.co.uk> wrote: >I really like this idea. I'd like to throw in a suggestion. > >I think probably the facility should only be applied to fixed-point types. >All floating-point types would remain 'undimensioned' and there would be >conversions and other operations between all floating-point, integer, and >fixed-point types as usual (whose results would be undimensioned). > >There would be a new package, Ada.Physics, in which the following types and >constants would be declared: > > type Physical_Dimension is (Mass, Distance, Time); > > type Dimensionality is array (Physical_Dimension) of Integer; > > Meter_Dimensionality: constant Dimensionality := (1,0,0); > Metre_Dimensionality: constant Dimensionality := (1,0,0); > > Second_Dimensionality: constant Dimensionality := (0,0,1); > -- etc. > >A programmer may then construct a package with unit declarations appropriate >to a specific application domain, e.g.: > > package My_Physics is > > Foot_Dimensionality: > constant Ada.Physics.Dimensionality := (1,0,0); > > generic > type Feet is delta <>; > type Meters is delta <>; > function Generic_Feet_to_Meters (X: in Feet) return Meters; > pragma Inline(Generic_Feet_to_Meters); > > -- etc. > > end; > >Then, in application code, the following could be used: > > -- TURD: Traditional Ultrasonic Ranging Device > > type TURD_Distance is delta 17.0/16200 range 1.0/12 .. 17.0; > -- in feet > > pragma Dimensionality > ( Type_Name => TURD_Distance, > Dimensions => My_Physics.Foot_Dimensionality ); > >By supplying a Dimensionality pragma for the type T, dimension checking >would then be applied to the "+", "-", "*", "/", and "**" operations of T as >appropriate. The dimensionality of the result would be checked against: in >an assignment, the target object; for an actual parameter, the corresponding >formal. Of these operations, if either actual parameter (apart from the >righthand one of "**") is undimensioned, no check would be applied (and the >result is undimensioned). There are two different "undimensioned" in your system: a) ones with no paragma Dimensionality applied and b) ones with pragma Dimensionality (Dimensions=>(others=>0)); Then: case b case a 2*2m 4 4m 2+2m illegal 4 2m**2 4sqm 4sqm 2**2m illegal 4 Anyway you should invent some rules for literals of dimensioned types. Will you apply pragma Dimensionality to literals depending on the context? >The checks would be entirely static. The pragma >must occur before the type is frozen. The value of the Dimensions parameter >must be static, and of type Ada.Physics.Dimensionality. Static unit checks would efficiently exclude "class-wide" operations on dimensioned values like 'Value, 'Image, 'Read etc. There is IMO an obvious analogy between dimensionality and both type tags and discriminants. I think that there should be possible to have both constrained (=fixed dimension) and unconstrained (class-wide) subtypes and instances of dimensioned types. Constrained ones should be checked at compile time the same way as String (1..3) is checked when "abc" is assigned. If Ada should support dimensioned types, then I think that it should do it using the existing paradigms. As I see it there could be two approaches: a hard-wired implementation of dimensioned units as many have proposed and a more complicated way based on an ability to have compile-time user-defined subroutines defined on type tags and/or discriminants. I believe it is worth to think (for Ada 2100 (:-)) about the "more compilcated" approach because the pattern of dimensioned units is quite wide spread. For instance, it could well be used for matrix/vector types etc. >These facilities could be defined in an optional annex. If a program which >uses dimensionality checking were to be ported to a compiler which doesn't >support it, the program should still compile and work as before, except only >that the dimensionality checking would not be done. > >I would suggest that scaling and offset are done using existing Ada >facilities. To which of the following two types would you apply pragma Dimensionality (Dimensions=>Second_Dimensionality); 1. Ada.Calendar.Time 2. Standard.Duration (:-)) Regards, Dmitry Kazakov ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Dimensionality Checking (Ada 20XX) 2001-12-04 14:00 ` Dmitry A. Kazakov @ 2001-12-06 19:52 ` Britt Snodgrass 2001-12-06 20:55 ` Mark Lundquist ` (3 more replies) 0 siblings, 4 replies; 26+ messages in thread From: Britt Snodgrass @ 2001-12-06 19:52 UTC (permalink / raw) Perhaps this is not a new proposal but it seems to me that units (dimensionality) in Ada code would be most naturally implemented as attributes of objects or types. The units of an object or type would be specified with a representation clause. If unspecified, the unit attribute would default to "null" (no units). The compiler could then enforce unit consistency during compilation or generate runtime unit checking code. For example: with Ada.Text_IO; with Ada.Dimensionality.ISO_Metric_Units; -- predefined for kilograms, meters, etc. with Ada.Dimensionality.My_User_Defined_Units -- parsecs_per_picosecond, etc. use Ada.Dimensionality; package body Proposed_Unit_Syntax_Example is type Magnitude is digits 15; Delta_Position : Magnitude; for Delta_Position'Unit use ISO_Metric_Units.Meter; Delta_Time : Magnitude; for Delta_Time'Unit use ISO_Metric_Units.Second; Current_Speed : Magnitude; for Current_Speed'Unit use ISO_Metric_Units.Meter / ISO_Metric_Units.Second; Accel : Magnitude; for Accel'Unit use ISO_Metric_Units.Meter / ISO_Metric_Units.Second**2; -- note use of operators in attribute definition. begin Delta_Position := 500.0; -- meters implied by unit attribute Delta_Interval := 10.0; -- seconds implied by unit attribute Current_Speed := Delta_Position / Delta_Interval; -- OK, units match Current_Speed := Delta_Position / Delta_Interval**2; -- won't compile or raises a predefined Unit_Error exception; exception when Unit_Error => Ada.Text_IO.Put_Line ("Oops! I just passed Mars without stopping to orbit!"); end Proposed_Unit_Syntax_Example; Since all of the variables in this example are of the same type, no new arithmetic operators need to be defined. However the compiler would use the unit attributes to ensure that any resulting right-side composite unit matches the left-side unit before allowing an assignment to proceed. Most unit inconsistencies would be caught during compilation. If a unit mismatch can't be caught until runtime, then a predefined Unit_Error exception would be raised (unless the code had been compiled with Pragma Suppress (Unit_Checks) ). Britt Snodgrass ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Dimensionality Checking (Ada 20XX) 2001-12-06 19:52 ` Britt Snodgrass @ 2001-12-06 20:55 ` Mark Lundquist 2001-12-06 22:38 ` Wes Groleau ` (2 subsequent siblings) 3 siblings, 0 replies; 26+ messages in thread From: Mark Lundquist @ 2001-12-06 20:55 UTC (permalink / raw) In my post, I mentioned the idea of specifying units and their relationships independent of types, then somehow "binding" units to types. At first glance, your idea seems promising for the "binding" part. Very nice. I hadn't thought of using attributes for this, and as you say it is a natural notation for Ada. -- mark "Britt Snodgrass" <britt@adapower.net> wrote in message news:36c6f8dd.0112061152.333c9de@posting.google.com... > Perhaps this is not a new proposal but it seems to me that units > (dimensionality) in Ada code would be most naturally implemented as > attributes of objects or types. The units of an object or type would > be specified with a representation clause. If unspecified, the unit > attribute would default to "null" (no units). The compiler could then > enforce unit consistency during compilation or generate runtime unit > checking code. > > For example: > > with Ada.Text_IO; > > with Ada.Dimensionality.ISO_Metric_Units; > -- predefined for kilograms, meters, etc. > > with Ada.Dimensionality.My_User_Defined_Units > -- parsecs_per_picosecond, etc. > > use Ada.Dimensionality; > > package body Proposed_Unit_Syntax_Example is > > type Magnitude is digits 15; > > Delta_Position : Magnitude; > for Delta_Position'Unit use ISO_Metric_Units.Meter; > > Delta_Time : Magnitude; > for Delta_Time'Unit use ISO_Metric_Units.Second; > > Current_Speed : Magnitude; > for Current_Speed'Unit use > ISO_Metric_Units.Meter / ISO_Metric_Units.Second; > > Accel : Magnitude; > for Accel'Unit use > ISO_Metric_Units.Meter / ISO_Metric_Units.Second**2; > -- note use of operators in attribute definition. > > begin > > Delta_Position := 500.0; -- meters implied by unit attribute > > Delta_Interval := 10.0; -- seconds implied by unit attribute > > Current_Speed := Delta_Position / Delta_Interval; > -- OK, units match > > Current_Speed := Delta_Position / Delta_Interval**2; > -- won't compile or raises a predefined Unit_Error exception; > > exception > > when Unit_Error => > Ada.Text_IO.Put_Line > ("Oops! I just passed Mars without stopping to orbit!"); > > end Proposed_Unit_Syntax_Example; > > > Since all of the variables in this example are of the same type, no > new arithmetic operators need to be defined. However the compiler > would use the unit attributes to ensure that any resulting right-side > composite unit matches the left-side unit before allowing an > assignment to proceed. Most unit inconsistencies would be caught > during compilation. If a unit mismatch can't be caught until runtime, > then a predefined Unit_Error exception would be raised (unless the > code had been compiled with Pragma Suppress (Unit_Checks) ). > > Britt Snodgrass ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Dimensionality Checking (Ada 20XX) 2001-12-06 19:52 ` Britt Snodgrass 2001-12-06 20:55 ` Mark Lundquist @ 2001-12-06 22:38 ` Wes Groleau 2001-12-06 23:12 ` Mark Lundquist 2001-12-07 9:37 ` Dmitry A. Kazakov 2001-12-07 22:51 ` Mark Lundquist 3 siblings, 1 reply; 26+ messages in thread From: Wes Groleau @ 2001-12-06 22:38 UTC (permalink / raw) Britt Snodgrass wrote: > (dimensionality) in Ada code would be most naturally implemented as > attributes of objects or types. The units of an object or type would > be specified with a representation clause. If unspecified, the unit I think this is a very good idea. But now to nitpick: > Accel : Magnitude; > for Accel'Unit use > ISO_Metric_Units.Meter / ISO_Metric_Units.Second**2; In some cases, might there be multiple ways to describe the units? Speed is Acceleration * Time but it is also Distance / Time. -- Wes Groleau http://freepages.rootsweb.com/~wgroleau ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Dimensionality Checking (Ada 20XX) 2001-12-06 22:38 ` Wes Groleau @ 2001-12-06 23:12 ` Mark Lundquist 2001-12-07 14:36 ` Wes Groleau 0 siblings, 1 reply; 26+ messages in thread From: Mark Lundquist @ 2001-12-06 23:12 UTC (permalink / raw) "Wes Groleau" <wgroleau@usa.com> wrote in message news:3C0FF376.2DC0C3E4@usa.com... > > > Britt Snodgrass wrote: > > (dimensionality) in Ada code would be most naturally implemented as > > attributes of objects or types. The units of an object or type would > > be specified with a representation clause. If unspecified, the unit > > I think this is a very good idea. But now to nitpick: > > > Accel : Magnitude; > > for Accel'Unit use > > ISO_Metric_Units.Meter / ISO_Metric_Units.Second**2; > > In some cases, might there be multiple ways to describe > the units? Speed is Acceleration * Time but it is also > Distance / Time. Right, which is why (a) the concepts of "unit" and of "dimension" need to be loosely coupled (this is missing from the proposals I've seen so far), and then (b) you have to distinguish between base and derived dimensions. We normally think of Distance and Time as being "fundamental", so typically we would declare these as base dimensions. Then we declare the derived dimension Rate = Distance / Time. That's (a). (b) says that Rate = Distance / Time no matter the units. The dimensionality checking would be done in terms of base dimensions, so it makes no difference "how you got there", e.g. in terms of derived dimensions. Best Regards, Mark ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Dimensionality Checking (Ada 20XX) 2001-12-06 23:12 ` Mark Lundquist @ 2001-12-07 14:36 ` Wes Groleau 0 siblings, 0 replies; 26+ messages in thread From: Wes Groleau @ 2001-12-07 14:36 UTC (permalink / raw) Mark Lundquist wrote: > > "Wes Groleau" <wgroleau@usa.com> wrote .... > > > Accel : Magnitude; > > > for Accel'Unit use > > > ISO_Metric_Units.Meter / ISO_Metric_Units.Second**2; > > > > In some cases, might there be multiple ways to describe > > the units? Speed is Acceleration * Time but it is also > > Distance / Time. > > Right, which is why (a) the concepts of "unit" and of "dimension" need to be > loosely coupled (this is missing from the proposals I've seen so far), and > then (b) you have to distinguish between base and derived dimensions. I guess what I mean is that the compiler would have to have some smarts to be able to figure out all the numerous ways of deriving a derived dimension--including from other derived dimensions. -- Wes Groleau http://freepages.rootsweb.com/~wgroleau ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Dimensionality Checking (Ada 20XX) 2001-12-06 19:52 ` Britt Snodgrass 2001-12-06 20:55 ` Mark Lundquist 2001-12-06 22:38 ` Wes Groleau @ 2001-12-07 9:37 ` Dmitry A. Kazakov 2001-12-07 22:51 ` Mark Lundquist 3 siblings, 0 replies; 26+ messages in thread From: Dmitry A. Kazakov @ 2001-12-07 9:37 UTC (permalink / raw) On 6 Dec 2001 11:52:12 -0800, britt@adapower.net (Britt Snodgrass) wrote: >Perhaps this is not a new proposal but it seems to me that units >(dimensionality) in Ada code would be most naturally implemented as >attributes of objects or types. The units of an object or type would >be specified with a representation clause. If unspecified, the unit >attribute would default to "null" (no units). The compiler could then >enforce unit consistency during compilation or generate runtime unit >checking code. > >For example: > >with Ada.Text_IO; > >with Ada.Dimensionality.ISO_Metric_Units; >-- predefined for kilograms, meters, etc. > >with Ada.Dimensionality.My_User_Defined_Units >-- parsecs_per_picosecond, etc. > >use Ada.Dimensionality; > >package body Proposed_Unit_Syntax_Example is > > type Magnitude is digits 15; > > Delta_Position : Magnitude; > for Delta_Position'Unit use ISO_Metric_Units.Meter; > > Delta_Time : Magnitude; > for Delta_Time'Unit use ISO_Metric_Units.Second; > > Current_Speed : Magnitude; > for Current_Speed'Unit use > ISO_Metric_Units.Meter / ISO_Metric_Units.Second; > > Accel : Magnitude; > for Accel'Unit use > ISO_Metric_Units.Meter / ISO_Metric_Units.Second**2; > -- note use of operators in attribute definition. > >begin > > Delta_Position := 500.0; -- meters implied by unit attribute > > Delta_Interval := 10.0; -- seconds implied by unit attribute > > Current_Speed := Delta_Position / Delta_Interval; > -- OK, units match > > Current_Speed := Delta_Position / Delta_Interval**2; > -- won't compile or raises a predefined Unit_Error exception; > >exception > > when Unit_Error => > Ada.Text_IO.Put_Line > ("Oops! I just passed Mars without stopping to orbit!"); > >end Proposed_Unit_Syntax_Example; > > >Since all of the variables in this example are of the same type, no >new arithmetic operators need to be defined. However the compiler >would use the unit attributes to ensure that any resulting right-side >composite unit matches the left-side unit before allowing an >assignment to proceed. Most unit inconsistencies would be caught >during compilation. If a unit mismatch can't be caught until runtime, >then a predefined Unit_Error exception would be raised (unless the >code had been compiled with Pragma Suppress (Unit_Checks) ). I would also prefer a representation clause over rather obscure pragmas, but the question stands: how to do class-wide unit programming? For instance, how to write [non-generic] subprogram IntegrateTime which takes <unit>/s and returns <unit>? How to write a subprogram that gets user input from a dialog field and returns some dimensioned value? Therefore I would prefer a solution based on discriminants or else tags provided that the compiler will remove all extra data fields and run-time checks in case when units are statically known. Regards, Dmitry Kazakov ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Dimensionality Checking (Ada 20XX) 2001-12-06 19:52 ` Britt Snodgrass ` (2 preceding siblings ...) 2001-12-07 9:37 ` Dmitry A. Kazakov @ 2001-12-07 22:51 ` Mark Lundquist 3 siblings, 0 replies; 26+ messages in thread From: Mark Lundquist @ 2001-12-07 22:51 UTC (permalink / raw) "Britt Snodgrass" <britt@adapower.net> wrote in message news:36c6f8dd.0112061152.333c9de@posting.google.com... > > Most unit inconsistencies would be caught > during compilation. If a unit mismatch can't be caught until runtime, > then a predefined Unit_Error exception would be raised (unless the > code had been compiled with Pragma Suppress (Unit_Checks) ). Well, I would think that unit checking would be *entirely* a compile-time phenomenon. Can you think of any reason why it would not be? Also... you want to set up the proposed feature so that it can be defined without touching the conformance rules in any way, which means that at some point you "bury" the units in the type and then don't think about them any more. That point is the application of the 'Unit representation clause in your scheme. Assuming this, then the check that actually takes place is just the normal type check, which of course is fully static (except for tagged types, but the reasons for that are completely unrelated and do not apply to scalars). Cheers, Mark ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Another Idea for Ada 20XX 2001-12-03 14:56 ` Another Idea for Ada 20XX Mark Lundquist 2001-12-03 15:12 ` Lutz Donnerhacke @ 2001-12-03 17:00 ` chris.danx 1 sibling, 0 replies; 26+ messages in thread From: chris.danx @ 2001-12-03 17:00 UTC (permalink / raw) "Mark Lundquist" <mlundquist2@attbi.com> wrote in message news:KoMO7.2339$Px.45566@rwcrnsc54... > > Yes. Units do need to be primitive. > > I've been thinking about this for a while too, but haven't had the chance to > write it up. The idea frankly never occurred to me until Ehud suggested it > in a post a few months back. At first I thought "that's nuts". But it > isn't :-)... > > We now have type-safe programming in Ada. But there are two things wanting: > (1) unit-safe programming, and (2) automatic unit conversion. These cannot > be provided without augmenting the language. (Note: "automatic" does not > mean "implicit", it means the compiler does the work for you). > > This would really complete Ada's support for scalar abstraction. > > "James Rogers" <jimmaureenrogers@worldnet.att.net> wrote in message > news:3C0A5054.E74A82E7@worldnet.att.net... > > > [snip...] > > > > Possible declarative syntax might be: > > > > type Meters is unit range (0.0..1.0E380); > > type Hours is unit range (0.0..9.99E30); > > Something like that. I don't think this is going to cut it, but you're on > the right track.... Unit declarations need to be independent of types. > Then a dimensioned type would be created by combining a unit with a > representation later on, in the type definition. You need to defer the > "binding" of a type to a unit in order to achieve the right level of > abstraction. > > type Speed is unit(Meters / Hours); > > I think the correct approach would involve declaring a unit (but not a type) > in terms of Meters and Hours (in your example). The programmer would want > to call this unit "Meters_Per_Hour", not "Speed". ^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2001-12-07 22:51 UTC | newest] Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-12-02 16:01 Another Idea for Ada 20XX James Rogers 2001-12-02 16:38 ` Preben Randhol 2001-12-02 22:26 ` James Rogers 2001-12-02 21:19 ` Patrick Hohmeyer 2001-12-02 21:26 ` Lutz Donnerhacke 2001-12-02 23:49 ` Patrick Hohmeyer 2001-12-03 6:06 ` Wilhelm Spickermann 2001-12-03 8:58 ` Lutz Donnerhacke 2001-12-03 13:40 ` Thomas Koenig 2001-12-03 0:21 ` Robert C. Leif, Ph.D. 2001-12-03 0:35 ` Robert Dewar 2001-12-03 1:33 ` James Rogers 2001-12-03 12:34 ` Dirk Dickmanns 2001-12-04 19:02 ` Unit handling (was: Another Idea for Ada 20XX) Wilhelm Spickermann 2001-12-03 14:56 ` Another Idea for Ada 20XX Mark Lundquist 2001-12-03 15:12 ` Lutz Donnerhacke 2001-12-03 21:13 ` Dimensionality Checking (Ada 20XX) Nick Roberts 2001-12-04 14:00 ` Dmitry A. Kazakov 2001-12-06 19:52 ` Britt Snodgrass 2001-12-06 20:55 ` Mark Lundquist 2001-12-06 22:38 ` Wes Groleau 2001-12-06 23:12 ` Mark Lundquist 2001-12-07 14:36 ` Wes Groleau 2001-12-07 9:37 ` Dmitry A. Kazakov 2001-12-07 22:51 ` Mark Lundquist 2001-12-03 17:00 ` Another Idea for Ada 20XX chris.danx
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox