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
In a lot of the code in Catlab we have methods that define parameters as Int rather than Integer. Int will be converted to Int32/Int64 based on whether or not it's on a 32-bit or 64-bit machine. If we change all of these to Integer then it will generalize to integers of any bit size.
Basically on a 64-bit machine if you decide to use Int32 anywhere we won't be able to use any of the Catlab internal functions because there won't be functions defined for Int32
The text was updated successfully, but these errors were encountered:
I take your point, but I'll note that a proper fix involves more than just replacing Int with Integer in method signatures. Our combinatorial data structures (acsets) would need to be generalized with an extra type parameter T<:Integer specializing the integer type and this would need to be propagated through constructors, as well as supplemented with suitable default constructors.
It's certainly possible to do this. Graphs.jl does it, for example. But for me it's not so much a bug fix as a deliberate design decision whether the extra boilerplate is worth it. My guess is that nothing will happen until someone shows up with an HPC use case where it actually matters.
In a lot of the code in Catlab we have methods that define parameters as
Int
rather thanInteger
.Int
will be converted toInt32
/Int64
based on whether or not it's on a 32-bit or 64-bit machine. If we change all of these toInteger
then it will generalize to integers of any bit size.Basically on a 64-bit machine if you decide to use
Int32
anywhere we won't be able to use any of the Catlab internal functions because there won't be functions defined forInt32
The text was updated successfully, but these errors were encountered: