Is dense_longlong ever necessary?

[alecjacobson]

My understanding is that we're using numpyeigen to create a generous matrix of template type instantiations to compile. It's questionable if it's worth this dependency (and it's non-standard fork of pybind11) is a worthwhile cost for all those templates: that is, are people really using all these combinations of input types. To answer that bigger question, I think it would be really excellent to gather data. Maybe such surveys of numpy users already exist.

In the meantime, I saw that our "standard" set of types for indexing matrix (e.g., faces F or edges E) is something like :

npe_arg(F, dense_int, dense_long, dense_longlong)

These three correspond to int32, int64 and int128.

Consider int64. The maximum index value would be 9,223,372,036,854,775,807

It is extremely unlikely (IMHO) that we are ever dealing with meshes even remotely near this large. Nor would libigl be a suitable library for doing that as nearly ever algorithm implicitly assumes easy access to memory. It's a stretch even to consider using a mesh with 2,147,483,647 (max value of int32).

So, now, the max value of int128 is 170,141,183,460,469,231,731,687,303,715,884,105,727

This strikes me as absurd. Does int128 show up in a lot of numpy code? I'd like to hear arguments in favor of keeping this type. Removing it would speed up compilation and reduce binary sizes.

[alecjacobson]

If my understanding is correct, all of the class-like-bindings in classes/classes.cpp are only bound to Eigen::MatrixXd and Eigen::MatrixXi. I can't find an issues complaining about not being able to call these or call them efficiently with other types. A couple different explanations:

• few people are using those classes
• the folks using them want more generous bindings but aren't complaining
• the folks using them are satisfied with these bindings

It's observational evidence at best, but maybe a clue.