How to Handle <stdfloat> Types Like std::float64_t and std::float16_t in nanobind?

[KowerKoint]

I am developing a library for quantum computing and am using C++23's <stdfloat> types—std::float16_t, std::float32_t, std::float64_t, and std::bfloat16_t—to bind my template functions.

These types evaluate std::floating_point_v as true, which leads nanobind to handle them based on their size, treating them as either double or float (referring to [this section](

nanobind/include/nanobind/nb_cast.h

Line 128 in d7d9d90

if constexpr (std::is_floating_point_v<T>) {

)).

However, std::float64_t (an alias of _Float64) and double have the same structure but are distinct types in GCC, which causes the following error:

/tmp/pip-build-env-dzccmkpm/overlay/local/lib/python3.10/dist-packages/nanobind/include/nanobind/nb_cast.h: In instantiation of ‘bool nanobind::detail::type_caster<T, typename std::enable_if<(is_arithmetic_v<T> && (! is_std_char_v<T>)), int>::type>::from_python(nanobind::handle, uint8_t, nanobind::detail::cleanup_list*) [with T = _Float64; typename std::enable_if<(is_arithmetic_v<T> && (! is_std_char_v<T>)), int>::type = int; uint8_t = unsigned char]’:
  /tmp/pip-build-env-dzccmkpm/overlay/local/lib/python3.10/dist-packages/nanobind/include/nanobind/nb_cast.h:514:32: required from ‘T nanobind::detail::cast_impl(nanobind::handle) [with bool Convert = true; T = _Float64]’
  /tmp/pip-build-env-dzccmkpm/overlay/local/lib/python3.10/dist-packages/nanobind/include/nanobind/nb_cast.h:574:46: required from ‘T nanobind::cast(const detail::api<Derived>&, bool) [with T = _Float64; Derived = handle]’
  /workspaces/scaluq/include/scaluq/circuit/circuit.hpp:115:74: required from ‘void scaluq::internal::bind_circuit_circuit_hpp(nanobind::module_&) [with Fp = _Float64]’
  /workspaces/scaluq/python/binding.cpp:128:43: required from ‘void bind_on_precision(nanobind::module_&, const char*) [with Fp = _Float64]’
  /workspaces/scaluq/python/binding.cpp:145:27: required from here
/tmp/pip-build-env-dzccmkpm/overlay/local/lib/python3.10/dist-packages/nanobind/include/nanobind/nb_cast.h:130:59: error: cannot convert ‘nanobind::detail::type_caster<_Float64, int>::Value*’ {aka ‘_Float64*’} to ‘double*’
  130 | return detail::load_f64(src.ptr(), flags, &value);
      |                                         ^~~~~~
      |                                         |
      |                                         nanobind::detail::type_caster<_Float64, int>::Value* {aka _Float64*}
/tmp/pip-build-env-dzccmkpm/overlay/local/lib/python3.10/dist-packages/nanobind/include/nanobind/nb_lib.h:516:59: note: initializing argument 3 of ‘bool nanobind::detail::load_f64(PyObject*, uint8_t, double*)’
  516 | NB_CORE bool load_f64(PyObject *o, uint8_t flags, double *out) noexcept;
      |                                                   ~~~~~~~~^~~

Even if I were to give up on using std::float64_t and std::float32_t and fallback to double and float, I still have no idea how to properly bind 16-bit floating-point types like std::float16_t.

Does anyone have experience or advice on how to handle this situation effectively?

[wjakob]

Python really just understands doubles, so any other floating point type (including single precision float) must be converted on both directions of a cast. I suggest that you make a PR that generalizes nanobind so that it performs these casts for the new types. You will need to do so in a way that causes nanobind to not depend on C++23 features, since it has a C++17 feature cutoff.

[hpkfft]

As commented above, a Python float is represented using IEEE 754 binary64, i.e., as a C++ double or std::float64_t.
So, I chose to bind using double d and then pass d as an argument to my C++ function (which has a half-precision parameter) by writing foo(static_cast<std::float16_t>(d)).

If you have a NumPy array using dtype=np.float16, then add a specialization for struct dtype_traits as explained in the nanobind docs.
This works today for binding nb::ndarray parameters. So, if you avoid floating-point scalars and only work with arrays, you're set.

I'm interested in this topic, but I don't have time in the short term to work on it.
But I have a question:
If one were to create a PR for nanobind on this topic, would it be acceptable to use #ifdef __STDCPP_FLOAT16_T__ to protect the new code from being seen by C++17 compilers?

[wjakob]

That's a slippery slope. There are lots of containers and other fancy C++23 features that people might want to add with #ifdef-ed sections, and I am not ready to go down that rabbit hole. My main goal is that it's possible to further customize nanobind to tell it about such types (which was limited/broken a while back but is working now).

[KowerKoint]

Thank you for your reply. I’m considering modifying the code, as shown in this commit (
KowerKoint@209910a ),
to use std::numeric_limits in order to strictly identify IEEE binary64 and binary32 and call load accordingly. With this approach, unsupported floating-point types such as _Float16 would result in a compile error, while _Float64 (which is a binary64 type but different from double) would be supported.

I would also like to see _Float128, _Float16, and __gnu_cxx::__bfloat16_t supported for machine learning purposes. However, is it currently your policy not to use #ifdef __STDCPP_FLOAT16_T__ to enable support only on specific environments? In other words, if I really want to use those types, would I have to fork and use my own version?

[hpkfft]

Please try #829

This is intended to support all of double, float, _Float64, _Float32, _Float16, etc.
I think it should work, but I have not had time to test it.
If there's a bug, I will fix it (as time permits this month, or in early January).

[KowerKoint]

I tried your folk on my project and works perfectly! Thank you for your kindness.