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: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-04-16 18:38:29

Le 16/04/12 23:44, Christopher Kormanyos a écrit :
> <big snip>
>
>> Would this syntax be convenient? Or, do we need something intermediary as
>> f1 = convert(1.2345);
>> f2 = convert(f1 - 2);
>> f2 = convert(f1 / f2);
>> The template function convert will return a wrapper of its parameter that is accepted as an implicit conversion.
> <snip>
>> Best, Vicente
> As always, good luck with a project of such importance and complexity.
>
> I'm relatively new here. But I am concerned about the above-mentioned dialog.
>
> Perhaps I have not understood this dialog because the discussion was at
> a relatively high level of C++ abstraction. But boost already has a policy
> on mixing specialized numeric types with built-in types. As far as I know,
> a specialized type in boost is supposed to seamlessly interact with
> all built-in types on both the left-hand as well as the right-hand side
> of all expressions.
>
> 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

f1-2

could be interpreted as

f1 - (decltype(f1))(2)

But the conversion of f1 - (decltype(f1))(2) to f2 should be explicit in a open world and implicit in a closed world. (see below).

>
> About converting
>
> fixed_point<unsigned bits_mantissa,
>                      signed bits_fraction>
>
> 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.
>
> You might have this:
>    fixed_point<15, -16>  radius<123, 100>(); // Ratio of approx. 1.23
>
> And you want to go to this:
>    fixed_point<15, -16>  result1 = pi_rep<15, -16>() * (radius * radius); // Should work!
>
> OK.
Well, it should or not. I think that it should work only if

A * A -> A

which I pretend is not always a good thing. I'm not saying that in other 
contexts this is not acceptable.

I think that we have two kind of fixed-point arithmetic
* open A * A -> 2A
* close A * A -> A

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 expect this to work in the closed fixed point-world
   fixed_point<4, -14> result2 = pi_rep<2, -8>() * pi_rep<2, -6>();

Or should the user need to convert the parameters before to 
fixed_point<4, -14>?
   fixed_point<4, -14> result2 = fixed_point<4, -14>(pi_rep<2, -8>()) * 
fixed_point<4, -14>(pi_rep<2, -6>());

That is, does the closed fixed-point hierarchy define mixed fixed-point 
arithmetic, other than the one with builtin?

A*B->C

In my opinion it will be confusing if

A*A->A
and
A*B->C
> But if you want to go to this:
>    fixed_point<7, -8>  result2 = pi_rep<15, -16>() * (radius * radius); // Should not work!
>
> In my opinion, it should not work. The user should explicitly convert
> to the other fixed-point type with copy-construct.
I agree this conversion must be explicit in any case.

>
> But this should work:
>    fixed_point<15, -16>  result3 = 3.141592654 * (radius * radius); // Should work!
>
>
In a closed world, yes.

Best,
Vicente