Support for NumPy-style data types

[Mandrenkov]

Context:
Python bindings for templated C++ classes require a unique class name for each template specialization. This introduces some boilerplate code on the C++ side and increases the verbosity of code on the Python side.

Description of the Change:

• The name parameter passed to Python binding generators is now derived with the help of a Type structure.
• Python bindings of templated C++ classes now include a static dtype attribute.
• Factory methods which accept a dtype parameter are now available in the jet Python package.
• Class parametrizations in Python unit tests have been replaced with dtype parametrizations.

Benefits:

• The C++ code used to generate the Python bindings is cleaner.
• The classes generated from Python bindings can be instantiated using a convention that mirrors NumPy.

Possible Drawbacks:

• The tensor template parameter of classes with Python bindings is restricted to instances of the Tensor class.
  • This may be problematic when it comes time to generate Python bindings for CUDA tensor specializations.

Related GitHub Issues:
None.

[github-actions]

Test Report (C++) on Ubuntu

    1 files  ±0      1 suites  ±0   0s ⏱️ ±0s
239 tests ±0  239 ✔️ ±0  0 💤 ±0  0 ❌ ±0 
519 runs  ±0  519 ✔️ ±0  0 💤 ±0  0 ❌ ±0 

Results for commit ea17dd5. ± Comparison against base commit ea17dd5.

♻️ This comment has been updated with latest results.

[github-actions]

Test Report (C++) on MacOS

    1 files  ±0      1 suites  ±0   0s ⏱️ ±0s
239 tests ±0  239 ✔️ ±0  0 💤 ±0  0 ❌ ±0 
519 runs  ±0  519 ✔️ ±0  0 💤 ±0  0 ❌ ±0 

Results for commit ea17dd5. ± Comparison against base commit ea17dd5.

♻️ This comment has been updated with latest results.

[mlxd]

Looks great. Just a quick q or 2.

[mlxd]

Looks good, though just a thought on mixing real and complex data types: given everything is a complex datatype on the backend, we could potentially speed-up BLAS ops for real * real, and real * complex contractions (and save memory too) by extending BLAS supports for the above types. Granted, I think this can be done later as needed.

[Mandrenkov]

given everything is a complex datatype on the backend

Do you mean currently? Or will this always be the case?

we could potentially speed-up BLAS ops for real * real, and real * complex contractions (and save memory too) by extending BLAS supports for the above types.

I'm not sure about real * complex, but would adding bindings for cblas_dgemv, cblas_dgemm, and cblas_ddotu_sub be enough (so that you can instantiate a Tensor<double>)? Or are you talking about something else?