Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

units: Improve precision of angle conversion #18

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from
Open

units: Improve precision of angle conversion #18

wants to merge 1 commit into from

Conversation

ghost
Copy link

@ghost ghost commented Jun 22, 2015

Use high precision constants from boost/math/constants/constants.hpp
to fix trac#6893.

Use high precision constants from boost/math/constants/constants.hpp
to fix trac#6893.
@mkurdej
Copy link
Member

mkurdej commented Jun 23, 2015

Looks good to me, but I don't know what's the policy about dependencies on other Boost libraries. Anyone?
Personally, I find it ok, as I would probably use math constants together with units anyway, so there will be no overhead actually.

@jhunold
Copy link
Contributor

jhunold commented Jun 24, 2015

We already depend on Boost.Math, see units/cmath.hpp for the functions used there. But I'd like to have a unit test for this. My main concern is the question of hardcoding double precision instead of using whatever precision the user wants.

@ghost
Copy link
Author

ghost commented Jun 24, 2015

@jhunold But the double is hardcoded here:
https://github.com/boostorg/units/blob/master/include/boost/units/conversion.hpp#L167
Unless I'm mistaken, the user doesn't have a choice here.

I opened https://svn.boost.org/trac/boost/ticket/11389 about this issue.

@jhunold
Copy link
Contributor

jhunold commented Jun 25, 2015

@rleigh-dundee the original double is okay as it is a POD and is subject to the usual decaying rules for PODs. Using a double as a template parameter triggers template instantiation rules which opens up a different can of worms . So the hardcoding of double is not a separate issue, but a part of the original issue #6893. Those are the reasons I want an unit test case which shows that different constants are used for different underlying floating types and makes sure that this stays so.

@hernando
Copy link

hernando commented Apr 11, 2023

Is #44 a valid solution? The current constants do not have acceptable precision when using double.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants