On 10/10/05, Jeff Garland <jeff@crystalclearsoftware.com> wrote:
Expression rearrangement is really cool stuff, but it doesn't really impact the interface does it? If you're serious about putting it in boost it's really the interface and docs that will ultimately matter the most. Personally I'd like to see a units lib proposal sooner rather than later...
Jeff
No, it doesn't impact the interface. You use operators just like you normally would. However, I do feel the need to make expression rearrangement toggleable even if the rearrangement is fully optimized to compile-time on almost all compilers, since rearrangement of expressions could have subtle effects on precision, or even cause things like overflow or underflow in different places than in the unorganized expression. These types of things generally shouldn't be an issue, but they cause enough concern to make a mechanism to turn off the behavior if necessary. Right now I plan on adding function templates which act as expression modifiers that turn on and off reordering i.e. strictly_ordered( expression_here ) to make it such that the internal expression isn't reordered, and loosely_ordered( expression_here ) to explicitly allow the internal expression to be reordered (which can be nested inside strictly_ordered expression). Similar toggles would be made for other optimizations through expression templates. Initially, I plan on making all expressions loosely_ordered by default, but I may provide additional point, vector, and scalar templates which default to strict ordering when used in expressions if people would want such functionality. As of now, I'd prefer not to add those additional point, vector, and scalar templates, just to avoid unecessarily bloating in the library, but this opinion may change if such templates would be commonly used. Much of how I am developing the library is dependent on expression templates and many impact optimization in ways some might not initially think about. For instance, last week I realized that even simple assignment operations benefit from the expression templates. As an example, take the expression your_quantity = some_meters + some_feet; Without expression templates, you pretty much arbitrarily choose whether to convert meters to feet or feet to meters on the right side of the equals, however since the operations are now expression templates, the choice can be determined better by context. If your_quantity is a quantity in meters, then some_feet should be converted to meters in the expression. If your_quantity is in feet, then some_meters should be converted to feet in the expression. Otherwise, the complexity of the conversion decides which unit_type should be used. Such analysis of context to produce the more optimized choice is entirely possible using expression templates. On 10/10/05, Deane Yang <deane_yang@yahoo.com> wrote:
If you dig back in the archives, I tried to explain it all before, but obviously not very well. Suffice to say that a "time point" and a "point quantity" are the same type of thing and that the difference between any two such things is a "vector quantity" or equivalently a "time_duration".
Mathematicians have identified the common abstract concepts underlying these things, and I went on and on about this earlier. But I think I'm going to resist reviving all that, because I don't think it's particularly helpful. I like Matt's terminology, because it seems to be more meaningful for everyone.
I wish I had seen that conversation when it was active. I'm glad that I'm not just going crazy about these relationship, as no places I've found even make mention of them. -- -Matt Calabrese