Hi, I need to use the boost::units::atan2() function in boost/units/cmath.hpp, but am having trouble figuring out how. Do the units have to be dimensionless, or can they be any unit? I have two variables, x_ and y_ which are of a scaled unit type, called light_second_unit. I'm calling it like this: boost::units::atan2(y_, x_); I get this error: ./physics/cartesian_coordinate_system/point.cpp:85: error: no matching function for call to `atan2(boost::units::quantity<boost::units::astronomical::light_second_unit, double>, boost::units::quantity<boost::units::astronomical::light_second_unit, double>)' If it has to be dimensionless, how do I convert them to a dimensionless quantity? Thanks, Brandon -- www.creatorspiritus.com Blog and forum discussing living a Christ-centered life Follow me on Twitter: http://twitter.com/devbanana Follow creatorspiritus.com on Twitter: http://twitter.com/creatorspiritus
AMDG Brandon Olivares wrote:
I need to use the boost::units::atan2() function in boost/units/cmath.hpp, but am having trouble figuring out how. Do the units have to be dimensionless, or can they be any unit?
I have two variables, x_ and y_ which are of a scaled unit type, called light_second_unit. I'm calling it like this:
boost::units::atan2(y_, x_);
I get this error:
./physics/cartesian_coordinate_system/point.cpp:85: error: no matching function for call to `atan2(boost::units::quantity<boost::units::astronomical::light_second_unit, double>, boost::units::quantity<boost::units::astronomical::light_second_unit, double>)'
If it has to be dimensionless, how do I convert them to a dimensionless quantity?
The problem is that the library tries to determine the return type from the system. In this case, the system doesn't include a unit of angle, so the call fails. In Christ, Steven Watanabe
On 2010-01-04, Steven Watanabe wrote:
AMDG
The problem is that the library tries to determine the return type from the system. In this case, the system doesn't include a unit of angle, so the call fails.
Thank you. So how should I use it then when the two variables are lengths, not angles? Brandon
In Christ, Steven Watanabe
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
-- Brandon www.creatorspiritus.com Blog and forum discussing living a Christ-centered life Follow me on Twitter: http://twitter.com/devbanana
AMDG Brandon Olivares wrote:
On 2010-01-04, Steven Watanabe wrote:
The problem is that the library tries to determine the return type from the system. In this case, the system doesn't include a unit of angle, so the call fails.
Thank you. So how should I use it then when the two variables are lengths, not angles?
Something like this should work: typedef boost::units::unit< boost::units::length_dimension, boost::units::make_system< boost::units::angle::radian_base_unit, boost::units::astronomical::light_second_base_unit >::type
light_second_unit;
In Christ, Steven Watanabe
The problem is that the library tries to determine the return type from the system. In this case, the system doesn't include a unit of angle, so the call fails.
Thank you. So how should I use it then when the two variables are lengths, not angles?
Something like this should work:
typedef boost::units::unit< boost::units::length_dimension, boost::units::make_system< boost::units::angle::radian_base_unit, boost::units::astronomical::light_second_base_unit
::type light_second_unit;
Steven, I think we should probably have functions that return angles default to radians if not otherwise specified in the system. To my mind, that is consistent with the principle of least surprise and is consistent with existing library functionality... While the above solution should work and is consistent, it requires more understanding of Boost.Units than should be necessary for simple use of inverse trigonometric functions. Matthias
AMDG Matthias Schabel wrote:
I think we should probably have functions that return angles default to radians if not otherwise specified in the system. To my mind, that is consistent with the principle of least surprise and is consistent with existing library functionality... While the above solution should work and is consistent, it requires more understanding of Boost.Units than should be necessary for simple use of inverse trigonometric functions.
Yeah. That makes sense. In Christ, Steven Watanabe
On 2010-01-04, Steven Watanabe wrote:
AMDG
Matthias Schabel wrote:
I think we should probably have functions that return angles default to radians if not otherwise specified in the system. To my mind, that is consistent with the principle of least surprise and is consistent with existing library functionality... While the above solution should work and is consistent, it requires more understanding of Boost.Units than should be necessary for simple use of inverse trigonometric functions.
Yeah. That makes sense.
I ended up doing something like the following to get it to work. Please let me know if there is a better way. template<class Length> template<class Angle> physics::cylindrical_coordinate_system::point<Length, Angle>& point<Length>::to_cylindrical() const { static physics::cylindrical_coordinate_system::point<Length, Angle> cylindrical( boost::units::sqrt(boost::units::pow<2>(x_) + boost::units::pow<2>(y_)), static_cast<boost::units::quantity<Angle> >( boost::units::atan2( static_cast<boost::units::quantity<boost::units::si::dimensionless> >( y_.value()), static_cast<boost::units::quantity<boost::units::si::dimensionless> >( x_.value()))), z_ ); return cylindrical; } // to_cylindrical I didn't quite understand what you were getting at before. light_second is a measure of length, so I didn't want to include a measure of angle in it. Thanks, Brandon
In Christ, Steven Watanabe
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
-- Brandon www.creatorspiritus.com Blog and forum discussing living a Christ-centered life Follow me on Twitter: http://twitter.com/devbanana
participants (3)
-
Brandon Olivares -
Matthias Schabel -
Steven Watanabe