Matthias Schabel said: (by the date of Mon, 15 Jan 2007 21:42:39 -0700)
As I mention in my previous post, I could easily add a quantity in the SI namespace that allows double precision by default and inverts the order of the template arguments. I am also not strongly opposed to flipping the order in quantity itself, so the value_type is the second argument:
template<class Unit,class Y = double> class quantity;
You can look at Boost.Parameter http://www.boost.org/libs/parameter/doc/html/index.html It allows to use both argument orders in a single template, I mean: template<class Unit,class Y = double> class quantity; template<class Y, class Unit> class quantity; become the same template. But in fact, maybe following Ockham's razor you should just follow your suggestion and use template<class Unit,class Y = double> class quantity; because 'class Unit' *cannot* have a reasonable default. While class Y=double *can* have a default. I hope that you have read the reviews of Andy's Little quantity library, and why it was rejected. Some of the reasones were considered show-stoppers. I remember few of them, but better you will read the reviews. Here's what I remember: 1) support for powers of N (where N is different from 10) in multipliers: usually people operate using kilo (10^3), mega (10^6). But sometimes a unit is expressed in different system, like a power of 2 (harddrive capacity, file size: http://en.wikipedia.org/wiki/Kibi ) 2) try to decouple: A) dimension analysis (length,temperature,velocity) B) from dimension units (meter,inch,kelvin,fahrenheit,kph) C) from dimension multipliers (kilo, mega, kibi) Because: A) people might want to use ONLY dimension analysis in their program without any units at all. During compilation compiler witll check ONLY if the dimensions of the variable match. For example one variable is length another is a temperature, and the compiler will catch an error when someone tries to add them. BUT the program will NOT perform any conversions (for example from inch to meters) because the dimension units are not used. B) if someone decides to use them, he agrees that some additional work is done by the program when converting (implicitly, or explicitly) from inches to meters. C) only those multipliers that are declared either by the user, or in an included file that contains some predeclared multipliers are used by the program. Allow the user to chose between explicit and implicit conversion, when he wants. You don't know if someone wants to store 1km or 1000m in his variable. 3) Do not eforce SI on anyone: Make it easy to declare one's own unit system. This point it is not about imperial and metric. It is about physics. For instance parsecs and light-years do not belong to SI. But try to store 100 parsecs with 'double' precision using meters. (or yottameters 10^24 (?)). This is not practical, any calculations that operate on parsecs must be done in parsecs, or we lose precision. Of course you can provide few #include <boost/unit/SI.hpp>, #include <boost/unit/imperial.hpp>, #include <boost/unit/relativity.hpp>, etc files. But you never know what kind of unit system will be useful for somebody. It should be equally easy to declare that I will use a meter (1 line) and a second (1 line, makes 2 lines total) in my program, instead of including whole SI.hpp (1 line), which I don't need. For instance in calculations involving general relativity, the speed is expressed dimensionless. (because it is always a fraction of light-speed). 4) Make input/output as decoupled as possible. Basic cout << of the unit is enough for beginning. Do NOT make it sophisticated in any way, otherwise you will start writing another library. 5) leave door open for adapting your library into other math libraries. For example, let's say that I have a 3D vector of meters: vector<3,quantity<meter> > a,b; vector<3,quantity<meter*meter> > c; c=dot_product(a,b); What is the return type of function dot_product ? Think about it, and you will see what I mean. Where that function is defined? Well, boost still has not a small vector library, but you should leave an open door for making one. Ok, I don't remember any more. Better you will have a look at that reviews. I still have them in my inbox, so in fact I can forward them to you. -- Janek Kozicki |