On Wednesday 16 March 2011 00:12:49 Gruenke, Matt wrote:
I'm not sure we're talking about the same thing, here. The template parameters of the results returned by my operators were determined by those of the operands. For instance, 8.16 + 8.8 would return a 9.16. If the result is then stored into a 16.8, then a right-shift of 8 bits is performed as part of the assignment. In the case of 0.16 * 8.8, the result is 8.24.
So, the only thing you have to think about is whether you need to force a conversion in the middle of an complex expression to avoid running out of range. But that can easily be managed by breaking up complex expressions into smaller, simpler ones.
I think the idea was to use proto to actually look at the whoel expression as a whole and figure out the needed bit storage directly then work within it
In my implementation, the size of the storage used was determined by the template parameters, such that an array of 9.7 fixed-point numbers would only take 2 bytes per element (we actually had such arrays and could not afford for them to be any larger than necessary). Since each operator was a template where the result was defined in terms of the operands, different unnamed temporaries, within an expression, could use different amounts of storage. The largest supported storage size was 64-bits, since we were interested in efficiency and required nothing larger.
This is what I have in mind as well. However, Joel's suggestion is also interesting, though I would personally consider it an optimization that can be performed once the interface is complete.
I have no experience with Boost.Proto. If the primary purpose of the proposed exercise is as a case study to demonstrate use of Proto, then perhaps my comments are of little or no relevance. However, if the primary goal is to produce the most useful and efficient fixed-point library possible, then I offer my insights and experience in hopes that a better product might result.
Your comments are very much appreciated. Your experience matches mine quite a lot; our (minor) disagreements stem, I think, mostly from my considering a larger set of use cases than just speed. Regards, Ravi