You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be better to receive scalar type in the parameters dict not as a C99 typename string, but rather as a numpy type (np.float64) or numpy type name ('float64') -- they are easily convertible to one another, as well as to dtype instances. The latter helps deciding complex mode easier (dtype(name).kind == 'c') as well as looking up default precision.
This representation of scalar type could easily be mapped to a C type name through a predefined dict when it comes to code generation. Alternatively, one could map to C++ type names when needed, e.g., double complex is C99 and does not work in C++, which is problem when the generated code needs to be compiled as C++ because of Eigen, for example.
The numpy type representation is also required when interfacing loopy.
The text was updated successfully, but these errors were encountered:
It would be better to receive scalar type in the parameters dict not as a C99 typename string, but rather as a numpy type (
np.float64
) or numpy type name ('float64'
) -- they are easily convertible to one another, as well as to dtype instances. The latter helps deciding complex mode easier (dtype(name).kind == 'c'
) as well as looking up default precision.This representation of scalar type could easily be mapped to a C type name through a predefined dict when it comes to code generation. Alternatively, one could map to C++ type names when needed, e.g.,
double complex
is C99 and does not work in C++, which is problem when the generated code needs to be compiled as C++ because of Eigen, for example.The numpy type representation is also required when interfacing loopy.
The text was updated successfully, but these errors were encountered: