AMDG Martin Schulz <Martin.Schulz <at> synopsys.com> writes:
Hello everybody,
my background is in software development for scientific and engineering computing, facing complex applications in industry. Therefore, I may take the opposite stand here. For fairness, I must add that I am somewhat from the competion, as I have started my own little (not yet upgrown) project in this area.
Practically speaking, when developing such a technically minded piece of software, approximately 30% of the development effort goes into the computation kernel whereas the remaining 70% of the effort goes to the overall infrastructure, business layer, presentation layer (batch, gui, api,..), interoperability, productizing etc. It is sad to say, but such is life.
<snip>
I feel a far stronger need for a physical unit library in two other parts: Namely the business locgic and the presentation layer.
<snip>
I'm sorry. I don't understand what you are getting at. would something like this be more acceptable. unit meters(_symbol = "m", _conversion_factor_to_si = 1); unit kilograms(_symbol = "kg", _conversion_factor_to_si = 1); unit seconds(_symbol = "s", _conversion_factor_to_si = 1); unit joules(kilograms * meters * meters / (seconds * seconds), _symbol = "J", _name = "Joule"); unit hours(_name = "hour", _conversion_factor_to_si = 1/(3600.0)); unit kilowatt_hours(joules / seconds * hours, _name = "kilowatt-hour"); quantity<double> energy(2.89 * joules); Or is it primarily IO that you want. istringstream stream("1.29038761 J"); quantity<double> energy; stream >> energy; cout << symbol << energy << endl; //1.29038761 J cout << name << energy << endl; //1.29038761 Joule assert(energy.value() == 1.29038761); assert(energy.unit() == joules); energy.convert_to(kilowatt_hours); cout << name << energy << endl; //... kilowatt-hours
I like the notion of a unitsystem as a mean of choice for the internal represenation of the quantities (and have already taken that idea to my own project). On the other hand: the length of my desk is a physical quantity that exists independently of the unit it is expressed in. The numerical value of that quantity is only fixed for a given unitsystem but this is an implementation detail, not a principal thought or definition. Thus I find the definition "A quantity is defined as a value of an arbitrary value type that is associated with a specific unit." somewhat irritating.
Trying to give a quantity an absolute meaning leads to defining everything in terms of SI.
Some more details: ------------------
<snip>
I got the impression that the intent of the following code is not so obvious: quantity<force> F(2.0*newton); std::cout << "F = " << F << std::endl; The author states that the intent is obviously F = 2 m kg s^(-2); In contrast to the author, I personally would naturally expect something like: F = 2.0[N] This issue is not half as superficial as it might seem at first glance. In fact that is what the whole presentation layer stuff is all about.
I agree. The ouput that we have is not really useful for anything other than debugging.
I have yet to see any stringend need for rational exponents. They rather obscure the physical meaning of certain terms, imho.
They are present because someone needed them.
To define all possible conversions of n unitsystems, you'll need about O(n*n) helper structs to be defined. I may be overlooking some more elaborated automatism, though. However, we are likely to face a larger number of unitsystems as already the conversion of "cm" in "m" requires different systems.
Yes. That is a problem. There is no way to avoid it that I know. Suppose that you need meters, feet, furlongs, and miles. Then, you will need 12 conversion factors. Now, it would be possible for the library to automatically work out meters->feet e.g. if feet->meters is already defined, but that still requires O(n*n) specializations. Unless the library makes one unit special there is no way to reduce this to O(n).
The handling of temperatures (affine units in general) is correct but not very practical.
The executive summary: ----------------------
<snip>
Thanks for you comments. In Christ, Steven Watanabe