s := []string{"Zeno", "John", "Al", "Jenny"}
sort.Sort(sort.Reverse(sort.StringSlice(s)))
I could not understand the logic of Reverse
The source code for Reverse seems as follows:
func Reverse(data Interface) Interface {
return &reverse{data}
}
type reverse struct {
// This embedded Interface permits Reverse to use the methods of
// another Interface implementation.
Interface
}
type Interface interface {
// Len is the number of elements in the collection.
Len() int
// Less reports whether the element with index i
// must sort before the element with index j.
//
// If both Less(i, j) and Less(j, i) are false,
// then the elements at index i and j are considered equal.
// Sort may place equal elements in any order in the final result,
// while Stable preserves the original input order of equal elements.
//
// Less must describe a transitive ordering:
// - if both Less(i, j) and Less(j, k) are true, then Less(i, k) must be true as well.
// - if both Less(i, j) and Less(j, k) are false, then Less(i, k) must be false as well.
//
// Note that floating-point comparison (the < operator on float32 or float64 values)
// is not a transitive ordering when not-a-number (NaN) values are involved.
// See Float64Slice.Less for a correct implementation for floating-point values.
Less(i, j int) bool
// Swap swaps the elements with indexes i and j.
Swap(i, j int)
}
How do those given operations above induce the given array to be reversed?
If you look at the sort.StringSlice type, you can see it implements the Less method, notice the comparison x[i] < x[j], which means smaller element goes first.
func (x StringSlice) Less(i, j int) bool { return x[i] < x[j] }
And then notice the sort.reverse type (not sort.Reverse interface), it also implements the Less method but see how it passes the i and j arguments, receives i and j but passes j and i, which is just equivalent to x[i] > x[j]
// 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)
}
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'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
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
I have just seen an implementation of a priority queue in a generic kind of way in which any
type satisfying an interface can be put into the queue. Is this the way to go with go or does this introduces any issues?
// Copyright 2012 Stefan Nilsson
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
// http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.
// Package prio provides a priority queue.
// The queue can hold elements that implement the two methods of prio.Interface.
package prio
/*
A type that implements prio.Interface can be inserted into a priority queue.
The simplest use case looks like this:
type myInt int
func (x myInt) Less(y prio.Interface) bool { return x < y.(myInt) }
func (x myInt) Index(i int) {}
To use the Remove method you need to keep track of the index of elements
in the heap, e.g. like this:
type myType struct {
value int
index int // index in heap
}
func (x *myType) Less(y prio.Interface) bool { return x.value < y.(*myType).value }
func (x *myType) Index(i int) { x.index = i }
*/
type Interface interface {
// Less returns whether this element should sort before element x.
Less(x Interface) bool
// Index is called by the priority queue when this element is moved to index i.
Index(i int)
}
// Queue represents a priority queue.
// The zero value for Queue is an empty queue ready to use.
type Queue struct {
h []Interface
}
// New returns an initialized priority queue with the given elements.
// A call of the form New(x...) uses the underlying array of x to implement
// the queue and hence might change the elements of x.
// The complexity is O(n), where n = len(x).
func New(x ...Interface) Queue {
q := Queue{x}
heapify(q.h)
return q
}
// Push pushes the element x onto the queue.
// The complexity is O(log(n)) where n = q.Len().
func (q *Queue) Push(x Interface) {
n := len(q.h)
q.h = append(q.h, x)
up(q.h, n) // x.Index(n) is done by up.
}
// Pop removes a minimum element (according to Less) from the queue and returns it.
// The complexity is O(log(n)), where n = q.Len().
func (q *Queue) Pop() Interface {
h := q.h
n := len(h) - 1
x := h[0]
h[0], h[n] = h[n], nil
h = h[:n]
if n > 0 {
down(h, 0) // h[0].Index(0) is done by down.
}
q.h = h
x.Index(-1) // for safety
return x
}
// Peek returns, but does not remove, a minimum element (according to Less) of the queue.
func (q *Queue) Peek() Interface {
return q.h[0]
}
// Remove removes the element at index i from the queue and returns it.
// The complexity is O(log(n)), where n = q.Len().
func (q *Queue) Remove(i int) Interface {
h := q.h
n := len(h) - 1
x := h[i]
h[i], h[n] = h[n], nil
h = h[:n]
if i < n {
down(h, i) // h[i].Index(i) is done by down.
up(h, i)
}
q.h = h
x.Index(-1) // for safety
return x
}
// Len returns the number of elements in the queue.
func (q *Queue) Len() int {
return len(q.h)
}
// Establishes the heap invariant in O(n) time.
func heapify(h []Interface) {
n := len(h)
for i := n - 1; i >= n/2; i-- {
h[i].Index(i)
}
for i := n/2 - 1; i >= 0; i-- { // h[i].Index(i) is done by down.
down(h, i)
}
}
// Moves element at position i towards top of heap to restore invariant.
func up(h []Interface, i int) {
for {
parent := (i - 1) / 2
if i == 0 || h[parent].Less(h[i]) {
h[i].Index(i)
break
}
h[parent], h[i] = h[i], h[parent]
h[i].Index(i)
i = parent
}
}
// Moves element at position i towards bottom of heap to restore invariant.
func down(h []Interface, i int) {
for {
n := len(h)
left := 2*i + 1
if left >= n {
h[i].Index(i)
break
}
j := left
if right := left + 1; right < n && h[right].Less(h[left]) {
j = right
}
if h[i].Less(h[j]) {
h[i].Index(i)
break
}
h[i], h[j] = h[j], h[i]
h[i].Index(i)
i = j
}
}
This package is not the way to go in general, but if you like it and it meets your needs, use it. I don't see any major issues.
The concept of this package compared to container/heap is to put the interface on the node rather than the container. Container/heap allows more flexibility by using your container. (You might have nodes in a container already, and that container might not even be a slice. It just has to be indexable.) On the other hand, it's probably a common case that you don't care about the container and would be happy to let the package manage it for you. The index management of this package is a nice feature over container/heap, although it adds the overhead of a method call even when index management is not needed.
There are always tradeoffs. Container/heap is very general. This package gets by with a smaller method set (2 instead of 5) and adds index management on top, but only by sacrificing a bit of generality and perhaps a bit of performance in some cases. (You'd want to benchmark if you really cared. There are other differences that may dwarf the overhead of the Index call.)
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.