Would support on more numpy integer types be a good idea?

Is your feature request related to a problem? Please describe. When playing with librosa especially with other audo libraries and numpy functions, I always meet erros from time to time by type errors where for example, n_bins requires int (as reflected by isinstance() in source code), but other integer types are not acceptable, for example np.int64. Would it be a good idea to support more integer types instead of asking users to transfer a numpy integer to a “pythonic” integer? I know it is a small thing but it can avoid some unexpected behaviors and additional bothering for users if done properly.

Describe the solution you’d like I can implement it and do tests if @bmcfee you think it’s a good idea.

[underdogliu]

@bmcfee yeah for np.integer I do found reference after replying.

@dpwe sorry for being ruthless due to lacking knowledge on that and thanks for your suggestion. I think your solution would work.

“I’d like to see some examples of where our current implementation is problematic though.” -> an example can be as simple as lpcs = librosa.lpc(frame, int(lp_order)), where I have to add int() to transfer data type from np.int64 to int, in order to make it work.

[bmcfee]

where I have to add int() to transfer data type from np.int64 to int, in order to make it work.

Indeed, that case is an exception to what I wrote earlier about our use of int types, and I agree that here we should relax it. That said, if you’re doing LPC with order ~ 2^63, you may be in for a bad time 😆