Re: [boost] GSOC 2013

Subject: Re: [boost] GSOC 2013
From: Dmitriy Gorbel (dmitriycpp_at_[hidden])
Date: 2013-04-22 18:35:50

Vicente Botet wrote
> Dmitriy,
> what is your opinion about this?
> 
> Best,
> Vicente 

Sorry for the delay, I was busy at the weekend. 
At first thanks for your comments - I really not thought about some issues
before reading it.

Vicente Botet wrote
> Your proposal must state clearly whether you want to implement binary or
> decimal fixed points.

I propose the binary fixed-point type. I will emphasize it in the proposal.

Vicente Botet wrote
> What would you add to the C++1y proposal? 

I want to add some math functions, include ceil, floor, sqrt, sin, cos, exp,
fabs, etc. 
Functions must work similar to standard C function with same name, but with
fixed point numbers.  
I think it would be useful for end user.

Vicente Botet wrote
> Why the range and resolution must be static? Which advantages would have
> a run-time range and/or resolution? On which context each approach is
> preferable? 

I think run-time range and resolution more 	
comfortable and useful, but require more resources.

Vicente Botet wrote
> What kind of problems have floating point types? Are you aware of the
> problems fixed point numbers have respect to floating point numbers? 
> 
> How fixed-point number solves the problems fixed-point numbers have? 

Floating point arithmetic has a lot of problems, really. 
For example limited exponent range, loss of significance, unsafe standard
operations.
For exploring floating point problems I read 
http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems 
and http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html

I think main advantage of the  fixed-point numbers - customizable range and
resolution, hence more efficient.

Vicente Botet wrote
> Why do you say that "undefined behavior after signed integer arithmetic
> overflow". 

I mean that signed integer overflow causes undefined behavior.

Vicente Botet wrote
> Are you aware of the limitations of the C++11 proposal? Could it be used
> on embedded systems? 

I think it depends on concrete embedded system and software developer. 
For example, templates are useful for making generic classes or functions.
But they may increase the program size, which is critical for embedded
systems applications. 
Furthermore, templates may increase the time of compilation.

I know that some embedded developers avoid templates, namespaces,
exceptions,
virtual inheritance, etc.

Vicente Botet wrote
> What would be the result of
> nonnegative<8,-4>+nonnegative<8,-4>?
> 
> There are clearly several possibilities. Should your library provide the
> user with the capacity to choose? If yes, how? if not why? 

The range and resolution of the result calculate by(for addition and
subtraction):
nonnegative<max(range1,range2)+1, min(resolution1, resolution2)>

So type of the result: nonnegative<9,-4>

User can create new variable and set any capacity. I think it is enough. 

Vicente Botet wrote
> You talk about the need to round for division. Do you know of other
> cases where rounding is needed? 

Oh rounding needed in many cases. 
Rounding(or truncating) needed always when representation can't accumulate a
number precisely.
I said about division because division may have special result, with
infinite fractional part.  
For example 1/3 = 0.333333333...

Vicente Botet wrote
> Would the conversion of fixed points with different range and resolution
> be implicitly/explicitly convertibles? And respect to C++ built-in
> types? Would you provide some kind of cast between numbers? 

In comments for your library you note about conversion policy
when user can choose between  implicitly/explicitly conversion.
I will try to implement both variants.

Vicente Botet wrote
> What would be the size associated to a fixed-point type? Should it be
> defined by the library or should the library let the user give some
> hints to use the storage for the user.
> Should the classes constructor have allocators for arbitrary large
> fixed-point types? 

Do you mean size of the representation? I think, good way when user can set 	
needed size. In this case allocators will be used. But also must be
reasonable maximum size.
What's your opinion?

Vicente Botet wrote
> Do you think that it is enough to use just an enum to define the
> rounding policies or it would be better to let the user to define its
> strategy?
> The same question for overflow. 

C++1y proposal require enum for rounding and overflow mode. 
I think it is enough.

Vicente Botet wrote
> What external resources have you read in addition to the C++1y proposal?
> have you read the Boost ML archives respect to this subject? 

Yea, I read Boost ML, and  external resources. 
I really liked this introduction to  fixed-point  arithmetic.
http://www.digitalsignallabs.com/fp.pdf  

Vicente Botet wrote
> There are several notations for fixed point numbers that don't use range
> and precission. There are people that use to use these notations. How
> your library will let them to use their preferred notation?

I think notation in the proposal clean and easy for understanding. 
What is your advice  about this issue?

Vicente Botet wrote
> Are you confident with the implementation of the prototype in the
> sandbox? Do you find it is too complex? if yes, why? would you start
> from the prototype on the sandbox or would you start from zero?

Yes, I'm confident with the prototype. Honestly, it took some time for
exploring it.
Not very complex, but not simple. Just need time for understand.

I would start from zero, but I will keep near the prototype. 

Vicente Botet wrote
> Do you prefer to implement something well defined even with some
> limitations or explore the domain and see what could/should be done? 

Ohh this is hard question. I would look for middle way.

Michael Marcin-3 wrote
> There is a typo: The range must be *grater* then the resolution
> 
> I don't understand your types.
> 
> cardinal<16> 0 <= n <= 65536
> 
> This seems to be a 16 bit unsigned type but requires 17 bits to store
> this range. It should probably be 0 <= n <= 65535.
> 
> integral<4> -16 <= n <= 16
> 
> Similar here this seem to be a 5 it signed integer but requires 6 bits
> to store this range. It should probably be -16 <= n <= 15.
> 
> nonnegative<8,-4> -256 < n < 256 in increments of 2^-4 = 1/16
> 
> I don't understand how a type nonnegative can store values in (-256,0).
> 
> 
> negatable<16,-8> -65536 < n < 65536 in increments of 2^-8
>   = 1/ 256
> 
> This seems close to a fixed point type as I'm used to seeing it.
> Although again the ranges seem wrong.
> 
> I'm much more accustom to seeing fixed point number specified as
> <Magnitude bits, Fractional Bits>
>  i.e. <16,8> instead of <16,-8>.
> Still this representation makes sense because it specifies both
> parameters in terms 2^x. It also supports something like <17,1> to give
> a 16 bit type that has the range [-131072, 131071] in increments of 2.
> 
> Still it might be surprising to those familiar with the more common
> fixed-point notation. 

Here is no mistake in the example. I paste here  part of the C++1y proposal

 C++1y proposal wrote
> Basic Types
> 
> The fixed-point library contains four class templates.
>  They are cardinal and integral for integer arithmetic, 
> and nonnegative and negatable for fractional arithmetic.
> 
> These types have a range specified by an integer. 
> The range of an unsigned number n is 0 <= n < 2g where g is the range
> parameter.
>  The range of an signed number n is 2g < n < 2g. Note that the range
> interval is
>  half-open for unsigned numbers and open for signed numbers. 
> For example, cardinal<8> has values n such that 0 <= n < 256
>  and integral<8> has values n such that -256 < n < 256.
> 
> The fractional types have a resolution specified by an integer. 
> The resolution of a fractional number n is 2s, where s is the resolution
> parameter.
>  For example, negatable<8,-4> has values n such that -256 < n < 256 in
> increments
>  of 2-4 = 1/16.
> 
> Both range and resolution parameters may be either positive or negative. 
> The number of significant bits is g-s. This specification enables
> representing
>  both very small and very large values with few bits. In any event, the
> range 
> must be greater than the resolution, that is g>s. 

About the notation, what can I do for improve it and not 	
break notation from the proposal? 

I will send new version of the proposal as soon as possible.

P.S. Please, don't judge strictly my English, it really isn't very good.
Sorry... 
I will try to write clearly and carefully. 

Sincerely, 
Dmitriy.

--
View this message in context: http://boost.2283326.n4.nabble.com/GSOC-2013-tp4645089p4645863.html
Sent from the Boost - Dev mailing list archive at Nabble.com.