owlbarn
Improve type safety of operations
One of the remaining weak points of owl, shared by many numerical libraries, is the common (and often annoying to debug) appearance of runtime errors in operations between vectors and matrices.
I can personally relate with @pveber comment here and his suggestion: https://github.com/owlbarn/owl/pull/475#issuecomment-568041927 and I believe we can provide an improved experience at least for low dimensional systems.
It is worth also to keep in mind https://github.com/akabe/slap in this regard, which had found a nice (although probably not scalable) solution to this issue.
I understand that this is currently not a priority but we should keep it in mind.
With regard to slap, I was surprised to find that they used numeric types (z s s s) for uniqueness, but not for conversion between multiple dimensions. (e.g. 4 dim to 3 dim). I wonder if it's too hard to do it in ocaml.
This has been proposed before https://github.com/owlbarn/owl/issues/374
I need to see an exmaple to demonstrate the benefits and how it can be applied to owl and how much it will impact existing APIs.
Yes, I agree. I created this issue as an opportunity for brainstorming and for evaluating/comparing examples. Thanks for pointing out the other issue
Interesting, I didn't know snap. So up till now we have three typing levels:
- none
- order (as in tensor order, that is distinguish between scalar, vector and matrices)
- order + dimension
I experienced the benefits of level 2 recently although it's difficult to describe it concisely. Basically I was having a hard time with several functions I had written, until I introduced this signature. I immediately found a few bugs that I had trouble tracking. I can only imagine that more typing (I mean level 3) would help further, although it comes (like level 2) at a certain price. For level 3, the types are already significantly less readable; I believe level 2 helped to clarify my signatures though.
In any cases, I would not be in favor of changing owl's api but rather, as @ryanrhymes proposed in #374, to propose a tiny library exposing the same operations with more (private) typing.
In any cases, I would not be in favor of changing owl's api but rather, as @ryanrhymes proposed in #374, to propose a tiny library exposing the same operations with more (private) typing.
I fully agree with this, but if we figure out how to build (or generate) a safer shim over owl it would be nice to make it fully compatible with the rest of owl.