[fixed_point] First presentation from GSoC 2015 and more
Hello Boost developers, 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: fixed_point-masterPreliminary docs are available at: fixed_point-docWe 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
Hello Boost developers,
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: fixed_point-masterPreliminary docs are available at: fixed_point-docWe 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
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost That sounds awesome, I also startet to work on that but didn't have the time to finish it yet. But your links don't work, I guess you need to
Am 05.10.2016 um 22:22 schrieb Christopher Kormanyos: post them directly into the mail. If I can I'd offer to be the review manager, but I currently only have a small contribution too boost.dll and a library in the review queue. So I guess the community would have to decide if that's alright.
A partial implementation of fixed-point in a Boost-like style based on proposal N3352 is now available.
... But your links don't work, I guess you need to > post them directly into the mail. Thanks. I think the docs link is broken.I will look into correcting this with the co-authors. Best regards, Chris
Hello Boost developers,
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: fixed_point-masterPreliminary docs are available at: fixed_point-docWe 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
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost That sounds awesome, I also startet to work on that but didn't have the time to finish it yet. But your links don't work, I guess you need to
On Wednesday, October 5, 2016 10:39 PM, Klemens Morgenstern <klemens.morgenstern@gmx.net> wrote: Am 05.10.2016 um 22:22 schrieb Christopher Kormanyos: post them directly into the mail. If I can I'd offer to be the review manager, but I currently only have a small contribution too boost.dll and a library in the review queue. So I guess the community would have to decide if that's alright. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Christopher Kormanyos Sent: 05 October 2016 23:07 To: boost@lists.boost.org 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/... 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/... 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/... 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. --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Paul A. Bristow Sent: 06 October 2016 11:08 To: boost@lists.boost.org Subject: Re: [boost] [fixed_point] First presentation from GSoC 2015 and more
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Christopher Kormanyos Sent: 05 October 2016 23:07 To: boost@lists.boost.org 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/...
but sadly this no longer works for reasons that so far escape me (but I suspect some change at Dropbox?).
I have fallen foul of https://www.dropbox.com/help/16 For our advanced users Dropbox Basic (free) users: *****Beginning October 3, 2016*****, you can no longer use shared links to render HTML content in a web browser. If you created a website that directly displays HTML content from your Dropbox, it will no longer render in the browser. The HTML content itself will still remain in your Dropbox and can be shared. I suspect this type of use was causing too much traffic? So I have now added all the generated docs files in /html to https://github.com/BoostGSoC15/fixed_point so you can view the html docs by cloning the whole thing (or copy from Dropbox public link). (I am trying to find a better way of doing this - suggestions welcome).
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/...
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/...
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.
--- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Le 06/10/2016 à 12:07, Paul A. Bristow a écrit :
https://dl.dropboxusercontent.com/u/43940943/modular-boost/libs/fixed_point/...
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/...
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/...
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
Hi, glad to see that you reached to get a review ready fixed point library. There are two fetures that I woudl like the documentation states more clearly: *Q format:** *I understand that you prefer the Q format, instead of the Range/Resolution format as described in n3352. Most of the people is using the Qm.n format in their products. However, I believe the library should name the type more explicitly, either q, q_negatable or q::negatable or fixed_point_q::negatable or something else. In the Qm.n format m is not the range and n is not the resolution as the documentation often use. It is quite close, but it is not the exactly that. For a given Q/m/./n/format, using an/m/+/n/+1 bit signed integer container with/n/fractional bits: * its range is{\displaystyle [-(2^{m}),2^{m}-2^{-n}]}[-(2^{m}),2^{m}-2^{-n}] * its resolution is{\displaystyle 2^{-n}}2^{-n} n3352 negatable<M,N> would be boost::fixed_point::negatable<M+1, -N> and loss the smallest value. *Symmetric range* There is an additional difference. n3352 has symmetric range that merits more attention. negatable<m,n> * its range is [-2^m, 2^m] * its resolution is2^N This has all the problems signed integers have. Negating an integer could result in overflow. I understand that a bit is a bit and in some environments this is the best choice. However, n3352 symmetric signed types are more robust. I will consider to spend an additional bit if I'm ready to use arbitrary precision. *Bounded versus unbounded *n3352 has unbounded arithmetic, while boost::fixed_point has bounded arithmetic. While I understand we could want bounded arithmetic for fixed points types that have a builtin representation, I believe that we want open arithmetic when we use arbitrary precision. *Very small and very large numbers * n3352 allows positive and negative range and resolution. The proposed boost::fixed_point doesn't. I don't know if this limitation of the Qm.n. format, a limitation of the proposed library or if it is by design. Anyway, I believe that very large numbers fixed point numbers are needed as well as very small ones. Thanks for your work, Vicente
We are now requesting comments and suggestions for improvements,>> corrections and any further test results if these become available.
glad to see that you reached to get a review ready fixed point library. Thank you Vicente. We appreciate your comments and experience.
There are two features that I woudl like the documentation states more clearly:
*Q format:** *I understand that you prefer the Q format, instead of the Range/Resolution format as described in n3352. Most of the people is using the Qm.n format in their products. However, I believe the library should name the type more explicitly, either q, q_negatable or q::negatable or fixed_point_q::negatable or something else.
In the Qm.n format m is not the range and n is not the resolution as the documentation often use. It is quite close, but it is not the exactly that.
For a given Q/m/./n/format, using an/m/+/n/+1 bit signed integer container with/n/fractional bits:
* its range is{\displaystyle [-(2^{m}),2^{m}-2^{-n}]}[-(2^{m}),2^{m}-2^{-n}] * its resolution is{\displaystyle 2^{-n}}2^{-n}
I am not sure if I completely understand your point. SoI believe that we need to take a closer look at thisnaming convention. At this time, I would prefer notto change anything, but let's take a closer look andtry to make sure that there are no big mistakesin the docs.
n3352 negatable<M,N> would be boost::fixed_point::negatable<M+1, -N> and loss the smallest value.
*Symmetric range* There is an additional difference. n3352 has symmetric range that merits more attention. negatable<m,n>
* its range is [-2^m, 2^m] * its resolution is2^N
Again, I am not sure if I completely understand this.But I believe that the proposed boost::fixed_point codediffers from n3352 in this area at the moment. One issue I also struggled with is if we should internallyuse the sign bit (as is done now)? Or should we usea dedicated Boolean member variable for sign information?There are trade-offs for either way.
This has all the problems signed integers have. Negating an integer could result in overflow. I understand that a bit is a bit and in some environments this is the best choice. However, n3352 symmetric signed types are more robust. I will consider to spend an additional bit if I'm ready to use arbitrary precision. The cost of multiprecision is quite large. I would really prefernot to require this overhead for 32-bit or 64-bit fixed_points.
*Bounded versus unbounded
*n3352 has unbounded arithmetic, while boost::fixed_point has bounded arithmetic.
While I understand we could want bounded arithmetic for fixed points types that have a builtin representation, I believe that we want open arithmetic when we use arbitrary precision. Do you mean that the range and resolution should bedynamically changed at run-time?
*Very small and very large numbers * n3352 allows positive and negative range and resolution. The proposed boost::fixed_point doesn't. I don't know if this limitation of the Qm.n. format, a limitation of the proposed library or if it is by design.
It is by design choice.
Anyway, I believe that very large numbers fixed point numbers are needed > as well as very small ones. At the moment, the fixed_point negatable class extends tomultiprecision without limitation at compile time, as longas multiprecision backends are enabled. So you can havevery small and very large fixed_point numbers. In fact, some of the examples and tests use just a few bits,while others use many thousands of bits.
Thanks for your work, Vicente Thank you for your comments and insightful suggestions. Best regards, Chris
On Monday, October 10, 2016 9:00 AM, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote: Le 06/10/2016 à 12:07, Paul A. Bristow a écrit :
https://dl.dropboxusercontent.com/u/43940943/modular-boost/libs/fixed_point/...
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/...
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/...
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
Hi, glad to see that you reached to get a review ready fixed point library. There are two fetures that I woudl like the documentation states more clearly: *Q format:** *I understand that you prefer the Q format, instead of the Range/Resolution format as described in n3352. Most of the people is using the Qm.n format in their products. However, I believe the library should name the type more explicitly, either q, q_negatable or q::negatable or fixed_point_q::negatable or something else. In the Qm.n format m is not the range and n is not the resolution as the documentation often use. It is quite close, but it is not the exactly that. For a given Q/m/./n/format, using an/m/+/n/+1 bit signed integer container with/n/fractional bits: * its range is{\displaystyle [-(2^{m}),2^{m}-2^{-n}]}[-(2^{m}),2^{m}-2^{-n}] * its resolution is{\displaystyle 2^{-n}}2^{-n} n3352 negatable<M,N> would be boost::fixed_point::negatable<M+1, -N> and loss the smallest value. *Symmetric range* There is an additional difference. n3352 has symmetric range that merits more attention. negatable<m,n> * its range is [-2^m, 2^m] * its resolution is2^N This has all the problems signed integers have. Negating an integer could result in overflow. I understand that a bit is a bit and in some environments this is the best choice. However, n3352 symmetric signed types are more robust. I will consider to spend an additional bit if I'm ready to use arbitrary precision. *Bounded versus unbounded *n3352 has unbounded arithmetic, while boost::fixed_point has bounded arithmetic. While I understand we could want bounded arithmetic for fixed points types that have a builtin representation, I believe that we want open arithmetic when we use arbitrary precision. *Very small and very large numbers * n3352 allows positive and negative range and resolution. The proposed boost::fixed_point doesn't. I don't know if this limitation of the Qm.n. format, a limitation of the proposed library or if it is by design. Anyway, I believe that very large numbers fixed point numbers are needed as well as very small ones. Thanks for your work, Vicente _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Le 11/10/2016 à 22:17, Christopher Kormanyos a écrit : >>> We are now requesting comments and suggestions for improvements,>> corrections and any further test results if these become available. >> glad to see that you reached to get a review ready fixed point library. > Thank you Vicente. We appreciate your comments and experience. > >> There are two features that I woudl like the documentation states more >> clearly: >> *Q format:** >> *I understand that you prefer the Q format, instead of the >> Range/Resolution format as described in n3352. Most of the people is >> using the Qm.n format in their products. However, I believe the library >> should name the type more explicitly, either q, q_negatable or >> q::negatable or fixed_point_q::negatable or something else. >> In the Qm.n format m is not the range and n is not the resolution as the >> documentation often use. It is quite close, but it is not the exactly that. >> For a given Q/m/./n/format, using an/m/+/n/+1 bit signed integer >> container with/n/fractional bits: Sorry for the format: For a given Qm.n format, using an (m+n+1) bit signed integer container with n fractional bits: >> * its range is{\displaystyle >> [-(2^{m}),2^{m}-2^{-n}]}[-(2^{m}),2^{m}-2^{-n}] >> * its resolution is{\displaystyle 2^{-n}}2^{-n} * its range is [-(2^m), 2^m-2^(-n)] * its resolution is 2^(-n) > I am not sure if I completely understand your point. SoI believe that we need to take a closer look at thisnaming convention. At this time, I would prefer notto change anything, but let's take a closer look andtry to make sure that there are no big mistakesin the docs. The problem is using the same name that have different meaning than the referenced proposal. > >> n3352 negatable<M,N> would be boost::fixed_point::negatable<M+1, -N> and >> loss the smallest value. >> *Symmetric range* >> There is an additional difference. n3352 has symmetric range that merits >> more attention. negatable<m,n> >> * its range is [-2^m, 2^m] >> * its resolution is2^N > Again, I am not sure if I completely understand this.But I believe that the proposed boost::fixed_point codediffers from n3352 in this area at the moment. here it is where I don't agree. > One issue I also struggled with is if we should internallyuse the sign bit (as is done now)? Or should we usea dedicated Boolean member variable for sign information?There are trade-offs for either way. I believe that the use the sign bit is the correct way, yes. > >> This has all the problems signed integers have. Negating an integer >> could result in overflow. I understand that a bit is a bit and in some >> environments this is the best choice. However, n3352 symmetric signed >> types are more robust. I will consider to spend an additional bit if I'm >> ready to use arbitrary precision. > The cost of multiprecision is quite large. I would really prefernot to require this overhead for 32-bit or 64-bit fixed_points. What I mean is that when boost::fixed_point is using Boost.MultiPrecission as representation type, there is no reason to don't be symetric. When the representation is a 32-bit, n3352 lost a value (the smalles one) to be able to be symetric. [-128,127] versus [-127,127] > >> *Bounded versus unbounded >> *n3352 has unbounded arithmetic, while boost::fixed_point has bounded >> arithmetic. >> While I understand we could want bounded arithmetic for fixed points >> types that have a builtin representation, I believe that we want open >> arithmetic when we use arbitrary precision. > Do you mean that the range and resolution should bedynamically changed at run-time? No at all. I mean that the range and resolution of the result of an operation depend on the operands and the operation it self (of course). IIUC the addition results in a fixed point with the same representation and the better resolution. This results already in overflow. While I can understand that this is the way to work on some domains when the representations must be a fixed builtin integral type, it is less clear the advantage when we use a multiprecision representation. When I use arbitrary I mean that the class is able to represent any number of bits. The result of a+b can have more bits. In p0106r0/ N3352 <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3352.html> operation result range result resolution a+b max($a,$b)+1 min(@a,@b) > >> *Very small and very large numbers >> * n3352 allows positive and negative range and resolution. The proposed >> boost::fixed_point doesn't. >> I don't know if this limitation of the Qm.n. format, a limitation of the >> proposed library or if it is by design. > It is by design choice. With p0106r0 I can represent numbers in the range [-1/32, 1/32] in steps of 1/128 and also number in the range [-1024*1024*1024, 1024*1024*1024] in steps of 32*1024. This is due because p0106r0 allows negative and positive powers of 2 for the range and resolution. Your Boost.FixedPoint doesn't allow to work with these numbers IIUC. > >> Anyway, I believe that very large numbers fixed point numbers are needed > as well as very small ones. > At the moment, the fixed_point negatable class extends tomultiprecision without limitation at compile time, as longas multiprecision backends are enabled. So you can havevery small and very large fixed_point numbers. > In fact, some of the examples and tests use just a few bits,while others use many thousands of bits. See above for what I consider very small and very big. > >> Thanks for your work, >> Vicente > Thank you for your comments and insightful suggestions. > Best regards, Chris > Hoping I've clarified a little bit my concerns, about the symmetry, the closed and open arithmetic and the positive and negative powers of two. Best, Vicente > > On Monday, October 10, 2016 9:00 AM, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote: > > > Le 06/10/2016 à 12:07, Paul A. Bristow a écrit : >> 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 >> >> > Hi, > > glad to see that you reached to get a review ready fixed point library. > > > There are two fetures that I woudl like the documentation states more > clearly: > > *Q format:** > *I understand that you prefer the Q format, instead of the > Range/Resolution format as described in n3352. Most of the people is > using the Qm.n format in their products. However, I believe the library > should name the type more explicitly, either q, q_negatable or > q::negatable or fixed_point_q::negatable or something else. > > In the Qm.n format m is not the range and n is not the resolution as the > documentation often use. It is quite close, but it is not the exactly that. > > For a given Q/m/./n/format, using an/m/+/n/+1 bit signed integer > container with/n/fractional bits: > > * its range is{\displaystyle > [-(2^{m}),2^{m}-2^{-n}]}[-(2^{m}),2^{m}-2^{-n}] > * its resolution is{\displaystyle 2^{-n}}2^{-n} > > > n3352 negatable<M,N> would be boost::fixed_point::negatable<M+1, -N> and > loss the smallest value. > > *Symmetric range* > There is an additional difference. n3352 has symmetric range that merits > more attention. negatable<m,n> > > * its range is [-2^m, 2^m] > * its resolution is2^N > > > This has all the problems signed integers have. Negating an integer > could result in overflow. I understand that a bit is a bit and in some > environments this is the best choice. However, n3352 symmetric signed > types are more robust. I will consider to spend an additional bit if I'm > ready to use arbitrary precision. > > *Bounded versus unbounded > > *n3352 has unbounded arithmetic, while boost::fixed_point has bounded > arithmetic. > > While I understand we could want bounded arithmetic for fixed points > types that have a builtin representation, I believe that we want open > arithmetic when we use arbitrary precision. > > *Very small and very large numbers > * > n3352 allows positive and negative range and resolution. The proposed > boost::fixed_point doesn't. > I don't know if this limitation of the Qm.n. format, a limitation of the > proposed library or if it is by design. > Anyway, I believe that very large numbers fixed point numbers are needed > as well as very small ones. > > Thanks for your work, > Vicente > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > > > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 6 October 2016 at 12:07, Paul A. Bristow <pbristow@hetp.u-net.com> wrote:
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Christopher Kormanyos Sent: 05 October 2016 23:07 To: boost@lists.boost.org 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
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Klaim - Joël Lamotte Sent: 11 October 2016 22:38 To: Boost Developers List 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. <big snip>
I'm a bit surprised I didn't see this work before.
This is it's first 'public' outing.
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
We have referenced the first paper (see References section - or search the pdf for the authors name or p number), but the second was too recent for my update process ;-) There are a lot of similarities, but handling overflow etc efficiently without C/C++ access to the machine's carry bit looks difficult to me.
I will notify SG14 in case they missed your work too.
Thank you. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
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. 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.
In your work I've been experiencing some trouble withthe division routine. I also had some problems compilingon VC12 (but you don't target that compiler anyway).So that's no big deal. 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. 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. Thank you and best regards, Chris On Tuesday, October 11, 2016 11:37 PM, Klaim - Joël Lamotte <mjklaim@gmail.com> wrote: On 6 October 2016 at 12:07, Paul A. Bristow <pbristow@hetp.u-net.com> wrote:
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Christopher Kormanyos Sent: 05 October 2016 23:07 To: boost@lists.boost.org 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
Am 06.10.2016 um 00:07 schrieb Christopher Kormanyos:
A partial implementation of fixed-point in a Boost-like style based on proposal N3352 is now available.
... But your links don't work, I guess you need to > post them directly into the mail. Thanks. I think the docs link is broken.I will look into correcting this with the co-authors. Best regards, Chris
I looked over the pdf Paul Bristow shared, and it looks awesome, though I'd think you'll also need the unsigned variant. I searched for an easy solution for the notation for signed/unsigned and what you can do is use a plain `signed` or `unsigned` as a template parameter, which yields `signed int` and `unsigned int`. That does allow syntax like this: `fixed_point<42, -6, unsigned>(42)` which is quite neat I think. Maybe I missed that, but shift operators would be neat. I.e. "static" shift operators, that is: fp<7, 5> x = 1.0; auto shifted = x >> c<1>; //type = fp<7,4>, but the underlying value is the same. Another thing I worked on, was a literal operator, using the `template<char...> operator"` overload. So you could automatically determine the needed fixed-point type: auto x = 5.25_fp; //yields fp<6,2> I'd have to look how good my code was there, but if you´re interested I could work on that, to integrate it into your library.
A partial implementation of fixed-point in a Boost-like style based on proposal N3352 is now available.
... But your links don't work, I guess you need to > post them directly into the mail.
Thanks. I think the docs link is broken.I will look into correcting this with the co-authors.>> Best regards, Chris
I looked over the pdf Paul Bristow shared, and it looks awesome, though I'd think you'll also need the unsigned variant. I searched for an easy solution for the notation for signed/unsigned and what you can do is use a plain `signed` or `unsigned` as a template parameter, which yields `signed int` and `unsigned int`. That does allow syntax like this: `fixed_point<42, -6, unsigned>(42)` which is quite neat I think. Thank you. The original proposal specifies the types negatable,nonnegative, cardinal and another one I forgot. I agree thatthe unsigned type would be nice to have. So that one iscalled nonnegative. I haven't figured out how nonnegativeshould interact with math functions and/or with negatable. Maybe I missed that, but shift operators would be neat. I.e. "static" > shift operators, that is: fp<7, 5> x = 1.0; auto shifted = x >> c<1>; //type = fp<7,4>, but the underlying value is the same. Shift operators are not present at the moment.We can look into this.
Another thing I worked on, was a literal operator, using the `template<char...> operator"` overload. So you could automatically determine the needed fixed-point type: auto x = 5.25_fp; //yields fp<6,2>
I'd have to look how good my code was there, but if you´re interested I could work on that, to integrate it into your library. Thank you for the input. Let's wait for some more commentsand see if this is something we should support. Best regards, Chris.
On Thursday, October 6, 2016 3:16 PM, Klemens Morgenstern <klemens.morgenstern@gmx.net> wrote: Am 06.10.2016 um 00:07 schrieb Christopher Kormanyos:
A partial implementation of fixed-point in a Boost-like style based on proposal N3352 is now available.
... But your links don't work, I guess you need to > post them directly into the mail. Thanks. I think the docs link is broken.I will look into correcting this with the co-authors. Best regards, Chris
I looked over the pdf Paul Bristow shared, and it looks awesome, though I'd think you'll also need the unsigned variant. I searched for an easy solution for the notation for signed/unsigned and what you can do is use a plain `signed` or `unsigned` as a template parameter, which yields `signed int` and `unsigned int`. That does allow syntax like this: `fixed_point<42, -6, unsigned>(42)` which is quite neat I think. Maybe I missed that, but shift operators would be neat. I.e. "static" shift operators, that is: fp<7, 5> x = 1.0; auto shifted = x >> c<1>; //type = fp<7,4>, but the underlying value is the same. Another thing I worked on, was a literal operator, using the `template<char...> operator"` overload. So you could automatically determine the needed fixed-point type: auto x = 5.25_fp; //yields fp<6,2> I'd have to look how good my code was there, but if you´re interested I could work on that, to integrate it into your library. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 10/5/2016 4:22 PM, Christopher Kormanyos wrote:
Hello Boost developers,
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: fixed_point-masterPreliminary docs are available at: fixed_point-docWe 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
The correct link is evidently https://github.com/BoostGSoC15/fixed_point.
On 10/5/2016 3:22 PM, Christopher Kormanyos wrote:
Hello Boost developers,
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: fixed_point-masterPreliminary docs are available at: fixed_point-docWe 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
I looked over some of the cmath routines but I think several could be optimized. Specifically I noticed at abs, ceil, fmod, and sqrt. Here's some of my old fixed-point cmath routines. http://codepad.org/CqvPx5u0
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. I looked over some of the cmath routines but I think> several could be optimized.
Specifically I noticed at abs, ceil, fmod, and sqrt.
Here's some of my old fixed-point cmath routines. Thanks. Those implementations of ceil, floor, fmodare cool. I can see how those ideas fit into our work. I would like to further investigate your sqrt implementation.Of all the <cmath> functions we implemented, sqrt is oneof the less efficient ones. Thanks again for the ideas. Best regards, Chris
On Saturday, October 15, 2016 6:33 PM, Michael Marcin <mike.marcin@gmail.com> wrote: On 10/5/2016 3:22 PM, Christopher Kormanyos wrote:
Hello Boost developers,
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: fixed_point-masterPreliminary docs are available at: fixed_point-docWe 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
I looked over some of the cmath routines but I think several could be optimized. Specifically I noticed at abs, ceil, fmod, and sqrt. Here's some of my old fixed-point cmath routines. http://codepad.org/CqvPx5u0 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 10/15/2016 4:02 PM, Christopher Kormanyos wrote:
I would like to further investigate your sqrt implementation.
It seems the link to the whitepaper for sqrt has broken over the years. I swear archive.org is the only thing keeping us from another dark age. I found it again here: http://www.realitypixels.com/turk/computergraphics/FixedSqrt.pdf along side another relevant article: http://www.realitypixels.com/turk/computergraphics/FixedPointTrigonometry.pd...
I would like to further investigate your sqrt implementation.
It seems the link to the whitepaper for sqrt has broken over the years. I swear archive.org is the only thing keeping us from another dark age.
I found it again here: OK. Thank you. I will try to bench the iterative sqrt algorithm for,let's say, 32-bit signed fixed-point on a 32-bit microcontroller.If I get any sensible results compared with our polynomialapproximation, I will forward them to the thread. One disadvantage of polynomial approximation is digit lossdue to argument reduction. Iterative and CORDIC seem tonot suffer from this, and cam be good options. Thanks for the suggestions.
Best regards, Chris On Sunday, October 16, 2016 8:06 AM, Michael Marcin <mike.marcin@gmail.com> wrote: On 10/15/2016 4:02 PM, Christopher Kormanyos wrote:
I would like to further investigate your sqrt implementation.
It seems the link to the whitepaper for sqrt has broken over the years. I swear archive.org is the only thing keeping us from another dark age. I found it again here: http://www.realitypixels.com/turk/computergraphics/FixedSqrt.pdf along side another relevant article: http://www.realitypixels.com/turk/computergraphics/FixedPointTrigonometry.pd... _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 10/16/2016 12:52 PM, Christopher Kormanyos wrote:
I would like to further investigate your sqrt implementation.
It seems the link to the whitepaper for sqrt has broken over the years. I swear archive.org is the only thing keeping us from another dark age.
I found it again here: OK. Thank you. I will try to bench the iterative sqrt algorithm for,let's say, 32-bit signed fixed-point on a 32-bit microcontroller.If I get any sensible results compared with our polynomialapproximation, I will forward them to the thread. One disadvantage of polynomial approximation is digit lossdue to argument reduction. Iterative and CORDIC seem tonot suffer from this, and cam be good options. Thanks for the suggestions.
Two things of note: I'm pretty sure that sqrt is missing a bit of code to handle an odd number of fractional bits (I never used any types that had these but is probably important for a fully generic lib). I'm pretty sure there is a low hanging fruit optimization opportunity to use CLZ to skip a bunch of iterations before starting the loop.
I would like to further investigate your sqrt implementation.
It seems the link to the whitepaper for sqrt has broken over the years.
I found it again here:>> http://www.realitypixels.com/turk/computergraphics/FixedSqrt.pdf OK. Thank you. I will try to bench the iterative sqrt algorithm for,> let's say, 32-bit signed fixed-point on a 32-bit microcontroller.> If I get any sensible results compared with our polynomial> approximation, I will forward them to the thread. I have benchmarked the iterative shift-and-add sqrt functioncompared with the polynomial approximation used inthe proposed Boost.Fixed_point. The benchmark usedbare-metal embedded microcontrollers.
I used a 32-bit microcontroller at 24MHz and also an 8-bitmicrocontroller at 16MHz. I used an argument of 6/10 forthe sqrt function. The fixed_point type used was:boost::fixed_point::negatable<7, -24>. Timing measurementshave been done with a digital ascilloscope. GCC 5.2 and 5.3have been used. On 32-bit microcontroller: * polynomial approx : 6 micro-sec, sqrt(6/10) = 0.7745966 * Shift-and-add :15 micro-sec, sqrt(6/10) = 0.7745967 On 8-bit microcontroller: * polynomial approx. : 180us* Shift-and-add : 450us Here, the unit [us] means microseconds. The benchmark code is available at develop branch here: https://github.com/BoostGSoC15/fixed_point/blob/develop/example/fixed_point_... Best regards, Chris. On Sunday, October 16, 2016 9:20 PM, Michael Marcin <mike.marcin@gmail.com> wrote: On 10/16/2016 12:52 PM, Christopher Kormanyos wrote:
I would like to further investigate your sqrt implementation.
It seems the link to the whitepaper for sqrt has broken over the years. I swear archive.org is the only thing keeping us from another dark age.
I found it again here: OK. Thank you. I will try to bench the iterative sqrt algorithm for,let's say, 32-bit signed fixed-point on a 32-bit microcontroller.If I get any sensible results compared with our polynomialapproximation, I will forward them to the thread. One disadvantage of polynomial approximation is digit lossdue to argument reduction. Iterative and CORDIC seem tonot suffer from this, and cam be good options. Thanks for the suggestions.
Two things of note: I'm pretty sure that sqrt is missing a bit of code to handle an odd number of fractional bits (I never used any types that had these but is probably important for a fully generic lib). I'm pretty sure there is a low hanging fruit optimization opportunity to use CLZ to skip a bunch of iterations before starting the loop. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 10/20/2016 3:56 PM, Christopher Kormanyos wrote:
I would like to further investigate your sqrt implementation.
It seems the link to the whitepaper for sqrt has broken over the years.
I found it again here:>> http://www.realitypixels.com/turk/computergraphics/FixedSqrt.pdf OK. Thank you. I will try to bench the iterative sqrt algorithm for,> let's say, 32-bit signed fixed-point on a 32-bit microcontroller.> If I get any sensible results compared with our polynomial> approximation, I will forward them to the thread. I have benchmarked the iterative shift-and-add sqrt functioncompared with the polynomial approximation used inthe proposed Boost.Fixed_point. The benchmark usedbare-metal embedded microcontrollers.
I used a 32-bit microcontroller at 24MHz and also an 8-bitmicrocontroller at 16MHz. I used an argument of 6/10 forthe sqrt function. The fixed_point type used was:boost::fixed_point::negatable<7, -24>. Timing measurementshave been done with a digital ascilloscope. GCC 5.2 and 5.3have been used.
On 32-bit microcontroller: * polynomial approx : 6 micro-sec, sqrt(6/10) = 0.7745966 * Shift-and-add :15 micro-sec, sqrt(6/10) = 0.7745967 On 8-bit microcontroller: * polynomial approx. : 180us* Shift-and-add : 450us Here, the unit [us] means microseconds.
The benchmark code is available at develop branch here: https://github.com/BoostGSoC15/fixed_point/blob/develop/example/fixed_point_... Best regards, Chris.
I was able to reproduce your results on win64 using vs2015. I was able to trick the compiler and double the speed of the iterative method but was unable to approach the poly approx in performance. results at the top of this link (requires google benchmark) http://codepad.org/CF84VtYS Thanks for running the tests.
I have benchmarked the iterative shift-and-add sqrt>> functioncompared with the polynomial approximation>> used in the proposed Boost.Fixed_point. The benchmark>> used bare-metal embedded microcontrollers. I was able to reproduce your results on win64 using vs2015. I was able to trick the compiler and double the speed of the iterative method but was unable to approach the poly approx in performance.
results at the top of this link (requires google benchmark)> http://codepad.org/CF84VtYS
Thanks for running the tests. Nice work! Thanks for the refinements. I think we havea couple of good options for sqrt now. The shift-and-addmight be effective in certain digit ranges such as betweenlong double and 128-bit. I think it is always a good idea to have a few options foralgorithms.
Best regards, Chris On Friday, October 21, 2016 6:06 AM, Michael Marcin <mike.marcin@gmail.com> wrote: On 10/20/2016 3:56 PM, Christopher Kormanyos wrote:
I would like to further investigate your sqrt implementation.
It seems the link to the whitepaper for sqrt has broken over the years.
I found it again here:>> http://www.realitypixels.com/turk/computergraphics/FixedSqrt.pdf OK. Thank you. I will try to bench the iterative sqrt algorithm for,> let's say, 32-bit signed fixed-point on a 32-bit microcontroller.> If I get any sensible results compared with our polynomial> approximation, I will forward them to the thread. I have benchmarked the iterative shift-and-add sqrt functioncompared with the polynomial approximation used inthe proposed Boost.Fixed_point. The benchmark usedbare-metal embedded microcontrollers.
I used a 32-bit microcontroller at 24MHz and also an 8-bitmicrocontroller at 16MHz. I used an argument of 6/10 forthe sqrt function. The fixed_point type used was:boost::fixed_point::negatable<7, -24>. Timing measurementshave been done with a digital ascilloscope. GCC 5.2 and 5.3have been used.
On 32-bit microcontroller: * polynomial approx : 6 micro-sec, sqrt(6/10) = 0.7745966 * Shift-and-add :15 micro-sec, sqrt(6/10) = 0.7745967 On 8-bit microcontroller: * polynomial approx. : 180us* Shift-and-add : 450us Here, the unit [us] means microseconds.
The benchmark code is available at develop branch here: https://github.com/BoostGSoC15/fixed_point/blob/develop/example/fixed_point_... Best regards, Chris.
I was able to reproduce your results on win64 using vs2015. I was able to trick the compiler and double the speed of the iterative method but was unable to approach the poly approx in performance. results at the top of this link (requires google benchmark) http://codepad.org/CF84VtYS Thanks for running the tests. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (7)
-
Christopher Kormanyos
-
Edward Diener
-
Klaim - Joël Lamotte
-
Klemens Morgenstern
-
Michael Marcin
-
Paul A. Bristow
-
Vicente J. Botet Escriba