Gary, On Tue, Oct 23, 2018 at 10:49 AM <gary.willoug...@victoriaplumb.com> wrote:
> In that example, how would you call the `New` function? > like this: - https://github.com/sbinet/go2-test/blob/master/ndarray/nd_test.go func TestArray1D(t *testing.T) { shape := []int{10} arr0 := ndarray.New(float64)(shape, []float64{0, 1, 2, 3, 4, 5, 6, 7, 8, 9}) arr1 := ndarray.New(shape, []float64{0, 1, 2, 3, 4, 5, 6, 7, 8, 9}) } func TestArray2D(t *testing.T) { shape := []int{2, 5} arr0 := ndarray.New(float64)(shape, []float64{0, 1, 2, 3, 4, 5, 6, 7, 8, 9}) arr1 := ndarray.New(shape, []float64{0, 1, 2, 3, 4, 5, 6, 7, 8, 9}) } hth, -s > On Monday, 22 October 2018 10:10:51 UTC+1, Sebastien Binet wrote: >> >> Hi Volker, >> >> On Mon, Oct 22, 2018 at 10:57 AM Volker Dobler <dr.volke...@gmail.com> >> wrote: >> >>> The Go 2 draft generics draft has been discussed a lot, >>> especially contracts have drawn a lot of attention and >>> other ways to limit the set of possible type were suggested. >>> >>> Most discussions orbited around very basic polymorphic >>> functions like polymorphic Min or a Map functions. I do consider >>> a polymorphic Min function to be nothing more than a >>> litmus test to generics: If a generic/polymorphic Min cannot >>> be written the proposal is insufficient. But I probably would >>> never write a polymorphic Min as a type specific Min is >>> 3 lines and basically impossible to get wrong and just because >>> Min looks nice under a proposal does not mean that the >>> proposed solution will lead to good code where generic or >>> polymorphic code would actually be beneficial: For complicated >>> data structures and algorithms. >>> >>> At least the original proposal mentions a generic Graph >>> data structure. Still without showing how e.g. DFS, BFS, >>> Shortest Paths would be a) implemented and b) used. >>> >>> I think it would be good if we could see how different proposals >>> (and especially the official one) would affect how generic code >>> is written and used. Especially code which is hard to get right >>> and really benefits from a "generic" implementation. >>> >>> I'd like to see generic/polymorphic: >>> - Image manipulation (scaling, convolution, etc.) for various color >>> models >>> - Balanced trees (AVL or Red-Black) >>> - Matrices of bool, int, float32/64, complex with inversion, >>> LR-decomposition, eigenvalues >>> - Fast Fourier Transformation (with ints, float32/64, complex64/128 and >>> my float24 inputs) >>> - Graph algorithms (DFS, BFS, Dijkstra, Bellman-Ford, Floyd-Warshall) >>> (feel free to add stuff from your field here). >>> >>> How would a package graph with a generic Graph data structure >>> and accompanying algorithms look like? How would I use such >>> a generic algorithm with nodes of my own type? >>> >>> How would I be using a generic 2d FFT package when my inputs >>> is complex128 and how if inputs are float32? >>> >>> I think that answers to these questions would be much more >>> helpful in evaluating generics than the current focus on the >>> syntax of Min and whether contracts can be done trough interfaces. >>> >>> Let's start with Dijkstra and the Graph example of the >>> original proposal: How would the implementation look like >>> and how would my code use this implementation? >>> >> >> I agree. >> I had started something like this, there: >> - https://github.com/sbinet/go2-test/blob/master/ndarray/nd.go >> (my pet peeve is inter-operability with Python's protocol buffers and >> NumPy n-dim arrays in particular) >> >> it would be great to have a code generator that takes e.g. Go-generics >> draft-proposal code, and generates Go-1 compatible code (or, at the very >> least a gofmt command that can make sure the code parses ok.) >> >> -s >> > -- > 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. > -- 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.
