converting std::type_info* into something human-readable? (or how to interoperate with std::type info generally?)

[kratsg]

I've been struggling with a library where I rely on nb::ndarray<> and have access to dlpack::dtype as well as std::type_info.

Right now I've been returning the std::type_info::name as a string for the function that returns, but this name is a rather not-user-friendly such as a and h and so on... is there a way to at least convert the std::type_info to dlpack::dtype where possible so I can at least return (for a subset of the scenarios) the nbits and signed portion instead which is easier to understand? Or even being able to return the np.dtype equivalent would be great on some level.

I saw (likely internal) functions such as detail::nb_type_lookup which returns a corresponding PyObject * but that's not seemingly exposed for us to use.

    nb::class_<col::ColumnInfo>(module, "ColumnInfo")
        .def(nb::init<>())
        .def_ro("name", &col::ColumnInfo::name)
        .def_ro("index", &col::ColumnInfo::index)
        .def_prop_ro("type", [](const col::ColumnInfo &self){
            return self.type->name(); // a better way to return even a dict like {"signed": true/false, "nbits": 8, ...} or np.uint8?
        });

[wjakob]

You can use nb::dtype<T> to look up the dtype of an arithmetic type, whose members you can access to determine bith depth, integer/floating point type, etc. Then there is nb::type<T> to look up the Python object associated with a C++ type. std::type_info is a C++ data structure that is unrelated to nanobind.

Based on what you say, the easiest think would be if ColumnInfo had a type alias of the underlying arithmetic representation, and then you could return a dict of the type you want by examining the members of auto result = nb:dtype<typename ColumnInfo::ValueType>();

[kratsg]

I sort of think I get what you're saying here. However, ColumnInfo has zero-dependency on nanobind (outside of my scope) so I need a way to use the std::type_into RTTI and map that to the nb::type<T> or nb::dtype<T> in some way or form. For example, I've done this for right now as a temporary solution:

// this function converts us from type_info to a human-readable name
std::string get_type_name(const std::type_info& type_info) {
    if (type_info == typeid(int)) {
        return "int32";
    } else if (type_info == typeid(unsigned int)) {
        return "uint32";
    } else if (type_info == typeid(short)) {
        return "int16";
    } else if (type_info == typeid(unsigned short)) {
        return "uint16";
    } else if (type_info == typeid(char)) {
        return "char";
    } else if (type_info == typeid(unsigned char)) {
        return "uint8";
    } else if (type_info == typeid(float)) {
        return "float32";
    } else if (type_info == typeid(double)) {
        return "float64";
    } else if (type_info == typeid(long)) {
        return "int64";
    } else if (type_info == typeid(unsigned long)) {
        return "uint64";
    } else if (type_info == typeid(bool)) {
        return "bool";
    } else {
        // If the type is unknown, you can return the mangled name or a default message
        return std::string("unknown ('") + type_info.name() + "')";
    }
}

note that at the moment, I already have had to provide a mapping in the other direction from dlpack::dtype to type_info to work with this Column object

void setColumnVoid(col::PythonToolHandle &self, const std::string& key, nb::ndarray<> column, bool is_const = true) {
  // TODO: figure out how to get type_info from handle instead...
  // nb::handle handle = column.handle();

  const std::type_info* type_info = nullptr;
  const nb::dlpack::dtype dtype = column.dtype();

  switch ((nb::dlpack::dtype_code) dtype.code) {
     case nb::dlpack::dtype_code::Int:
         switch (dtype.bits) {
             // escape hatch to handle char for now
             // we should rely on signed/unsigned and nbits, instead of std::type_info
             // case 8: type_info = &typeid(std::int8_t); break;
             case 8: type_info = &typeid(char); break;
             case 16: type_info = &typeid(std::int16_t); break;
             case 32: type_info = &typeid(std::int32_t); break;
 /// ... lots more
     default:
         break;
  }

  if (type_info == nullptr) throw std::runtime_error ("unsupported column type passed in");
  self.setColumnVoid(key, column.shape(0), column.data(), *type_info, is_const);
}

so I'm not fully sure if there's a better solution to be had. I totally get that the std::type_info and dlpack::dtype are separate things, but they do have commonalities for the numeric types at least that there is usually a one-to-one mapping for a subset of the valid std::type_info cases.

[wjakob]

Why can you not construct the nb::dtype object only in your bindings. For example by binding a lambda function member of "ColumnInfo" that doesn't correspond to an actual function.

[kratsg]

Can we return nb::dtype object straight out to Python? If you're referring to my get_type_name() -- I would happily do that if that's the case. If I misunderstand, would you mind sketching out what you're thinking it should look like?

[wjakob]

You would have to inspect the elements of nb::dtype in the lambda function I mentioned. But this could be done with some runtime computation that will make your code a lot more compact than the typeid(...) == checks in your example. That's the best I can offer.

[kratsg]

Based on what you say, the easiest think would be if ColumnInfo had a type alias of the underlying arithmetic representation, and then you could return a dict of the type you want by examining the members of auto result = nb:dtype<typename ColumnInfo::ValueType>();

This part is what I'm a bit stuck on. I know we can't do something like

namespace col {
    struct ColumnInfo {
        using ValueType = int8_t; // Example: Replace with actual underlying type.
   ...
  }
}

or anything similar to store a type - so we'd have to use typeid or similar. So I'm still unsure what you mean... There has to be a bidirectional hashmap somewhere, no?