Re: [boost] [fixed_point] First presentation from GSoC 2015 and more

Subject: Re: [boost] [fixed_point] First presentation from GSoC 2015 and more
From: John McFarlane (john_at_[hidden])
Date: 2016-10-13 01:00:02

Hi Christopher. I'm actually the main culprit behind P0037. :)

Date: Wed, 12 Oct 2016 18:32:26 +0000 (UTC)
> From: Christopher Kormanyos <e_float_at_[hidden]>
> To: "boost_at_[hidden]" <boost_at_[hidden]>
> Subject: Re: [boost] [fixed_point] First presentation from GSoC 2015
>         and more
> Message-ID: <1026507022.4306136.1476297146580_at_[hidden]>
> Content-Type: text/plain; charset=UTF-8
>
> > I'm a bit surprised I didn't see this work before.
> > Are you aware that SG14, the gamedev, real-time simulations, embedded
> > software and financing study group for the standard
> > is working on fixed point real proposal too?
> > Here is a version of the proposal:>http://johnmcfarlane
> .github.io/fixed_point/papers/p0037r2.html and>http://johnmcfarlane.githu
> b.io/fixed_point/papers/p0381r0.html
> > I will notify SG14 in case they missed your work too.
> Thanks for the information.
> We became aware of your work unfortunately very late inthe project. Much
> of our fixed_point work stems from myearly prototyping dating from 2011 -
> 2013.
> I see a lot of similarities in the two bodies of work.Maybe we could
> identify the strengths of each work.I don't know if it makes sense to
> combine them,but maybe share some concepts or interface ideaswould make
> sense.
>

I discuss P0106R0 (a revision to N3352) in my paper, the latest draft of
which is always available here: https://github.com/
johnmcfarlane/fixed_point/blob/master/doc/p0037.md#p0106
I'm honestly not sure which approach is preferable overall. The set of
features and qualities requested during SG14 and SG6 meetings is large and
conflicting. It includes minimal build times, minimal run-time overhead,
every rounding and overflow strategy listed in P0105, decimal radix and
support for specialized fixed-point instructions on embedded architectures.

>
> In your work I've been experiencing some trouble withthe division routine.

Can you elaborate? Was this recently? I've been trying out numerous
strategies for arithmetic operators. My current preferred approach is to
pad the left-hand operand before performing the division but that's only
been checked in for a few months.

> I also had some problems compilingon VC12 (but you don't target that
> compiler anyway).So that's no big deal.
>

You will need a C++11-compliant compiler as sg14::fixed_point<> creates
literal types. Lack of support for features like constexpr constructors is
the main obstacle to compiling under VC++ 2013 and earlier.

> In your work you are using wrapped versions of elementarytranscendental
> functions designed for built-in float.You might appreciate our hand-crafted
> functionsdesigned to be highly efficient in several digit ranges.
>

Yes! I would be very interested in seeing if I could adapt those function.

Mine are placeholders and I've deliberately postponed the non-trivial task
of adding cmath equivalents. It's come up - maybe a couple of times -
whether these functions are desired and the response has been to just keep
the proposal narrow so they are not included.

There are interesting questions regarding how to implement some functions.
For example, you surely don't always want the same inputs and outputs from
functions involving angles. And hopefully these functions can be constexpr
- unlike existing functions.

Also, how have you approached the trade-off between speed and accuracy? I
went for a very simple sqrt function which is adequate if the value is
calculated at compile time but is likely not desirable at run-time. This
isn't a problem that floating-point variants face.

> I have also benched our fixed_point on bare-metalembedded systems both
> 8-bit and 32-bit with verysatisfying efficiency results. This is a key
> featurefor our embedded users that might also be interestingfor SG14.
>

My current aim is to match integer performance for common arithmetic
operations when using built-ins. This leads to some situations where
overflow is a big problem - but no worse than dealing with raw integers.
I'm curious how you deal with multiplying two int-sized values together
without resorting to wider, slower types.I was under the impression that
P0106 types always widen to fit their values.

>
> Thank you and best regards, Chris
>
> And thank you. Keep up the good work!
John

>
>     On Tuesday, October 11, 2016 11:37 PM, Klaim - Jo?l Lamotte <
> mjklaim_at_[hidden]> wrote:
>
>
>  On 6 October 2016 at 12:07, Paul A. Bristow <pbristow_at_[hidden]>
> wrote:
>
> > > -----Original Message-----
> > > From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of
> > Christopher Kormanyos
> > > Sent: 05 October 2016 23:07
> > > To: boost_at_[hidden]
> > > Subject: Re: [boost] [fixed_point] First presentation from GSoC 2015
> and
> > more
> > >
> > > >> A partial implementation of fixed-point in a Boost-like
> > > >> style based on proposal N3352 is now available.
> > >
> > > > ... But your links don't work,
> >
> > Indeed :-( (
> >
> > The correct link to the docs for some years used to be
> >
> > https://dl.dropboxusercontent.com/u/43940943/modular-boost/
> > libs/fixed_point/doc/html/index.html
> >
> > but sadly this no longer works for reasons that so far escape me (but I
> > suspect some change at Dropbox?).
> >
> > Meanwhile here is a PDF version to whet your appetite until I get a html
> > version publicly available.
> >
> > https://dl.dropboxusercontent.com/u/43940943/modular-boost/
> > libs/fixed_point/doc/fixed_point.pdf
> >
> > Boost.Fixed_point ?
> > ===============
> >
> > A partial implementation of fixed-point in a Boost-like style based on
> > proposal N3352 is now available.
> >
> > This work is the result of developments from 2013-2016, including efforts
> > from GSoC 2015.
> >
> > The source code is available at: https://github.com/
> > BoostGSoC15/fixed_point
> >
> > (The master branch will be stable for a while but the develop branch may
> > be updated in the light of your feedback).
> >
> > Preliminary docs are available at:
> >
> > https://dl.dropboxusercontent.com/u/43940943/modular-boost/
> > libs/fixed_point/index.html
> >
> > We are potentially interested in submitting this work for inclusion in
> > Boost.
> >
> > We are now requesting comments and suggestions for improvements,
> > corrections and any
> > further test results if these become available.
> >
> > Some key library features include:
> >
> > * proper C++ header-only implementation
> > * full numeric_limits and <cmath> functions
> > * flexible template choice of split between resolution and range
> > * automatic selection of underlying integral representation
> > * portability and high efficiency for bare metal microcontrollers
> > * interoperation with Boost.Math
> > * seamless extension to high-precision using Boost.Multiprecision
> > * extensive test suite
> >
> > Thank you for your consideration.
> > Best regards,
> >
> > Christopher Kormanyos
> >
> > And apologies from Paul.
> >
>
>
> Hi,
>
> I'm a bit surprised I didn't see this work before.
> Are you aware that SG14, the gamedev, real-time simulations, embedded
> software and financing study group for the standard
> is working on fixed point real proposal too?
> Here is a version of the proposal:
> http://johnmcfarlane.github.io/fixed_point/papers/p0037r2.html and
> http://johnmcfarlane.github.io/fixed_point/papers/p0381r0.html
> I will notify SG14 in case they missed your work too.
>
> Jo?l Lamotte
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman
> /listinfo.cgi/boost
>
>
>
>