On Mon, Nov 26, 2018 at 5:14 PM Dan Kortschak <dan.kortsc...@adelaide.edu.au> wrote: > > Background: > > As part of the Gonum dev team, I have an interest in using Go for > scientific computing. This stems from long experience with unsafe > computing environments often used in, particularly, bioinformatics > (perl, python and R being standouts in the field, with packages that > often use dubious design and implementation practices that allow silent > failures giving plausible but incorrect results rather than following > than following the rule of repair. In Gonum packages we (perhaps non- > idiomatically in the context of the broader Go ecosystem) insist on > failing noisily when we can rather than allowing silent progression to > an incorrect result; we use panics instead of errors a fair bit because > they cannot be implicitly ignored. > > Question: > > One of the areas where we do this is in the mat package for matrix > arithmetic and linear algebra. We use panics in lieue of a compile-time > type check for appropriate input matrix shape (e.g. the check needed to > ensure [mxw] <- [mxn] x [nxw] is a valid operation). I don't see any > way to encode this kind of information into a contract as it stands in > the current contracts draft. I'm not entirely sure that any kind of > reasonably simple contract system *would* allow this. If we assume that > there is some type parameterised function that operates on say [n][m]T > to perform a matrix mult, can anyone see a way of encoding the required > constraint?
There is no way to express that constraint. In general contracts are only intended to express things that can be described in the type system. What you are asking for--a relationship between the lengths of different slice types--can not be described in the type system. This of it this way: the purpose of a contract is to decide when it is OK to instantiate a generic function with a given type. When making that decision at compile time, we don't know the length of a slice. So we can't use the length of a slice when deciding whether to instantiate a generic function. (That said, one could imagine extending contracts to permit them to describe non-type arguments, and then one could use an integer argument to set the size of an array, and then one could write a contract describing the relationship between arrays. Of course the caller would have to pass arrays rather than slices, which would not work well with sub-matrixes.) Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
