Skip to content

Float Overloads Specialize to Least Precision #1512

@ax3l

Description

@ax3l

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)
# float

Reproducible 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.23

Proposed 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

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions