On Fri, 14 Dec 2001 22:01:23 -0000, "Nick Roberts" wrote: >So, the expression Exp(X) is dimensionless, and X must be (checked to be) >dimensionless. Ditto for Log(X). > >The same is also true for the trigonometric functions. I recall someone >posting in this thread suggesting, in effect, that the same is also true for >square root; I'd like this confirmed. The equation X *X = Y has a solution when Y is not negative and has even powers of all base units. Thus we could define sqrt. >Secondly, I suppose the standard package >Ada.Numerics.Generic_Elementary_Functions could and should check (upon >instantiation) that the generic parameter type Float_Type is either >dimensionless or not unit-specific. Am I correct in assuming that the Cycle >parameter must always be dimensionless? > >I have accepted the idea of units being applicable to floating point types, >as well as fixed point types, with the concern that unit-specific floating >point types are (more) liable to abuse. Am I right that >Ada.Numerics.Float_Random.Uniformly_Distributed should not be unit-specific? >As a slightly separate issue, is there any merit in the idea of adding >standard packages that provide Log, Exp, sin, Cos, Tan, etc. for fixed point >types? Let's look at this from slightly other point of view. I believe that there is a lot of confusion between units and scales. Your wish to have "logarithmic" units is rightful and IMO there is an answer. It sounds "logarithmic scale". A scale determines the representation of a value, but not its dimension. With scales there would be also no fixed vs. floating point dilemma. Both are *just* different scales of the same thing *real number*. Same is with units. There is no log(m), but there can be logarithmically graduated scales of meters. If I dare to misuse Ada (:-)) it could be something like: type meters is ... type log_meters is ... if x is of meters then log_meters (x) = log_meters'Val (log (meters'Pos(x))) From this point of view Celsius degree is of course Kelvin scaled by s(x)=x+273.15. Foot is a proportionally scaled Meter etc. Happily there is no need in Cycle parameter for sin/cos, because rad and degree are of different scales [but of same unit 1 SI]. So dimensioned types of values should be characterized by two attributes, discriminants, tag whatsoever: unit and scale. [ I played with this idea for a while. It is easy to make unit discriminant a modular number. Unfortunately an attempt to use access type discriminants to represent scales is doomed to fail, because then the type shall be limited. Damn, but there are good reasons why the type with a discriminant of an access type shall be limited (sigh) ] Differently scaled values cannot be mixed but can be explicitly converted. Values of same scale can be added and subtracted [when unit is same], multiplied and divided. Now problems (:-(): 1. There are different ways to define operations on scaled values. For instance: s(X+Y) vs. s(X)+s(Y). With �C we are using the first way [2�C+2�C=4�C], with floating point numbers the second. [for scales s(x)=ax and additive/multiplicative operations they are equivalent]. 2. Multiplicative operations may produce new scales. 3. Scales and units should be matched rather "by-structure" than by-name. Last note. If we want to do it consistently then of course there should be a possibility to assign units to any type. Consider complex numbers, matrices etc. a) Let I want to implement fuzzy readings. Then I should have an ability to write "type Fuzzy_Number is private;" and give some public specification that it has a dimension. b) A biz application could treat currency as a unit and different currencies as fixed point numbers of different scales with no loss of precision as long all calculations are made in one currency. c) Let I write a matrix package. I would like to define matrices of different sizes as ones having different units. For instance NxN and Nx1 should be two different units, so I cannot add matrices of this sizes. Yet I can multiple one of NxN to Nx1 and have Nx1 matrix (vector). Then I leave all checks to the compiler (:-)) Regards, Dmitry Kazakov