* Re: Another Idea for Ada 20XX @ 2001-12-02 19:51 Gautier Write-only-address 2001-12-02 22:36 ` James Rogers 2001-12-03 14:56 ` Another Idea for Ada 20XX Mark Lundquist 0 siblings, 2 replies; 35+ messages in thread From: Gautier Write-only-address @ 2001-12-02 19:51 UTC (permalink / raw) To: comp.lang.ada >From: James Rogers >In scientific terms a measurement is done in terms of some unit. >For instance, distance is in meters, microns, feet or furlongs. ... >calculations. Because of the added computational overhead, there must >be a way to choose or reject unit analysis for defined types. The overhead is not only computational, I fear: if programmers are forced to specify the unit of each of their variables with a possible physical meaning, they just won't program in Ada... Where is the problem, indeed ? Mixing feets and meters in a program ? This is more a political or cultural problem, I wouldn't wish to complicate Ada with it... ____________________________________________________________ Gautier -- http://www.mysunrise.ch/users/gdm/index.htm#Ada NB: Do not answer to sender address, visit the Web site! _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Another Idea for Ada 20XX 2001-12-02 19:51 Another Idea for Ada 20XX Gautier Write-only-address @ 2001-12-02 22:36 ` James Rogers 2001-12-03 12:44 ` Marc A. Criley 2001-12-04 1:40 ` Adrian Hoe 2001-12-03 14:56 ` Another Idea for Ada 20XX Mark Lundquist 1 sibling, 2 replies; 35+ messages in thread From: James Rogers @ 2001-12-02 22:36 UTC (permalink / raw) Gautier Write-only-address wrote: > > >From: James Rogers > > >In scientific terms a measurement is done in terms of some unit. > >For instance, distance is in meters, microns, feet or furlongs. > ... > >calculations. Because of the added computational overhead, there must > >be a way to choose or reject unit analysis for defined types. > > The overhead is not only computational, I fear: if programmers > are forced to specify the unit of each of their variables > with a possible physical meaning, they just won't program in > Ada... > > Where is the problem, indeed ? Mixing feets and meters in a > program ? This is more a political or cultural problem, I > wouldn't wish to complicate Ada with it... The problem is not only political and cultural. Take the situation of the NASA Mars probe that crashed because of an improper mixture of British and Metric distance units. If the programming language used had provided the ability to perform unit analysis the mistake would have been caught by the compiler. What I am trying to express is an extension of strong typing. This extension would allow specified mixing of types. The current Ada model places a strong barrier between all type mixes. The use of units will allow you to specify how and where certain types can be mixed. I personally find the units idea easier to understand than simply applying type coercion at various places in code. The concept of units also allows careful checking by the compiler, and secondary analysis (outside a compiler) of the code to ensure algorithmic correctness. Jim Rogers Colorado Springs, Colorado USA ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Another Idea for Ada 20XX 2001-12-02 22:36 ` James Rogers @ 2001-12-03 12:44 ` Marc A. Criley 2001-12-03 14:29 ` Larry Kilgallen 2001-12-04 1:40 ` Adrian Hoe 1 sibling, 1 reply; 35+ messages in thread From: Marc A. Criley @ 2001-12-03 12:44 UTC (permalink / raw) James Rogers wrote: > > Take the situation of the NASA Mars probe that crashed because > of an improper mixture of British and Metric distance units. > > If the programming language used had provided the ability to > perform unit analysis the mistake would have been caught by > the compiler. Actually, no it would not have been caught by the compiler. While working on an article several months ago I exchanged some emails with an individual at Malin Space Science Systems, who knew exactly what had happened there--which is why I'd contacted him. The problem was that one program wrote a file of floating point numbers representing values in British units, which was then read by a program that expected floating point numbers representing metric units. No unit information accompanied the values in the file, they were just numbers. Marc A. Criley Senior Staff Engineer Quadrus Corporation www.quadruscorp.com ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Another Idea for Ada 20XX 2001-12-03 12:44 ` Marc A. Criley @ 2001-12-03 14:29 ` Larry Kilgallen 2001-12-04 0:25 ` Marc A. Criley 0 siblings, 1 reply; 35+ messages in thread From: Larry Kilgallen @ 2001-12-03 14:29 UTC (permalink / raw) In article <3C0B65CB.8CDD7B31@earthlink.net>, "Marc A. Criley" <mcqada@earthlink.net> writes: > The problem was that one program wrote a file of floating point numbers > representing values in British units, which was then read by a program > that expected floating point numbers representing metric units. No unit > information accompanied the values in the file, they were just numbers. Do space probes include file systems and multiple programs ? Or is this something in the build environment ? If the latter, the problem could be solved by an old fashioned EDP tool called a data dictionary. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Another Idea for Ada 20XX 2001-12-03 14:29 ` Larry Kilgallen @ 2001-12-04 0:25 ` Marc A. Criley 0 siblings, 0 replies; 35+ messages in thread From: Marc A. Criley @ 2001-12-04 0:25 UTC (permalink / raw) Larry Kilgallen wrote: > > In article <3C0B65CB.8CDD7B31@earthlink.net>, "Marc A. Criley" <mcqada@earthlink.net> writes: > > > The problem was that one program wrote a file of floating point numbers > > representing values in British units, which was then read by a program > > that expected floating point numbers representing metric units. No unit > > information accompanied the values in the file, they were just numbers. > > Do space probes include file systems and multiple programs ? > > Or is this something in the build environment ? > > If the latter, the problem could be solved by an old fashioned EDP > tool called a data dictionary. The error occurred in the ground-based navigational processing, not onboard the spacecraft. And oh yes, there are many ways to avoid such a problem--any of the assorted manifestations of interface control documents, for instance. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Another Idea for Ada 20XX 2001-12-02 22:36 ` James Rogers 2001-12-03 12:44 ` Marc A. Criley @ 2001-12-04 1:40 ` Adrian Hoe 2001-12-04 1:56 ` Larry Kilgallen 1 sibling, 1 reply; 35+ messages in thread From: Adrian Hoe @ 2001-12-04 1:40 UTC (permalink / raw) James Rogers <jimmaureenrogers@worldnet.att.net> wrote in message news:<3C0AACCE.329CFB60@worldnet.att.net>... > Gautier Write-only-address wrote: > > > > >From: James Rogers > > > >In scientific terms a measurement is done in terms of some unit. > > >For instance, distance is in meters, microns, feet or furlongs. > ... > > >calculations. Because of the added computational overhead, there must > > >be a way to choose or reject unit analysis for defined types. > > > > The overhead is not only computational, I fear: if programmers > > are forced to specify the unit of each of their variables > > with a possible physical meaning, they just won't program in > > Ada... > > > > Where is the problem, indeed ? Mixing feets and meters in a > > program ? This is more a political or cultural problem, I > > wouldn't wish to complicate Ada with it... > > The problem is not only political and cultural. > > Take the situation of the NASA Mars probe that crashed because > of an improper mixture of British and Metric distance units. > > If the programming language used had provided the ability to > perform unit analysis the mistake would have been caught by > the compiler. > > What I am trying to express is an extension of strong typing. > This extension would allow specified mixing of types. The current > Ada model places a strong barrier between all type mixes. The > use of units will allow you to specify how and where certain > types can be mixed. I personally find the units idea easier to > understand than simply applying type coercion at various places > in code. The concept of units also allows careful checking by the > compiler, and secondary analysis (outside a compiler) of the code > to ensure algorithmic correctness. > > Jim Rogers > Colorado Springs, Colorado USA I missed the historic discussion on this matter too. Anyway, I don't see the reason to mixing unit calculation. Why not standardised the unit while designing and coding the software? It does not make good sense if an area is 25cm x 6inches and this certainly create chaos. The crash of NASA Mars probe proved the inability to communicate or to standardize among those engineers. Wouldn't this be avoided if these engineers agreed on a standardized unit of measurement? Again, will the further augmentation of Ada (adding of units conversions and checking) help to resolve this problem? I do not against the motion but question it and if James or anyone else can demonstarte the benefits of it with sample applications. This could be of great help in fMRP, the MRP software for furniture industry developed by my company. Lutz and Dmitry implementations are very interesting and may help in fMRP. Just my 2 cents from my own pocket. -- Adrian Hoe ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Another Idea for Ada 20XX 2001-12-04 1:40 ` Adrian Hoe @ 2001-12-04 1:56 ` Larry Kilgallen 2001-12-04 16:08 ` Wes Groleau 0 siblings, 1 reply; 35+ messages in thread From: Larry Kilgallen @ 2001-12-04 1:56 UTC (permalink / raw) In article <45601fc.0112031740.3e217c8a@posting.google.com>, byhoe@users.sourceforge.net (Adrian Hoe) writes: > The crash of NASA Mars probe proved the inability to communicate or to > standardize among those engineers. Wouldn't this be avoided if these > engineers agreed on a standardized unit of measurement? Again, will > the further augmentation of Ada (adding of units conversions and > checking) help to resolve this problem? If they simply used common type declarations, a lot of errors would be detected. If Meters is a new type and is used throughout, and Feet is another new type, it becomes difficult to add them. Again, in cross-language environments this was done for subprograms and records with a tool called a data dictionary -- years ago. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Another Idea for Ada 20XX 2001-12-04 1:56 ` Larry Kilgallen @ 2001-12-04 16:08 ` Wes Groleau 2001-12-04 17:48 ` Larry Kilgallen ` (3 more replies) 0 siblings, 4 replies; 35+ messages in thread From: Wes Groleau @ 2001-12-04 16:08 UTC (permalink / raw) Larry Kilgallen wrote: > If they simply used common type declarations, a lot of errors would > be detected. If Meters is a new type and is used throughout, and > Feet is another new type, it becomes difficult to add them. But that's not enough to prevent 2 Meters * 2 Meters = 4 Meters nor to allow 10 minutes * 5 KPH = 833 Meters -- Wes Groleau http://freepages.rootsweb.com/~wgroleau ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Another Idea for Ada 20XX 2001-12-04 16:08 ` Wes Groleau @ 2001-12-04 17:48 ` Larry Kilgallen 2001-12-09 23:02 ` Nick Roberts 2001-12-04 19:59 ` Vincent Marciante ` (2 subsequent siblings) 3 siblings, 1 reply; 35+ messages in thread From: Larry Kilgallen @ 2001-12-04 17:48 UTC (permalink / raw) In article <3C0CF4E3.A53D20A7@sparc01.ftw.rsc.raytheon.com>, Wes Groleau <wwgrol@sparc01.ftw.rsc.raytheon.com> writes: > > > Larry Kilgallen wrote: >> If they simply used common type declarations, a lot of errors would >> be detected. If Meters is a new type and is used throughout, and >> Feet is another new type, it becomes difficult to add them. > > But that's not enough to prevent 2 Meters * 2 Meters = 4 Meters True. > nor to allow 10 minutes * 5 KPH = 833 Meters Are you saying that multiplying two different types (not subtypes of the same type) works in Ada95 ? My experience is mostly Ada83. And exactly how would it decide that the resulting type is Meters ? Obviously one could use conversion and unchecked conversion, but those are supposed to be used with caution and serve as a red flag in formal inspection. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Another Idea for Ada 20XX 2001-12-04 17:48 ` Larry Kilgallen @ 2001-12-09 23:02 ` Nick Roberts 2001-12-10 16:22 ` Stephen Leake 2001-12-10 17:09 ` Wes Groleau 0 siblings, 2 replies; 35+ messages in thread From: Nick Roberts @ 2001-12-09 23:02 UTC (permalink / raw) "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message news:C1UHcLPG$dZX@eisner.encompasserve.org... > > nor to allow 10 minutes * 5 KPH = 833 Meters > > Are you saying that multiplying two different types (not subtypes > of the same type) works in Ada95 ? My experience is mostly Ada83. If they are both fixed point types, I think the answer is 'yes', provided it's in the context of a specific fixed point type (not universal fixed). E.g.: D: Distance := Duration(10*60.0) * KPH(5.0); -- Nick Roberts ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Another Idea for Ada 20XX 2001-12-09 23:02 ` Nick Roberts @ 2001-12-10 16:22 ` Stephen Leake 2001-12-10 17:11 ` Wes Groleau 2001-12-10 20:30 ` Robert C. Leif, Ph.D. 2001-12-10 17:09 ` Wes Groleau 1 sibling, 2 replies; 35+ messages in thread From: Stephen Leake @ 2001-12-10 16:22 UTC (permalink / raw) "Nick Roberts" <nickroberts@adaos.worldonline.co.uk> writes: > "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message > news:C1UHcLPG$dZX@eisner.encompasserve.org... > > > > nor to allow 10 minutes * 5 KPH = 833 Meters > > > > Are you saying that multiplying two different types (not subtypes > > of the same type) works in Ada95 ? My experience is mostly Ada83. > > If they are both fixed point types, I think the answer is 'yes', provided > it's in the context of a specific fixed point type (not universal fixed). > E.g.: > > D: Distance := Duration(10*60.0) * KPH(5.0); Umm, surely there must somewhere be defined a "conversion multiplier", and it must be visible: function "*" (left : in duration; right : in KPH) return Distance; otherwise the above statement is not legal, in Ada 83 or 95. Defining _all_ of these required conversion multipliers is the killer for this concept. -- -- Stephe ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Another Idea for Ada 20XX 2001-12-10 16:22 ` Stephen Leake @ 2001-12-10 17:11 ` Wes Groleau 2001-12-10 20:30 ` Robert C. Leif, Ph.D. 1 sibling, 0 replies; 35+ messages in thread From: Wes Groleau @ 2001-12-10 17:11 UTC (permalink / raw) Stephen Leake wrote: > Defining _all_ of these required conversion multipliers is the killer > for this concept. When I did it, it was a temporary pain, but once it was done..... (generics helped a lot). -- Wes Groleau http://freepages.rootsweb.com/~wgroleau ^ permalink raw reply [flat|nested] 35+ messages in thread
* RE: Another Idea for Ada 20XX 2001-12-10 16:22 ` Stephen Leake 2001-12-10 17:11 ` Wes Groleau @ 2001-12-10 20:30 ` Robert C. Leif, Ph.D. 2001-12-10 20:59 ` Wes Groleau 1 sibling, 1 reply; 35+ messages in thread From: Robert C. Leif, Ph.D. @ 2001-12-10 20:30 UTC (permalink / raw) To: comp.lang.ada From: Bob Leif To: Stephen Leake et al. "Defining _all_ of these required conversion multipliers is the killer for this concept." This is particularly true since they are NOT needed! In fact, the actual combinations of units in physics and chemistry formulas is very large. What has to be done is a check that the exponents of the units are the same for addition-subtraction. Of course the data that is an input, an output, or a check-point must have the exponents of their units being constants. -----Original Message----- From: comp.lang.ada-admin@ada.eu.org [mailto:comp.lang.ada-admin@ada.eu.org]On Behalf Of Stephen Leake Sent: Monday, December 10, 2001 8:22 AM To: comp.lang.ada@ada.eu.org Subject: Re: Another Idea for Ada 20XX "Nick Roberts" <nickroberts@adaos.worldonline.co.uk> writes: > "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message > news:C1UHcLPG$dZX@eisner.encompasserve.org... > > > > nor to allow 10 minutes * 5 KPH = 833 Meters > > > > Are you saying that multiplying two different types (not subtypes > > of the same type) works in Ada95 ? My experience is mostly Ada83. > > If they are both fixed point types, I think the answer is 'yes', provided > it's in the context of a specific fixed point type (not universal fixed). > E.g.: > > D: Distance := Duration(10*60.0) * KPH(5.0); Umm, surely there must somewhere be defined a "conversion multiplier", and it must be visible: function "*" (left : in duration; right : in KPH) return Distance; otherwise the above statement is not legal, in Ada 83 or 95. Defining _all_ of these required conversion multipliers is the killer for this concept. -- -- Stephe ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Another Idea for Ada 20XX 2001-12-10 20:30 ` Robert C. Leif, Ph.D. @ 2001-12-10 20:59 ` Wes Groleau 0 siblings, 0 replies; 35+ messages in thread From: Wes Groleau @ 2001-12-10 20:59 UTC (permalink / raw) "Robert C. Leif, Ph.D." wrote: > > From: Bob Leif > To: Stephen Leake et al. > "Defining _all_ of these required conversion multipliers is the killer > for this concept." > > This is particularly true since they are NOT needed! In fact, the actual In the concept he was talking about, they ARE needed. In the exponent/record concept they are not. Instead, there one has to define all the conversion and IO operations and attributes. -- Wes Groleau http://freepages.rootsweb.com/~wgroleau ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Another Idea for Ada 20XX 2001-12-09 23:02 ` Nick Roberts 2001-12-10 16:22 ` Stephen Leake @ 2001-12-10 17:09 ` Wes Groleau 2001-12-10 17:32 ` Larry Kilgallen 1 sibling, 1 reply; 35+ messages in thread From: Wes Groleau @ 2001-12-10 17:09 UTC (permalink / raw) > "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote .... > > > > nor to allow 10 minutes * 5 KPH = 833 Meters > > > > Are you saying that multiplying two different types (not subtypes > > of the same type) works in Ada95 ? My experience is mostly Ada83. No, I'm saying it doesn't. So making derived types for Minutes, KPH, and Meters is not sufficient to make the example work. You have to also define the operator. -- Wes Groleau http://freepages.rootsweb.com/~wgroleau ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Another Idea for Ada 20XX 2001-12-10 17:09 ` Wes Groleau @ 2001-12-10 17:32 ` Larry Kilgallen 0 siblings, 0 replies; 35+ messages in thread From: Larry Kilgallen @ 2001-12-10 17:32 UTC (permalink / raw) In article <3C14EC43.67FD5082@sparc01.ftw.rsc.raytheon.com>, Wes Groleau <wwgrol@sparc01.ftw.rsc.raytheon.com> writes: > >> "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote .... >> >> > > nor to allow 10 minutes * 5 KPH = 833 Meters >> > >> > Are you saying that multiplying two different types (not subtypes >> > of the same type) works in Ada95 ? My experience is mostly Ada83. > > No, I'm saying it doesn't. So making derived types for > Minutes, KPH, and Meters is not sufficient to make the > example work. You have to also define the operator. My point was that "accidental" multiplication will not be allowed if one uses individual types (not subtypes). ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Another Idea for Ada 20XX 2001-12-04 16:08 ` Wes Groleau 2001-12-04 17:48 ` Larry Kilgallen @ 2001-12-04 19:59 ` Vincent Marciante 2001-12-04 20:20 ` Wes Groleau 2001-12-04 22:18 ` Matthew Heaney 2001-12-06 4:14 ` Richard Riehle 3 siblings, 1 reply; 35+ messages in thread From: Vincent Marciante @ 2001-12-04 19:59 UTC (permalink / raw) "Wes Groleau" <wwgrol@sparc01.ftw.rsc.raytheon.com> wrote in message news:3C0CF4E3.A53D20A7@sparc01.ftw.rsc.raytheon.com... > > > But that's not enough to prevent 2 Meters * 2 Meters = 4 Meters You can _remove_ the meters*meters operation by declaring is as abstract, something like: function "*" (left,right: meters) return meters is abstract; then meters*meters won't compile. > nor to allow 10 minutes * 5 KPH = 833 Meters > > -- > Wes Groleau > http://freepages.rootsweb.com/~wgroleau ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Another Idea for Ada 20XX 2001-12-04 19:59 ` Vincent Marciante @ 2001-12-04 20:20 ` Wes Groleau 0 siblings, 0 replies; 35+ messages in thread From: Wes Groleau @ 2001-12-04 20:20 UTC (permalink / raw) Vincent Marciante wrote: > You can _remove_ the meters*meters operation by declaring is as abstract, > something like: Yes. My point was that the proposal created such illegal operators without taking action like this to compensate. -- Wes Groleau http://freepages.rootsweb.com/~wgroleau ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Another Idea for Ada 20XX 2001-12-04 16:08 ` Wes Groleau 2001-12-04 17:48 ` Larry Kilgallen 2001-12-04 19:59 ` Vincent Marciante @ 2001-12-04 22:18 ` Matthew Heaney 2001-12-06 4:14 ` Richard Riehle 3 siblings, 0 replies; 35+ messages in thread From: Matthew Heaney @ 2001-12-04 22:18 UTC (permalink / raw) "Wes Groleau" <wwgrol@sparc01.ftw.rsc.raytheon.com> wrote in message news:3C0CF4E3.A53D20A7@sparc01.ftw.rsc.raytheon.com... > > > Larry Kilgallen wrote: > > If they simply used common type declarations, a lot of errors would > > be detected. If Meters is a new type and is used throughout, and > > Feet is another new type, it becomes difficult to add them. > > But that's not enough to prevent 2 Meters * 2 Meters = 4 Meters > nor to allow 10 minutes * 5 KPH = 833 Meters You can always take away multipication: type Length_In_Meters_Type is new Float; --or whatever function "*" (L, R : Length_In_Meters_Type) return Length_In_Meters_Type is abstract; ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Another Idea for Ada 20XX 2001-12-04 16:08 ` Wes Groleau ` (2 preceding siblings ...) 2001-12-04 22:18 ` Matthew Heaney @ 2001-12-06 4:14 ` Richard Riehle 2001-12-06 17:39 ` Wes Groleau ` (2 more replies) 3 siblings, 3 replies; 35+ messages in thread From: Richard Riehle @ 2001-12-06 4:14 UTC (permalink / raw) Wes Groleau wrote: > Larry Kilgallen wrote: > > If they simply used common type declarations, a lot of errors would > > be detected. If Meters is a new type and is used throughout, and > > Feet is another new type, it becomes difficult to add them. > > But that's not enough to prevent 2 Meters * 2 Meters = 4 Meters > nor to allow 10 minutes * 5 KPH = 833 Meters > > -- > Wes Groleau > http://freepages.rootsweb.com/~wgroleau Correct. However, a simple type declaration is just part of the solution. I don't believe it requires a change to the language. Rather, it begs for a simple object-oriented programming solution, along with some old-fashioned encapsulation. package Metric_Number is type Metric_Type is private; -- export services for arithmetic on this type function "+"(L, R : Metric_Type) return Metric_Type; -- more arithmetic and boolean functions private -- full definition for the Metric_Type; -- helper type to avoid recursion during implementation end Metric_Number; In this way, we can control the behavior of each function with some exactness instead of depending only on the predefined behavior of ALRM Chapter 4 for numeric types. Of course, if we also had pre- and post-conditions as part of the language, this contract could be made even more robust. In that case, there would definitely be no need for a specialized language feature. Richard Riehle ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Another Idea for Ada 20XX 2001-12-06 4:14 ` Richard Riehle @ 2001-12-06 17:39 ` Wes Groleau 2001-12-07 0:55 ` Adrian Hoe 2001-12-07 11:49 ` Tarjei T. Jensen 2001-12-07 22:51 ` Dimensions (was Re: Another Idea for Ada 20XX) Mark Lundquist 2 siblings, 1 reply; 35+ messages in thread From: Wes Groleau @ 2001-12-06 17:39 UTC (permalink / raw) Richard Riehle wrote: > package Metric_Number is > type Metric_Type is private; > -- export services for arithmetic on this type > function "+"(L, R : Metric_Type) return Metric_Type; > -- more arithmetic and boolean functions > private > -- full definition for the Metric_Type; > -- helper type to avoid recursion during implementation > end Metric_Number; However, you have a proliferation of combination functions. function "*" (Left : Some_Metric_Type; Right : Another_Metric_Type) return : One_More_Metric_Type; function "/" (Left : Some_Metric_Type; Right : Another_Metric_Type) return : One_More_Metric_Type; With a reasonably complete facility, the number of left/right/return combinations is huge. Especially if you allow mixed unit addition: function "+" (Left : Meters; Right : Kilometers) return : Meters; Also, this method does not allow attributes and it makes literals slightly more clumsy at best, worse if you consider all the possible ways you can misspell a unit name or use an unrecognized abbreviation for it. (Of course the latter might also be a problem in a "language feature.") I once used an enumerated type for supported units, another for all allowed ways of writing them, a lookup table for standard_form (allowed_written_form), and loads of lookup tables for conversion factors, which type comes from what, etc. That allowed having only one actual type, and only one moderately sized function per operator, but the tables took up a lot of space. Extension and inheritance might have helped some but not a lot. In that particular application, the lack of attributes turned out to be only a minor inconvenience, but I would think it would mean a lot in other cases. Defining a new metric type by inheritance would require knowing all units in the inheritance tree that it could interact with, and providing or overriding the operators to work AND disabling all the operators that would make illegal operations. So I think it wouldn't help any over a non-inherited way. -- Wes Groleau http://freepages.rootsweb.com/~wgroleau ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Another Idea for Ada 20XX 2001-12-06 17:39 ` Wes Groleau @ 2001-12-07 0:55 ` Adrian Hoe 2001-12-07 9:01 ` Dmitry A. Kazakov 0 siblings, 1 reply; 35+ messages in thread From: Adrian Hoe @ 2001-12-07 0:55 UTC (permalink / raw) Wes Groleau <wgroleau@usa.com> wrote in message news:<3C0FAD3D.64ACC870@usa.com>... > > function "+" (Left : Meters; > Right : Kilometers) > return : Meters; Consider this: function "+" (Left : Meters; Right : Inches) return Meters; What kind of precision in the conversion of Inches to Meters if Unit Checking and Conversion are to be part of Ada? Do I/we have the liberty to select the precision I/we want? How exactly this will be implemented by the new annex of Ada (perhaps)? -- Adrian Hoe > Also, this method does not allow attributes > and it makes literals slightly more clumsy at best, > worse if you consider all the possible ways you can > misspell a unit name or use an unrecognized abbreviation > for it. (Of course the latter might also be a problem > in a "language feature.") > > I once used an enumerated type for supported units, > another for all allowed ways of writing them, > a lookup table for standard_form (allowed_written_form), > and loads of lookup tables for conversion factors, > which type comes from what, etc. That allowed having > only one actual type, and only one moderately sized > function per operator, but the tables took up a lot > of space. Extension and inheritance might have helped > some but not a lot. In that particular application, > the lack of attributes turned out to be only a minor > inconvenience, but I would think it would mean a lot > in other cases. > > Defining a new metric type by inheritance would require > knowing all units in the inheritance tree that it could > interact with, and providing or overriding the operators > to work AND disabling all the operators that would make > illegal operations. > > So I think it wouldn't help any over a non-inherited way. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Another Idea for Ada 20XX 2001-12-07 0:55 ` Adrian Hoe @ 2001-12-07 9:01 ` Dmitry A. Kazakov 0 siblings, 0 replies; 35+ messages in thread From: Dmitry A. Kazakov @ 2001-12-07 9:01 UTC (permalink / raw) On 6 Dec 2001 16:55:38 -0800, byhoe@users.sourceforge.net (Adrian Hoe) wrote: >Wes Groleau <wgroleau@usa.com> wrote in message news:<3C0FAD3D.64ACC870@usa.com>... >> >> function "+" (Left : Meters; >> Right : Kilometers) >> return : Meters; > >Consider this: > >function "+" (Left : Meters; > Right : Inches) > return Meters; > >What kind of precision in the conversion of Inches to Meters if Unit >Checking and Conversion are to be part of Ada? Do I/we have the >liberty to select the precision I/we want? A possible solution is that there should be same precision of Left, Right and result. They should have exactly same representation [in some unit system, like SI] and Inches would be just a view of some length [which corresponds to the physical nature of meters and inches]. So X : Inches := 5; -- Means X := 0.127 [m] Unfortunately the price of this is that it will be impossible to have precise computations in non-metric units and range problems [eV is pretty small when compared with J]. However, it is thinkable [and preferable] that Ada would provide not an implementation of some unit system, but rather facilities to do it. Then of course, a user might just create its own unit system like (foot, second, pound) and have meters as a view of feets. He would also be able to create two different systems and define conversions between them with necessary care of precision. >How exactly this will be implemented by the new annex of Ada >(perhaps)? Regards, Dmitry Kazakov ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Another Idea for Ada 20XX 2001-12-06 4:14 ` Richard Riehle 2001-12-06 17:39 ` Wes Groleau @ 2001-12-07 11:49 ` Tarjei T. Jensen 2001-12-07 22:51 ` Dimensions (was Re: Another Idea for Ada 20XX) Mark Lundquist 2 siblings, 0 replies; 35+ messages in thread From: Tarjei T. Jensen @ 2001-12-07 11:49 UTC (permalink / raw) Richard Riehle wrote >Correct. However, a simple type declaration is just part of the >solution. >I don't believe it requires a change to the language. Rather, it begs >for a >simple object-oriented programming solution, along with some >old-fashioned >encapsulation. > > package Metric_Number is > type Metric_Type is private; > -- export services for arithmetic on this type > function "+"(L, R : Metric_Type) return Metric_Type; > -- more arithmetic and boolean functions > private > -- full definition for the Metric_Type; > -- helper type to avoid recursion during implementation > end Metric_Number; I think my suggestion (long time ago) of having a "universe" where one defines how the datatypes interact is a far better idea. The compiler would know that multiplying meter by meter would result in meter squared and that this would not be assignment compatible with meter. There would be no need for units since one would be able to specify wheter an integer would have to be typed in order to be used in an expression. Greetings, ^ permalink raw reply [flat|nested] 35+ messages in thread
* Dimensions (was Re: Another Idea for Ada 20XX) 2001-12-06 4:14 ` Richard Riehle 2001-12-06 17:39 ` Wes Groleau 2001-12-07 11:49 ` Tarjei T. Jensen @ 2001-12-07 22:51 ` Mark Lundquist 2001-12-08 3:52 ` Richard Riehle 2001-12-10 14:09 ` Ian 2 siblings, 2 replies; 35+ messages in thread From: Mark Lundquist @ 2001-12-07 22:51 UTC (permalink / raw) "Richard Riehle" <richard@adaworks.com> wrote in message news:3C0EF0A0.9F42EDB4@adaworks.com... > > I don't believe it requires a change to the language. Rather, it begs > for a > simple object-oriented programming solution, along with some > old-fashioned > encapsulation. > > package Metric_Number is > type Metric_Type is private; > -- export services for arithmetic on this type > function "+"(L, R : Metric_Type) return Metric_Type; > -- more arithmetic and boolean functions > private > -- full definition for the Metric_Type; > -- helper type to avoid recursion during implementation > end Metric_Number; I have no idea what you're getting at with the "helper type to avoid recursion"... :-) But in any case, the "good old-fashioned encapsulation" isn't enough (see below)... > > In this way, we can control the behavior of each function with some > exactness > instead of depending only on the predefined behavior of ALRM Chapter 4 > for > numeric types. Of course, if we also had pre- and post-conditions as > part of > the language, this contract could be made even more robust. I don't see how pre- and post-conditions are relevant... ??? But anyway... All these schemes that rely on hiding the representation have some serious weaknesses. First of all, the public view is not scalar. So (a) your type is not compatible with generics that take scalar formals -- you are limited to formal private types; and (b) you cannot declare subtypes with range constraints. (In my opinion (b) is by far the worse of these). (c) it's way labor-intensive But the worst is still to come :-). These schemes are quite brittle and unscalable, because: (d) you have to define all your visibly quasi-numeric operations on every combination of types for base and derived units, so you have a multiplicative explosion on your hands (e) the explosion continues if you want more than one unit per dimension. It explodes in both new overloadings of the quasi-numeric operations, and also in the unit conversions. (f) all the unit types that you wish to be interoperable must be declared in the same package, since they are private, and you can't use child packages for this because then the operations are no longer primitive. It requires "prescience/ominiscience" on the part of the designer, so unless you are really God but you just go by "Richard Riehle" on Usenet :-), it could only be considered for self-contained software where you're "rolling your own" and in complete control of all the code. (g) if you wanted to have multiple types with the same unit relationships but different representations, e.g. different delta, decimal or fixed-point types, you are hosed -- the scheme becomes totally unmanageable at that point. Best Regards, Mark ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Dimensions (was Re: Another Idea for Ada 20XX) 2001-12-07 22:51 ` Dimensions (was Re: Another Idea for Ada 20XX) Mark Lundquist @ 2001-12-08 3:52 ` Richard Riehle 2001-12-08 5:28 ` Mark Lundquist ` (2 more replies) 2001-12-10 14:09 ` Ian 1 sibling, 3 replies; 35+ messages in thread From: Richard Riehle @ 2001-12-08 3:52 UTC (permalink / raw) Mark Lundquist wrote: > "Richard Riehle" <richard@adaworks.com> wrote in message > news:3C0EF0A0.9F42EDB4@adaworks.com... > > > > > package Metric_Number is > > type Metric_Type is private; > > -- export services for arithmetic on this type > > function "+"(L, R : Metric_Type) return Metric_Type; > > -- more arithmetic and boolean functions > > private > > -- full definition for the Metric_Type; > > -- helper type to avoid recursion during implementation > > end Metric_Number; > > I have no idea what you're getting at with the "helper type to avoid > recursion"... :-) In implementing the infix operators for an experimental version of this package, I found myself having to solve the problem of having the full definition of the type as a numeric type itself. > But in any case, the "good old-fashioned encapsulation" > isn't enough (see below)... > All these schemes that rely on hiding the representation have some serious > weaknesses. First of all, the public view is not scalar. So > > (a) your type is not compatible with generics that take scalar formals -- > you are limited to formal private types; and Granted. One would be required to write one's own versions of the generics and that would be a really bad idea. Once again, I experimented with this and ended up with some truly baroque code; workable but baroque. > (b) you cannot declare subtypes with range constraints. > (In my opinion (b) is by far the worse of these). Actually, I think (a) is worse than (b). One could define the package as generic and include generic formal parameters for the range constraints. > (c) it's way labor-intensive In experimenting with this idea, I found that I could factor out some properties to make it less labor-intensive than it might seem to be at first glance. Nevertheless, you are correct that it is more labor intensive than the more straigthforward approach orginally suggested. > But the worst is still to come :-). These schemes are quite brittle and > unscalable, because: > > (d) you have to define all your visibly quasi-numeric operations on every > combination of types for base and derived units, so you have a > multiplicative explosion on your hands In fact, I designed some generics to test this and found that the real problems are: 1) no notion of zero, 2) difficult to determine the 'Last and 'First, and 3) most other normally available attributes are not available. > (e) , (f), and (g) from your posting. I give you the points on those. My suggestion, however, does work for some situations. In experimenting with this idea, I decided to export the appropriate mathematical functions after instantiating the generic elementary functions within the body for the abstract number. I agree that the final numeric package is very specialized but it seems to have a small range of applicability for some circumstances. Meanwhile, I am experimenting with other options that might permit a solution without new language features. I will report on my findings if they are at all interesting. Richard Riehle ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Dimensions (was Re: Another Idea for Ada 20XX) 2001-12-08 3:52 ` Richard Riehle @ 2001-12-08 5:28 ` Mark Lundquist 2001-12-08 18:59 ` Matthew Heaney 2001-12-08 21:23 ` Wes Groleau 2001-12-09 22:15 ` Robert C. Leif, Ph.D. 2 siblings, 1 reply; 35+ messages in thread From: Mark Lundquist @ 2001-12-08 5:28 UTC (permalink / raw) "Richard Riehle" <richard@adaworks.com> wrote in message news:3C118E95.B5F013C8@adaworks.com... > Mark Lundquist wrote: > > > > I have no idea what you're getting at with the "helper type to avoid > > recursion"... :-) > > In implementing the infix operators for an experimental version of this > package, I found myself having to solve the problem of having the > full definition of the type as a numeric type itself. Hmm, if I'm understanding this correctly, it's you always have this problem when deriving privately and re-exporting the primitives of the base type (it's not unique to numeric types and/or infix operators). You can always convert up to the base type and back down again in the body of the primitive, right? Anyway, this is OT from our dimensions discussion, sorry... > > Actually, I think (a) is worse than (b). One could define the package > as generic and include generic formal parameters for the range constraints. That gives you something analogous to declaring a type whose first subtype is constrained (in fact I guess that's just how you would write the full type definition in your generic spec), where you do not intend to create any other subtypes. That's pretty limiting... you get nowhere near the full power of the subtyping system. > In fact, I designed some generics to test this and found that the real problems > are: 1) no notion of zero I hadn't thought of that... yeah, that is a problem. > > > (e) , (f), and (g) from your posting. > > I give you the points on those. > > My suggestion, however, does work for some situations. Sure, but it's survival, it's no way to live :-) > > Meanwhile, I am experimenting with other options that might permit a solution > without new language features. I will report on my findings if they are at all > interesting. > Sounds good :-) -- Mark ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Dimensions (was Re: Another Idea for Ada 20XX) 2001-12-08 5:28 ` Mark Lundquist @ 2001-12-08 18:59 ` Matthew Heaney 0 siblings, 0 replies; 35+ messages in thread From: Matthew Heaney @ 2001-12-08 18:59 UTC (permalink / raw) "Mark Lundquist" <mlundquist2@attbi.com> wrote in message news:FxhQ7.15837$ER5.268492@rwcrnsc52... > > "Richard Riehle" <richard@adaworks.com> wrote in message > news:3C118E95.B5F013C8@adaworks.com... > > Mark Lundquist wrote: > > > > > > I have no idea what you're getting at with the "helper type to avoid > > > recursion"... :-) > > > > In implementing the infix operators for an experimental version of this > > package, I found myself having to solve the problem of having the > > full definition of the type as a numeric type itself. > > Hmm, if I'm understanding this correctly, it's you always have this problem > when deriving privately and re-exporting the primitives of the base type > (it's not unique to numeric types and/or infix operators). You can always > convert up to the base type and back down again in the body of the > primitive, right? Anyway, this is OT from our dimensions discussion, > sorry... This is an issue with the implementation of ADT's in Ada, that often trips up the beginner. It may seem perfectly reasonable to do this: package P is type T is private; function "+" (L, R : T) return T; private type T is new Integer; --or whatever end P; package body P is function "+" (L, R : T) return T is Sum : T := L + R; --oops begin if Sum > 100 then --this type does "clamping" Sum := 100; end if; return Sum; end "+"; end P; The problem is that with this type, externally you want "+" to have one behavior, but internally you want "+" to have it's "normal" behavior. But in the implementation above, you have infinite recursion, because the compiler doesn't make the same distinction you do. There are a couple of ways to solve this problem. I. Implement that ADT as a private derivation: package P is type T is private; function "+" (L, R : T) return T; private type T_Rep is new Integer; type T is new T_Rep; end P; Here is there is no problem, because the special "+" operation applies to T, not T_Rep, so at least you now have a way to get back the "normal" behavior of "+": package body P is function "+" (L, R : T) return T is Sum : T_Rep := T_Rep (L) + T_Rep (R); begin if Sum > 100 then Sum := 100; end if; return T (Sum); end "+"; end P; II. Implement the ADT as a record: package P is type T is private; function "+" (L, R : T) return T; private type T is record Rep : Integer; end record; end P; Now there is no comflict, because a record type doesn't already have a "+" operator: package body P is function "+" (L, R : T) return T is Sum : Integer := L.Rep + R.Rep; begin if Sum > 100 then Sum := 100; end if; return T'(Rep => Sum); end "+"; end P; Ada83 probably would have been simpler had only records were allowed as implementations of ADT's -- which is the case for Ada95 tagged types. Oh well, live and learn. III. For non-private ADT's What I showed above (at least in I) applies when you have a private type implemented as a scalar type. If you don't need a private type, then you have another option. You're allowed to "squirral away" the predefined operator, prior to overriding it: package P is type T is new Integer; function Predefined_Add (L, R : T) return T renames "+"; function "+" (L, R : T) return T; end P; Now you have an explicit way of getting back to the predefined operator: package body P is function "+" (L, R : T) return T is Sum : T := Predefined_Add (L, R); begin if Sum > 100 then Sum := 100; end if; return Sum; end "+"; end P; ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Dimensions (was Re: Another Idea for Ada 20XX) 2001-12-08 3:52 ` Richard Riehle 2001-12-08 5:28 ` Mark Lundquist @ 2001-12-08 21:23 ` Wes Groleau 2001-12-09 22:15 ` Robert C. Leif, Ph.D. 2 siblings, 0 replies; 35+ messages in thread From: Wes Groleau @ 2001-12-08 21:23 UTC (permalink / raw) On another project, I implemented two variations of dimensioned numbers. package Units in the deliverable code was several KSLOC. It provided a ... is digits ... for each unit of measure on the project's allowed units list, all the conversion factors between them, and all the "legal" operators we could think of. There were two ways to create "*" or "/" (1) a generic that would always raise an exception or a generic that took left, right, and result types and a multiplier (conversion factor). It was a pain to write it and check it, but it worked well as part of a five MegaSLOC product. package Unitized_Numbers in the testing software used a private type with a Units discriminant and a value. Much smaller, easier to write, but the loss of attributes and other features of numeric types was a slight disadvantage. It would have been a much bigger disadvantage if it had to be used for any complicated algorithms. -- Wes Groleau http://freepages.rootsweb.com/~wgroleau ^ permalink raw reply [flat|nested] 35+ messages in thread
* RE: Dimensions (was Re: Another Idea for Ada 20XX) 2001-12-08 3:52 ` Richard Riehle 2001-12-08 5:28 ` Mark Lundquist 2001-12-08 21:23 ` Wes Groleau @ 2001-12-09 22:15 ` Robert C. Leif, Ph.D. 2 siblings, 0 replies; 35+ messages in thread From: Robert C. Leif, Ph.D. @ 2001-12-09 22:15 UTC (permalink / raw) To: comp.lang.ada From: Bob Leif To: Richard Riehle, Nick Roberts et al. I am trying to find a free version of ABBET. ABETT has an approach to dimensions. The IEEE charges for a standard that they do not support and ship it as paper. I believe that this work was primarily done by Bill Whitaker. 1226.1-1993 IEEE ABBETa Trial-Use Standard for Common Ada Packages for A Broad-Based Environment for Test (ABBETa) 1993 1993/ Softcover /104pp List Price:$76.00 IEEE Member Price:$61.00 ISBN 1-5593-7360-1 IEEE Product No. SH16709-TBR Product Size: 8.5 x 11 IEEE Standard No.:1226.1-1993 Availability: Available to Ship I hope that in Richard Riehle's generic approach, that the Metric_Number into a record containing a into a Quantity and Units_Type. One approach is to declare the types of the acceptable units in terms of their exponents. Then addition-subtraction requires that the exponents match; and multiplication-division only adds or subtracts the exponents. The input, output, and checkpoints could be strongly typed to only include allowable combinations of the individual Unit_Exponents and quantities. Assertions could possibly be used for this checking. The hard part is to eliminate as much as is prudent of the exponent run-time type checking of the Units. Type Units_Exponents_Type is record Current_Exponent : Unit_Exponent_Type; Luminescense_Exponent : Unit_Exponent_Type; Temperature_Exponent : Unit_Exponent_Type; Mass_Exponent : Unit_Exponent_Type; Moles_Exponent : Unit_Exponent_Type; Length_Exponent : Unit_Exponent_Type; Time_Exponent : Unit_Exponent_Type; End Record; I might note that I would like to be able to make the quantity base 10. One can not easily do the equivalent of a decimal floating point type with type decimal. It is simpler to use units that have not be scaled for internal calculations. I wrote a package to use the correct prefix for output. type Prefix_Type is (Yotta, Zetta, Exa, Peta, Tera, Giga, Mega, Kilo, Hecto, Deka, No_Exp, Deci, Centi, Milli, Micro, Nano, Pico , Femto, Atto, Zepto, Yocto); -----Original Message----- From: comp.lang.ada-admin@ada.eu.org [mailto:comp.lang.ada-admin@ada.eu.org]On Behalf Of Richard Riehle Sent: Friday, December 07, 2001 7:53 PM To: comp.lang.ada@ada.eu.org Subject: Re: Dimensions (was Re: Another Idea for Ada 20XX) Mark Lundquist wrote: > "Richard Riehle" <richard@adaworks.com> wrote in message > news:3C0EF0A0.9F42EDB4@adaworks.com... > > > > > package Metric_Number is > > type Metric_Type is private; > > -- export services for arithmetic on this type > > function "+"(L, R : Metric_Type) return Metric_Type; > > -- more arithmetic and boolean functions > > private > > -- full definition for the Metric_Type; > > -- helper type to avoid recursion during implementation > > end Metric_Number; > > I have no idea what you're getting at with the "helper type to avoid > recursion"... :-) In implementing the infix operators for an experimental version of this package, I found myself having to solve the problem of having the full definition of the type as a numeric type itself. > But in any case, the "good old-fashioned encapsulation" > isn't enough (see below)... > All these schemes that rely on hiding the representation have some serious > weaknesses. First of all, the public view is not scalar. So > > (a) your type is not compatible with generics that take scalar formals -- > you are limited to formal private types; and Granted. One would be required to write one's own versions of the generics and that would be a really bad idea. Once again, I experimented with this and ended up with some truly baroque code; workable but baroque. > (b) you cannot declare subtypes with range constraints. > (In my opinion (b) is by far the worse of these). Actually, I think (a) is worse than (b). One could define the package as generic and include generic formal parameters for the range constraints. > (c) it's way labor-intensive In experimenting with this idea, I found that I could factor out some properties to make it less labor-intensive than it might seem to be at first glance. Nevertheless, you are correct that it is more labor intensive than the more straigthforward approach orginally suggested. > But the worst is still to come :-). These schemes are quite brittle and > unscalable, because: > > (d) you have to define all your visibly quasi-numeric operations on every > combination of types for base and derived units, so you have a > multiplicative explosion on your hands In fact, I designed some generics to test this and found that the real problems are: 1) no notion of zero, 2) difficult to determine the 'Last and 'First, and 3) most other normally available attributes are not available. > (e) , (f), and (g) from your posting. I give you the points on those. My suggestion, however, does work for some situations. In experimenting with this idea, I decided to export the appropriate mathematical functions after instantiating the generic elementary functions within the body for the abstract number. I agree that the final numeric package is very specialized but it seems to have a small range of applicability for some circumstances. Meanwhile, I am experimenting with other options that might permit a solution without new language features. I will report on my findings if they are at all interesting. Richard Riehle ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Dimensions (was Re: Another Idea for Ada 20XX) 2001-12-07 22:51 ` Dimensions (was Re: Another Idea for Ada 20XX) Mark Lundquist 2001-12-08 3:52 ` Richard Riehle @ 2001-12-10 14:09 ` Ian 1 sibling, 0 replies; 35+ messages in thread From: Ian @ 2001-12-10 14:09 UTC (permalink / raw) "Mark Lundquist" <mlundquist2@attbi.com> wrote in message news:<7KbQ7.13821$L51.28784@rwcrnsc54 > But the worst is still to come :-). These schemes are quite brittle and > unscalable, because: > > (d) you have to define all your visibly quasi-numeric operations on every > combination of types for base and derived units, so you have a > multiplicative explosion on your hands Not if you define each only in terms of the nearest suitable type and chain the conversions between them. Then you only have an O(N) expansion where N is the number of unit types. If at compile time a table is constructed with the conversions used in any builds then thes will not be large in number. E.g. 1 yard is 3 feet which is 3*12 inches which is 3*12*0.00254 metres. I don't see any unsurmountable problem. > (e) the explosion continues if you want more than one unit per dimension. > It explodes in both new overloadings of the quasi-numeric operations, and > also in the unit conversions. See above. No explosion. > Mark Ian ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Another Idea for Ada 20XX 2001-12-02 19:51 Another Idea for Ada 20XX Gautier Write-only-address 2001-12-02 22:36 ` James Rogers @ 2001-12-03 14:56 ` Mark Lundquist 2001-12-06 15:27 ` Philip Anderson 1 sibling, 1 reply; 35+ messages in thread From: Mark Lundquist @ 2001-12-03 14:56 UTC (permalink / raw) "Gautier Write-only-address" <gautier_niouzes@hotmail.com> wrote in message news:mailman.1007322723.31592.comp.lang.ada@ada.eu.org... > >From: James Rogers > > >In scientific terms a measurement is done in terms of some unit. > >For instance, distance is in meters, microns, feet or furlongs. > > The overhead is not only computational, I fear: if programmers > are forced to specify the unit of each of their variables > with a possible physical meaning, they just won't program in > Ada... Only if they have to give distance in "furlongs"! :-) But seriously... no, the idea would not "force" programmers to do specify. Units are unlike types in that they are optional (think about it, what units would you give for Pi?). What it would do is make it possible (but not necessary) for you to write a subprogram that takes its inputs in certain units. Callers of the subprogram would then have to supply parameters of a correctly dimensioned type, which might entail a unit conversion. Note that it is probably necessary to provide conversions to and from dimensionlessness, so if the client wants to do everything without units (keeping track of this manually just as we do today), they can still do that (taking their life into their own hands) by applying a conversion at the point of the call to your routine. > > Where is the problem, indeed ? Mixing feets and meters in a > program ? This is more a political or cultural problem, I > wouldn't wish to complicate Ada with it... No, the idea does not complicate Ada with political/cultural problems. I don't Jim's suggestion extends to adding standardized physical units to the language, only the ability to abstract unit relationships. The language would not care (nor do I) whether feet and meters are mixed in a program; the point is that such a mixing (a) cannot be inadvertent, (b) is revealed in the source text, and (c) cannot be a source of errors. Really it would be quite a convenience and a savings of bother for the programmer. I don't know why anyone would not want it (OK, so maybe if I were to actually write enough of a proposal... :-) -- mark ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Another Idea for Ada 20XX 2001-12-03 14:56 ` Another Idea for Ada 20XX Mark Lundquist @ 2001-12-06 15:27 ` Philip Anderson 2001-12-07 22:51 ` Mark Lundquist 0 siblings, 1 reply; 35+ messages in thread From: Philip Anderson @ 2001-12-06 15:27 UTC (permalink / raw) Mark Lundquist wrote: > <snip> > Units are unlike types in that they are optional (think about it, what units > would you give for Pi?). <snap> I don't think units are "optional", although they may be dimensionless, ie just numbers like Pi. Note that radians, being a ratio, are actually dimensionless. -- hwyl/cheers, Philip Anderson Alenia Marconi Systems Cwmbr�n, Cymru/Wales ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Another Idea for Ada 20XX 2001-12-06 15:27 ` Philip Anderson @ 2001-12-07 22:51 ` Mark Lundquist 2001-12-10 9:01 ` Dmitry A. Kazakov 0 siblings, 1 reply; 35+ messages in thread From: Mark Lundquist @ 2001-12-07 22:51 UTC (permalink / raw) "Philip Anderson" <phil.anderson@amsjv.com> wrote in message news:3C0F8E75.4F5CB3B8@amsjv.com... > Mark Lundquist wrote: > > > <snip> > > Units are unlike types in that they are optional (think about it, what units > > would you give for Pi?). > <snap> > > I don't think units are "optional", although they may be dimensionless, > ie just numbers like Pi. Eh? OK, so I'll ask again, what units would you give for Pi? > Note that radians, being a ratio, are actually > dimensionless. No, they are not! (BTW rate is also the ratio of distance/time, and of course rate isn't dimensionless -- any more than radians are!) The dimension of angle is distance/distance. (I'm not making this up -- the SI define radians in terms of meter*(meter**-1)). That's why when you multiply a distance by an angle, you get a distance. But if you were to multiply a mass by an angle, you do not get a mass (which would make it a unit conversion), but something whose units would be "kg-radians". (What use would that have? Beats me, for all I know there might be one... I'm a physics 'tard, my wise-ass PhD little brother got all the physics genes :-) :-) Dimensionless numbers do not change the units when you multiply them, that's the difference. No measurement is dimensionless. Cheers, Mark ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Another Idea for Ada 20XX 2001-12-07 22:51 ` Mark Lundquist @ 2001-12-10 9:01 ` Dmitry A. Kazakov 0 siblings, 0 replies; 35+ messages in thread From: Dmitry A. Kazakov @ 2001-12-10 9:01 UTC (permalink / raw) On Fri, 07 Dec 2001 22:51:47 GMT, "Mark Lundquist" <mlundquist2@attbi.com> wrote: > >"Philip Anderson" <phil.anderson@amsjv.com> wrote in message >news:3C0F8E75.4F5CB3B8@amsjv.com... >> Mark Lundquist wrote: >> > >> <snip> >> > Units are unlike types in that they are optional (think about it, what >units >> > would you give for Pi?). >> <snap> >> >> I don't think units are "optional", although they may be dimensionless, >> ie just numbers like Pi. > >Eh? OK, so I'll ask again, what units would you give for Pi? > >> Note that radians, being a ratio, are actually >> dimensionless. > >No, they are not! > >(BTW rate is also the ratio of distance/time, and of course rate isn't >dimensionless -- any more than radians are!) > >The dimension of angle is distance/distance. (I'm not making this up -- the >SI define radians in terms of meter*(meter**-1)). There are lot of formulae involving Pi, which you can derive Pi units from. Consider formula of volume, or better Euler's -1= exp (j*Pi) (:-)). >That's why when you >multiply a distance by an angle, you get a distance. But if you were to >multiply a mass by an angle, you do not get a mass (which would make it a >unit conversion), but something whose units would be "kg-radians". (What >use would that have? Beats me, for all I know there might be one... I'm a >physics 'tard, my wise-ass PhD little brother got all the physics genes :-) >:-) > >Dimensionless numbers do not change the units when you multiply them, that's >the difference. No measurement is dimensionless. This includes dimensionless numbers as well. For instance, when we count, the result is measured in fingers (:-)). Regards, Dmitry Kazakov ^ permalink raw reply [flat|nested] 35+ messages in thread
end of thread, other threads:[~2001-12-10 20:59 UTC | newest] Thread overview: 35+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-12-02 19:51 Another Idea for Ada 20XX Gautier Write-only-address 2001-12-02 22:36 ` James Rogers 2001-12-03 12:44 ` Marc A. Criley 2001-12-03 14:29 ` Larry Kilgallen 2001-12-04 0:25 ` Marc A. Criley 2001-12-04 1:40 ` Adrian Hoe 2001-12-04 1:56 ` Larry Kilgallen 2001-12-04 16:08 ` Wes Groleau 2001-12-04 17:48 ` Larry Kilgallen 2001-12-09 23:02 ` Nick Roberts 2001-12-10 16:22 ` Stephen Leake 2001-12-10 17:11 ` Wes Groleau 2001-12-10 20:30 ` Robert C. Leif, Ph.D. 2001-12-10 20:59 ` Wes Groleau 2001-12-10 17:09 ` Wes Groleau 2001-12-10 17:32 ` Larry Kilgallen 2001-12-04 19:59 ` Vincent Marciante 2001-12-04 20:20 ` Wes Groleau 2001-12-04 22:18 ` Matthew Heaney 2001-12-06 4:14 ` Richard Riehle 2001-12-06 17:39 ` Wes Groleau 2001-12-07 0:55 ` Adrian Hoe 2001-12-07 9:01 ` Dmitry A. Kazakov 2001-12-07 11:49 ` Tarjei T. Jensen 2001-12-07 22:51 ` Dimensions (was Re: Another Idea for Ada 20XX) Mark Lundquist 2001-12-08 3:52 ` Richard Riehle 2001-12-08 5:28 ` Mark Lundquist 2001-12-08 18:59 ` Matthew Heaney 2001-12-08 21:23 ` Wes Groleau 2001-12-09 22:15 ` Robert C. Leif, Ph.D. 2001-12-10 14:09 ` Ian 2001-12-03 14:56 ` Another Idea for Ada 20XX Mark Lundquist 2001-12-06 15:27 ` Philip Anderson 2001-12-07 22:51 ` Mark Lundquist 2001-12-10 9:01 ` Dmitry A. Kazakov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox