Re: [boost] GSOC 2013

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

Vicente Botet wrote
>>> As I said there are several notations and there is no real one that
>>> would make happy everyone. So I think that the library should take in
>>> account this point and provide some aliases (c++11)/type traits(c++98)
>>> for the most common notations.
>>>
>>> Choosing the default notation is critical and having a consensus on it
>>> would be difficult. Do you think that it is worth proposing several
>>> default notations and request the boost community to choose the default
>>> one?
> 
>> Yes, of course,  boost community should choose the default notation.
> 
> I would start this as soon as possible as this could take some time. I
> would start a thread as well for the naming of the different classes.
> Having to provide several notations let me think that the use of at
> least a namespace fixed_point is mandatory to don't pollute the Boost
> namespace. 

I started a thread at the ML and wait for community feedback. 

Vicente Botet wrote
>> What is the best way to provide several notations?
> Template alias? 

Just for now, if provide only 2 notations(notation from c++1y proposal and Q
notation)
I can just get absolute value from the resolution parameter. 
For example, in this two notations types same: 
negatable<8, -8> for c++1y proposal notation is equal to
negatable<8, 8> for Q notation
If users really want more than 2 notations, 
I will have to solve this issue.

Vicente Botet wrote
> As you are for using enum for rounding/overflow policies, could you add
> the policies that you must implement and when these policies will be
> implemented?

In the last days I explored closely the prototype, and
the closer I get to the prototype the more I like it :)
I really like OOP design for rounding and overflow strategies.
Moreover, exists strateges comply with the requirements of the c++1y
proposal and provide even more features. 

But c++1y proposal require enum for the strategies, 
can my proposal slightly break c++1y proposal?

Vicente Botet wrote
> I don't see when you would develop the math functions on the planning.

That's already in the specification and timeline.

Vicente Botet wrote
> Please don't forget to apply to GSoC as soon as possible so that the
> Mentors starts to evaluate your proposal and how you react to possible
> improvements. 

Link to my proposal on GSOC site
http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/dmitriy/1

Christopher Kormanyos wrote
> I have a major suggestion. You do not have to
> accept my suggestion, since I am only an observer
> of this project.
> 
> I strongly suggest limiting the scope of the GSoC
> fixed-point project to a specific number of digits,
> such as those that can fit into int8_t, int16_t, int32_t,
> and int64_t. This can be done with one template
> and one decimal split. It would allow for fixed-point
> representations all the way from Q0.63 through
> Q31.32, up to Q63.0.
> 
> I recommend this because it will make the project
> feasible when it comes to any computations
> of elementary transcendental functions. 

I strongly agree with you.
The prototype now work similar to your suggestions.

Christopher Kormanyos wrote
> I will be very difficult to develop algorithms
> for sin, cos, log, exp, for an unlimited number
> of digits extending all the way to the realm of
> multiprecision. In fact, it would be a remarkable
> feat to do it in one summer. On the other hand,
> you could plug fixed-point into multiprecision
> for digit counts exceeding, say, 64. So it is really
> up to you guys how you want to deal with this.

What if I will use Boost.multiprecision library 
for numbers with representation larger then 64 bits?
 
Now I correct my proposal, I send new version to this ML
and GSOC site as soon as possible. 

Sincerely,
Dmitriy. 

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