Boost logo

Boost :

Subject: Re: [boost] [fixed_point] Request for interest in a binary fixed point library
From: Christopher Kormanyos (e_float_at_[hidden])
Date: 2012-04-17 16:48:40

>> I believe that boost mandates implicit conversion to built-in types >> *without* a conversion-wrapper. This means that if the user selects to >> lose performance by mixing, say, double with fixed_point, then >> the user did it---willingly, that is on purpose! > I'm seen the alternatives. How the user will use the library is explicit > conversion is needed each time there is a lost of range or resolution. > It is clear that coding with this rule and mixing builtins is > cumbersome. I could admit that mixin builtins could be take as some kind > of implicit conversion and It is a lot of coding. It was previously, in fact, my preference to require explicit construction and disallow and implicit mixing of the specialized number type with built-in types. But I later learned that boost.math follows the other strategy. This is the only reason why I keep mentioning this point, because of compatibility with boost.math and a potential boost.multiprecision. >> About converting >> from one mantissa/fraction representation to another, I say don't ever do >> it without explicit ctor call or assignment operator. If you don't do this, >> then the code amount blows up beyond what it reasonably should. > Well, it should or not. I think that it should work only if > A * A -> A You can never please all of the people all of the time. But my preference is exclusively supporting the closed world. I personally do not like it if results grow-to-size. There will certainly be varying opinions on this. > I think that we have two kind of fixed-point arithmetic > * open A * A -> 2A > * close A * A -> A It just scares me to think of all the coding you will need. Explicit ctor conversion from one size fixed-point to another and assignment operator should be enough. And you can keep the code amount down. But, again, there will be different opinions on this in the community. > Each one of these arithmetic should be supported by different class > families. We could use the same name in different namespaces. Users > using only one of this families will not see the naming difference just > adding a using declaration. Do you really want to put yourself through this kind of pain? > Do you expect this to work in the closed fixed point-world >   fixed_point<4, -14> result2 = pi_rep<2, -8>() * pi_rep<2, -6>(); I do. Others might not. After all I posted, perhaps a simple summary of my thoughts might help. Basically, I recommend the following: * Do support implicit conversion from built-in types (compatibility with strategy of boost.math). * Do not support result resizing or mixed fixed-point *intelligence*. * Do support explicit conversion of mixed fixed-point but *only* via explicit ctor and copy-assign.If you take a moment to consider these top-level design choices, you will find that they, in general, lead to the simplest code and reduce the sources of error for both author and users alike. I finally adopted this strategy with my *third* formal fixed-point class. But again, one person alone can never be right and many experienced developers will have other opinions and, eventually, find the right mix in cooperation. Thanks, Vicente. Best regards, Chris.

Boost list run by bdawes at, gregod at, cpdaniel at, john at