Re: [boost] [fixed_point] Request for interest in a binary fixed point library

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.