-
Notifications
You must be signed in to change notification settings - Fork 2.3k
Closed
Description
Issue description
When overloading for float parameters, such as:
m.def("bar", [](float const& value) {
std::cout << "float! " << value << std::endl;
});
m.def("bar", [](double const& value) {
std::cout << "double! " << value << std::endl;
});
m.def("bar", [](long double const& value) {
std::cout << "long double! " << value << std::endl;
});the corresponding call from a python builtin.float will always select the least precise floating point type:
from cmake_example import bar
bar(1.23)
# float! 1.23
type(1.23)
# float
bar(1.23e38)
# float! 1.23e+38
type(1.23e38)
# float
bar(1.23e39)
# float! inf
type(1.23e39)
# floatReproducible example code
See above.
Contrary, in Boost.Python always the most precise floating point type was selected:
void bar1( float const& value ) {
std::cout << "float! " << value << std::endl;
}
void bar2( double const& value ) {
std::cout << "double! " << value << std::endl;
}
void bar3( long double const& value ) {
std::cout << "longdouble! " << value << std::endl;
}
// ...
def("bar", bar1);
def("bar", bar2);
def("bar", bar3);# ...
bar(1.23)
# longdouble! 1.23Proposed change
besides that making all three overloads possible for builtin.float but only selecting one is still fine, we should change the priorities of the selected overloads similar to the handling in Boost.Python to the largest/most-precise type.
for explicit control of passing float32/64/128 we should fix the bug reported in #1224
Metadata
Metadata
Assignees
Labels
No labels