Re: [boost] [Boost.FixedPoint] Choose notation

Subject: Re: [boost] [Boost.FixedPoint] Choose notation
From: Vicente Botet (vicente.botet_at_[hidden])
Date: 2013-04-29 13:18:51

Dmitriy Gorbel wrote
> 
>  Michael Marcin-3 wrote
>> I dislike the names. I don't really understand what the first 2 types
>> have to do with fixed-point math, other than maybe as an implementation
>> detail or degenerate fixed-point type (0 fractional bits). 
> I add cardinal and integral types to the proposal because
> this types required by C++1y proposal. I agree, this types
> quite illogical. Maybe, this types proposed for supporting big integers, 
> but I think for big integers better use Boost.Multiprecision library.
> 
> It's easy to implement integral types based on fractional, 
> using template aliases, for example:
> template
> <size_t Range>
>  using cardinal = nonnegative&lt;Range, 0&gt;;
> template
> <size_t Range>
>  using integral = negatable&lt;Range, 0&gt;;
> 
> What community think about this?
> Should library support integral fixed point types?

The implementation of fixed<Range, Resolution> needs to have as storage an
integer<Range-Resolution>.

As we need it for the implementation and its implementation is simpler than
fixed<Range,0> why not provide it to the users.

Note that this is not an arbitrary precision integer but an integer with a
fixed precision which has a different semantics (overflow).

> 
> Neal Becker wrote
>> Thank you.  The last time we discussed this topic, the issue was not one
>> of 
>> notation, but of different semantics that were desired by different end
>> users of 
>> a fixedpoint type.
>> 
>> I think there were several areas of disagreement - but perhaps primary
>> was 
>> whether arithmetic operations would produce different types or the same
>> types, 
>> and how to handle arithmetic between mixed types.  For example, does 
>> multiplication of 2 8-bit quantities promote to 16 bits or not.
>> 
>> My preference is/was that no implicit conversion was ever performed and
>> that it 
>> always had to be explicit.  This is partly because the primary consumer
>> for this 
>> technology (I think) is those working on FPGA or ASIC hardware - and they
>> should 
>> always be aware of any such conversions.
> Best way - conversion policy,
> when user can choose between implicitly/explicitly conversion.
> I will try to implement both variants. 

No, this is not solved by implicit/explicit conversion, but using closed
arithmetic. That is 

fixed<8>* fixed<8>-> fixed<8>

The C++1y proposal uses open arithmetic and

fixed<8>* fixed<8>-> fixed<16>

Using closed arithmetic the user must explicitly convert to the desired
result

fixed<8> a;
fixed<16> b = fixed<16>(a) * fixed<16>(a);
 

Best,
Vicente

--
View this message in context: http://boost.2283326.n4.nabble.com/Boost-FixedPoint-Choose-notation-tp4646262p4646306.html
Sent from the Boost - Dev mailing list archive at Nabble.com.