Thanks, Ian. On Mon, 2018-11-26 at 20:46 -0800, Ian Lance Taylor wrote: > 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 -- CRICOS provider code 00123M
-- 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.
