I'm looking at the sort.Reverse code:
type reverse struct {
// This embedded Interface permits Reverse to use the methods of
// another Interface implementation.
Interface
}
// Less returns the opposite of the embedded implementation's Less method.
func (r reverse) Less(i, j int) bool {
return r.Interface.Less(j, i)
}
// Reverse returns the reverse order for data.
func Reverse(data Interface) Interface {
return &reverse{data}
}
As far as I understand reverse implements Interface (and overrides Less) and *reverse does not implement Interface. Why does Reverse return *reverse (which somehow is Interface)?
For your comment:
As far as I understand reverse implements Interface (and overrides
Less)
There is no method overriding in Golang. It is not overriding Less. It is implementing Less of Interface which is an interface type:
type Interface interface {
// Len is the number of elements in the collection.
Len() int
// Less reports whether the element with
// index i should sort before the element with index j.
Less(i, j int) bool
// Swap swaps the elements with indexes i and j.
Swap(i, j int)
}
For the question asked:
Why does Reverse return *reverse (which somehow is Interface)
Because to change the order of the data it should be an address of the reverse struct. That's why it is *reverse. Now you can pass any type implementing Interface interface. And for implementing the Interface you should implement all the methods defined inside Interface.
type IntSlice []int
func (p IntSlice) Len() int { return len(p) }
func (p IntSlice) Less(i, j int) bool { return p[i] < p[j] }
func (p IntSlice) Swap(i, j int) { p[i], p[j] = p[j], p[i] }
In above case you can see that IntSlice implements the Interface. Hence you can pass the Intslice as an argument to Reverse.
As an example you can also implement using Float values as:
package main
import (
"fmt"
"sort"
)
func main() {
//s := []int{5, 2, 6, 3, 1, 4} // unsorted
s1 := []float64{5.2, 2.6, .6, .03, 2.1 } // unsorted
sort.Sort(sort.Reverse(sort.Float64Slice(s1)))
fmt.Println(s1)
}
Playground example
Related
I have defined a message in proto file:
my.proto
--------
message Holiday {
string title = 1;
google.protobuf.Timestamp date = 2;
}
After compiling, it creates my.pb.go
Now in my go code, I have an slice of Holiday.
main.go
-------
holidays := []my.Holiday{...}
I have to sort this slice by Holiday.date. As per the doc if I want to sort using sort.Sort then I have to implement Len, Swap & Less method. But I cannot define these receiver method in my go code because Holiday is coming from the different package (my.pb.go).
Is there any way to sort this?
Thanks,
You could just use sort.Slice, which doesn't require implementing sort.Interface.
Slice sorts the slice x given the provided less function. It panics if x is not a slice.
sort.Slice(holidays, func(i, j int) bool {
return holidays[i].GetDate().Before(holidays[j].GetDate())
})
The SortKeys example in the sort.Sort documentation shows how to accomplish this by using an ad-hoc struct:
// A Planet defines the properties of a solar system object.
type Planet struct {
name string
mass earthMass
distance au
}
// By is the type of a "less" function that defines the ordering of its Planet arguments.
type By func(p1, p2 *Planet) bool
// Sort is a method on the function type, By, that sorts the argument slice according to the function.
func (by By) Sort(planets []Planet) {
ps := &planetSorter{
planets: planets,
by: by, // The Sort method's receiver is the function (closure) that defines the sort order.
}
sort.Sort(ps)
}
// planetSorter joins a By function and a slice of Planets to be sorted.
type planetSorter struct {
planets []Planet
by func(p1, p2 *Planet) bool // Closure used in the Less method.
}
// Len is part of sort.Interface.
func (s *planetSorter) Len() int {
return len(s.planets)
}
// Swap is part of sort.Interface.
func (s *planetSorter) Swap(i, j int) {
s.planets[i], s.planets[j] = s.planets[j], s.planets[i]
}
// Less is part of sort.Interface. It is implemented by calling the "by" closure in the sorter.
func (s *planetSorter) Less(i, j int) bool {
return s.by(&s.planets[i], &s.planets[j])
}
Given that sort.Sort only takes a sort.Interface, it doesn't care about what data structure you are using or what type you are actually swapping.
The sort package documentation shows two examples that answer the question.
The first package example declares a slice type with the required methods:
type Person struct {
Name string
Age int
}
type ByAge []Person
func (a ByAge) Len() int { return len(a) }
func (a ByAge) Swap(i, j int) { a[i], a[j] = a[j], a[i] }
func (a ByAge) Less(i, j int) bool { return a[i].Age < a[j].Age }
...
sort.Sort(ByAge(people))
Notice that the Len, Swap and Less methods are on the slice type defined for sorting, not on the struct type. You can define that type in your own package.
The sort.Slice example shows how to sort with a less function only:
sort.Slice(people, func(i, j int) bool { return people[i].Name < people[j].Name })
In this example, there's no need to define types for the purpose of soring.
I've been trying to use the Heap package in Go and I am not sure on how to initialize it.
package main
import "container/heap"
type PriorityMessage struct {
Priority int
Message string
}
func priorityQueue() {
//WOULD THIS not initialize the heap?
h := heap.Init(h PriorityMessage)
}
I've been trying to find examples online of how other's initialized their heaps and all of them seem to create their own versions of the Go heap package everytime. Would calling the heap.Init(h Interface) function from the heap package not work?
There is the heap.Interface what you should implement first.
type Interface interface {
sort.Interface
Push(x interface{}) // add x as element Len()
Pop() interface{} // remove and return element Len() - 1.
}
This means you should have the necessary methods for your PriorityMessage struct. After you pass the instance of the struct into the heap.Init(&pm).
You can find details in the godoc as linked in the comments.
Just to clarify the confusion. Go is a strongly typed language with lack of generics. So the heap package designed on the way that it's type independent. You can create your own implementation for all of the types what you want to implement. Any type implements the heap.Interface can be used by the heap package.
//https://cs.opensource.google/go/go/+/refs/tags/go1.16.6:src/container/heap/example_intheap_test.go
// This example demonstrates an integer heap built using the heap interface.
//package heap_test
import (
"container/heap"
"fmt"
)
// An IntHeap is a min-heap of ints.
type IntHeap []int
func (h IntHeap) Len() int { return len(h) }
func (h IntHeap) Less(i, j int) bool { return h[i] < h[j] }
func (h IntHeap) Swap(i, j int) { h[i], h[j] = h[j], h[i] }
func (h *IntHeap) Push(x interface{}) {
// Push and Pop use pointer receivers because they modify the slice's length,
// not just its contents.
*h = append(*h, x.(int))
}
func (h *IntHeap) Pop() interface{} {
old := *h
n := len(old)
x := old[n-1]
*h = old[0 : n-1]
return x
}
// This example inserts several ints into an IntHeap, checks the minimum,
// and removes them in order of priority.
func Example_intHeap() {
h := &IntHeap{2, 1, 5}
heap.Init(h)
heap.Push(h, 3)
fmt.Printf("minimum: %d\n", (*h)[0])
for h.Len() > 0 {
fmt.Printf("%d ", heap.Pop(h))
}
// Output:
// minimum: 1
// 1 2 3 5
}
I have an imported type
type ExternalType struct {
quantity int
}
type ExternalArray []*ExternalType
I want to be able to implement the sort interface for ExternalArray for so that I sort it by quantity.
However, I am not sure how I could do that?
A concrete example is this:
https://play.golang.org/p/bEPtJ8NHQK
The sort.Interface defines three methods which must be implemented:
// Len is the number of elements in the collection.
Len() int
// Less reports whether the element with
// index i should sort before the element with index j.
Less(i, j int) bool
// Swap swaps the elements with indexes i and j.
Swap(i, j int)
In this context this would look something like:
type ExternalType struct {
quantity int
}
type ExternalArray []*ExternalType
func (ea ExternalArray) Len() int {
return len(ea)
}
func (ea ExternalArray) Less(i, j int) bool {
return ea[i].quantity < ea[j].quantity
}
func (ea ExternalArray) Swap(i, j int) {
ea[i], ea[j] = ea[j], ea[i]
}
In order to do the sort you can then use sort.Sort, for example:
arr := ExternalArray{
&ExternalType{quantity: 33},
&ExternalType{quantity: 44},
&ExternalType{quantity: 22},
&ExternalType{quantity: 11},
}
sort.Sort(arr)
// `arr` is now sorted :-)
Here is a working example in the playground.
Define a type in the current package that sorts a slice with the same element type as the imported type:
type byQuantity []*pkg.ExternalType
func (a byQuantity) Len() int { return len(a) }
func (a byQuantity) Swap(i, j int) { a[i], a[j] = a[j], a[i] }
func (a byQuantity) Less(i, j int) bool { return a[i].Quantity < a[j].Quantity }
Convert the imported slice type value to the type defined above and sort:
a := pkg.ExternalArray{{1}, {3}, {2}}
sort.Sort(byQuantity(a))
// a is now sorted by quantity
Because the original slice and the converted slice share the same backing array, sort on the converted slice also sorts the original slice.
playground example
There is one problem bothering me in Golang.
Say I have 2 structs:
type Dog struct {
Name string
Breed string
Age int
}
type Cat struct {
Name string
FavoriteFood string
Age int
}
And when I try to sort []*Dog and []*Cat by Age, I have to define 2 different sort struct like:
type SortCat []*Cat
func (c SortCat) Len() int {//..}
func (c SortCat) Swap(i, j int) {//..}
func (c SortCat) Less(i, j int) bool {//..}
type SortDog []*Dog
func (c SortDog) Len() int {//..}
func (c SortDog) Swap(i, j int) {//..}
func (c SortDog) Less(i, j int) bool {//..}
A natural thought is to implement some SortableByAge interface and create a Less function using the interface function. Like:
type SortableByAge interface {
AgeValue() int
}
And then:
type SortAnimal []SortableByAge
func (c SortDog) Less(i, j int) bool {
return c[i].AgeValue() < c[j].AgeValue()
}
However, according to:
http://golang.org/doc/faq#convert_slice_of_interface
dogs := make([]*Dogs, 0 , 1)
//add dogs here
sort.Sort(SortAnimal(dogs))
Above is not possible.
So I wonder what is the best practice for this case and
Is there any other technique that can reduce the need for implementing the sort.Interface for similar structs again and again that I have missed?
EDIT:
I realized that my examples are terrible :(
In real life case, these 2 structs are very different, the only thing in common between them is that I wish to sort them by a common numeric value.
A better example would be:
type Laptop {//...}
type Pizza {//...}
And the only thing these 2 structs share in common is that I wish to sort a slice(agh... should not have used Pizza in example) of them by price.
So, combining them to a common struct is not really working for a lot of cases.
But will look into go generate.
This Specific Case
In this specific case you shouldn't use 2 different types as they are identical, just use a common Animal type:
type Animal struct {
Name string
Age int
}
func (a Animal) String() string { return fmt.Sprintf("%s(%d)", a.Name, a.Age) }
type SortAnim []*Animal
func (c SortAnim) Len() int { return len(c) }
func (c SortAnim) Swap(i, j int) { c[i], c[j] = c[j], c[i] }
func (c SortAnim) Less(i, j int) bool { return c[i].Age < c[j].Age }
func main() {
dogs := []*Animal{&Animal{"Max", 4}, &Animal{"Buddy", 3}}
cats := []*Animal{&Animal{"Bella", 4}, &Animal{"Kitty", 3}}
fmt.Println(dogs)
sort.Sort(SortAnim(dogs))
fmt.Println(dogs)
fmt.Println(cats)
sort.Sort(SortAnim(cats))
fmt.Println(cats)
}
Output (Go Playground):
[Max(4) Buddy(3)]
[Buddy(3) Max(4)]
[Bella(4) Kitty(3)]
[Kitty(3) Bella(4)]
General Case
In general you can only use a common sorting implementation if you're willing to give up concrete types and use interface types instead.
Create the interface type you want your slice to hold:
type Animal interface {
Name() string
Age() int
}
You can have a common implementation of this:
type animal struct {
name string
age int
}
func (a *animal) Name() string { return a.name }
func (a *animal) Age() int { return a.age }
func (a animal) String() string { return fmt.Sprintf("%s(%d)", a.name, a.age) }
Your specific animal types:
type Dog struct {
animal // Embed animal (its methods and fields)
}
type Cat struct {
animal // Embed animal (its methods and fields)
}
You implement sort.Interface on SortAnim:
type SortAnim []Animal
func (c SortAnim) Len() int { return len(c) }
func (c SortAnim) Swap(i, j int) { c[i], c[j] = c[j], c[i] }
func (c SortAnim) Less(i, j int) bool { return c[i].Age() < c[j].Age() }
Using it:
dogs := SortAnim{&Dog{animal{"Max", 4}}, &Dog{animal{"Buddy", 3}}}
cats := SortAnim{&Cat{animal{"Bella", 4}}, &Cat{animal{"Kitty", 3}}}
fmt.Println(dogs)
sort.Sort(SortAnim(dogs))
fmt.Println(dogs)
fmt.Println(cats)
sort.Sort(SortAnim(cats))
fmt.Println(cats)
Output (Go Playground):
[Max(4) Buddy(3)]
[Buddy(3) Max(4)]
[Bella(4) Kitty(3)]
[Kitty(3) Bella(4)]
Note: as illustrated in commit ad26bb5, in Go 1.8 (Q1 2017), you won't have to implement Len() and Swap() and Less() since issue 16721 was resolved. Only Less() is needed, the rest is done by reflection.
The problem was:
Vast majority of sort.Interface uses a slice
Have to define a new top level type
Len and Swap methods are always the same
Want to make common case simpler with least hit to performance
See the new sort.go:
// Slice sorts the provided slice given the provided less function.
//
// The sort is not guaranteed to be stable. For a stable sort, use
// SliceStable.
//
// The function panics if the provided interface is not a slice.
func Slice(slice interface{}, less func(i, j int) bool) {
rv := reflect.ValueOf(slice)
swap := reflect.Swapper(slice)
length := rv.Len()
quickSort_func(lessSwap{less, swap}, 0, length, maxDepth(length))
}
So as long as you have a Less() function comparing two instances respecting an interface, you can sort any number of struct respecting said common interface.
Go 1.18 generics will add another option, as illustrated in nwillc/genfuncs/container/sort.go.
// Sort sorts a slice by the LessThan order.
func (s GSlice[T]) Sort(lessThan genfuncs.BiFunction[T, T, bool]) {
n := len(s)
s.quickSort(0, n, maxDepth(n), lessThan)
}
With BiFunction:
// BiFunction accepts two arguments and produces a result.
type BiFunction[T, U, R any] func(T, U) R
This is just an example illustrating how a generic sort could be implemented: it is not an official one (since generics are, at the ime of writing, Q1 2022, still very new).
The best practice for this case would be to define
type Animal struct{
Species,Name string
Age int
}
as suggested by twotwotwo. If cat and dog are similar enough to be sorted in the same way, they are also similar enough to be the same struct. If they are different in some way, then you should reimplement the interface for each type.
An alternative could be to copy all pointers from your []*Cat slice into a []SortableByAge slice of the same size. If you are going to sort the slice, that will take O(n*log(n)) so an extra O(n) shouldn't be a performance issue.
A third alternative, in the rare event that you have many types that for some reason have to be distinct but still have very simple sorting functions, you can look at autogenerating them with go generate.
If I have an array/slice of structs in Go and want to sort them using the sort package it seems to me that I need to implement the whole sort interface which contains 3 methods:
Len
Swap
Less
It seems that Len and Swap should always have the same implementation no matter the type of struct is in the array.
Is there a way to avoid having the implement Len and Swap every time or is this just a limitation from the lack of Generics in Go?
If you are implementing several different comparison operations on the same slice type, you can use embedding to avoid redefining Len and Swap each time. You can also use this technique to add parameters to the sort, for example to sort in reverse or not depending on some run-time value.
e.g.
package main
import (
"sort"
)
type T struct {
Foo int
Bar int
}
// TVector is our basic vector type.
type TVector []T
func (v TVector) Len() int {
return len(v)
}
func (v TVector) Swap(i, j int) {
v[i], v[j] = v[j], v[i]
}
// default comparison.
func (v TVector) Less(i, j int) bool {
return v[i].Foo < v[j].Foo
}
// TVectorBarOrdered embeds TVector and overrides
// its Less method so that it is ordered by the Bar field.
type TVectorBarOrdered struct {
TVector
}
func (v TVectorBarOrdered) Less(i, j int) bool {
return v.TVector[i].Bar < v.TVector[j].Bar
}
// TVectorArbitraryOrdered sorts in normal or reversed
// order depending on the order of its Reversed field.
type TVectorArbitraryOrdered struct {
Reversed bool
TVector
}
func (v TVectorArbitraryOrdered) Less(i, j int) bool {
if v.Reversed {
i, j = j, i
}
return v.TVector[i].Foo < v.TVector[j].Foo
}
func main() {
v := []T{{1, 3}, {0, 6}, {3, 2}, {8, 7}}
sort.Sort(TVector(v))
sort.Sort(TVectorBarOrdered{v})
sort.Sort(TVectorArbitraryOrdered{true, v})
}
Your own answer is right. In your case of an array or slice the implementations of Len() and Swap() are simple. Like len() Go could provide a native swap() here. But the interface which is used now can also be used for more complex data structures like BTrees. It still allows the Sort() function to work (like my parallel quicksort, which uses the same sort interface).
If you want to sort slices (for which Len and Swap always have the same implementation), the sort package now has a function that only requires an implementation of Less:
func Slice(slice interface{}, less func(i, j int) bool)
Although this is an old question, I'd like to point out
the github.com/bradfitz/slice
package.
But as an example or proof of concept only, I would not recommend this actually be used (it's documented with the word "gross"):
It uses gross, low-level operations to make it easy to sort arbitrary slices with only a less function, without defining a new type with Len and Swap operations.
In actual code, I find it completely trivial, quick, short, readable, and non-distracting to just do something like:
type points []point
func (p []points) Len() int { return len(p) }
func (p []points) Swap(i, j int) { p[i], p[j] = p[j], p[i] }
func (p []points) Less(i, j int) bool {
// custom, often multi-line, comparison code here
}
Here gofmt insists on a blank line between the type and func lines
but it has no problem with
multiple one-line functions with no blank lines
and it nicely lines up the function bodies.
I find this a nice readable compact form for such things.
As for your comment that:
It seems that Len and Swap should always have the same implementation no matter the type of struct is in the [slice]
just the other week I need a sort that kept pairs of elements in a slice together (for input to strings.NewReplacer) that required a trivial variation like:
type pairByLen []string
func (p pairByLen) Len() int { return len(p) / 2 }
func (p pairByLen) Less(i, j int) bool { return len(p[i*2]) > len(p[j*2]) }
func (p pairByLen) Swap(i, j int) {
p[i*2], p[j*2] = p[j*2], p[i*2]
p[i*2+1], p[j*2+1] = p[j*2+1], p[i*2+1]
}
This is not supported by an interface like the one in github.com/bradfitz/slice.
Again, I find this layout easy, compact, and readable.
Although (perhaps more so in this case), others may disagree.