On 10/20/05, Phil Richards <news@derived-software.ltd.uk> wrote:
What are the "fundamental types" that are being referred to here? I'm guessing that it is the basis set for the dimensional analysis, and hence would be something like: length, time, mass, temperature, intensity, current, amount.
Is this a fixed set, or can it be overridden (not just extended)? (This is what, if memory serves, was one of the major points of discussion back in 2003/2004.)
By fundamental types I meant base unit classifications such as length, etc. yes. You can add your own easily anywhere with one line anywhere in code. I posted the code to do so earlier in this thread already. You can use that classification with any other classifications, for instance, you can create "currency" and use currency/time. This is all covered already earlier in the thread. On 10/20/05, Phil Richards <news@derived-software.ltd.uk> wrote:
What I mean be overridden is: Could I choose to use velocity, force, and pressure as the basis for my dimensional analysis (so rather than thinking of velocity as "length / time", length would be represented as "pressure^-1 force^1 velocity^-2")
You can do that as well by just creating your own "velocity" base classification separate from the one I define. This would be rather silly though as well as pointless. Currently you wouldn't be able to convert your base classification to the more natural derived classification implicitly. This could easily be added, but I don't think it is necessary. On 10/20/05, Phil Richards <news@derived-software.ltd.uk> wrote:
can I constrain what various parts of the code are doing so that that expression would be invalid because "physical quantities" do not have a "bedknobs" dimension?
No. I don't really see the benefit of that. On 10/20/05, Phil Richards <news@derived-software.ltd.uk> wrote:
SI::length<double> footInMeters = convert_units<SI>(foot); which would store a value of 0.3048 in footInMeters (since the internal representation is in units of meters). Personally, I'm with Deane Yang: I don't like implicit conversions.
Well, implicit conversions is how it will be at least for this version since it's already all in place. I still don't see why you would want to force all explicit conversions. Quantities in meters, centimeters, feet, inches, miles, etc. all represent the same concept and should be able to be converted between behind the scenes. Nothing logically bad ever comes from it at that level of abstraction. Even Deane's example of why he wanted the functionality seemed completely specific to the way his project worked. Adding years to months in his case isn't unnacceptable because they are different units, it's just that he chose to use years and months in two separate modules, and just in the case of that project, he wouldn't ever need to add what the represent together. It's not because it doesn't make sense to add the concept of years with months. Changing the example slightly to better explain, one could very well have two different modules only now both are using years, though you may not logically ever want to add them together. The fact that you don't want to add them together really has no direct link to the fact that they are different units or the that they are the same units, but because at a higher level in your project than the quantities themselves, you shouldn't have to be adding them together. This type of abstraction, in my opinion, has absolutely no reason for being expressed at the library level. If you want that functionality, again, it's because of restrictions at a higher level in code than just "quantities". In actuality, I'd say the better solution, even if explicit conversions were forced by the library, would be for you to make a type which encapsulates one concept and a different type which encapsulates the other concept, since that higher level abstraction is what disallows the conversion, not the fact that they are different units. At this moment, the only result I see from adding direct support for quantities all requiring explicit conversions to the library is uneccessary bloating since the restrictions you desire are better expressible with higher-level code than a quantities library should provide. On 10/20/05, Phil Richards <news@derived-software.ltd.uk> wrote:
I've never actually needed this level of functionality, so I've never be inclined to wonder whether it was overly restrictive or not :-)
Neither do I. Length plus length is fine. Mass minus mass is fine. Time divided by time is fine. The underlying units used are merely implementation details. Restricting such operations merely because the underlying units of the dimensions are different does not make sense. They represent the same exact thing! Right now, the only exceptions to this rule that I see occur in abundance with dimensionless quantities, such as with radians and steradians, since implicit conversion between them doesn't make logical sense, despite the fact that they are of the same derived classification. Also, I wanted a version out for people to play with earlier this week, but with all of the discussion from last week and the amount of work I have to do this week, you'll have to wait a little bit longer; I'm just going to try to finish up getting expression rearrangement fully completed, as at the moment it's half-implemented. Toggles to turn individual optimizations off won't be implemented yet so that I can get it out earlier for people to use. -- -Matt Calabrese