Re: [go-nuts] Re: Why this simple sorting code doesn't work?

On Tue, Dec 6, 2022 at 10:29 PM hey...@gmail.com wrote: > > sorts defined by an ordering function purely dependent on the value of > the element > > Hmm, I thought the function was agnostic to what really get compared? If > it offers two index numbers, and the return value says the one with large

[go-nuts] Re: Why this simple sorting code doesn't work?

Reversing and then using the stable sort sounds like an elegant solution. Thanks! @Robert I totally missed the indexes could refer to swapped items. I somehow had the impression that go would memorize the returned order and swap them in one go. This explains it. Thanks a lot. On Wednesday, D

[go-nuts] Re: Why this simple sorting code doesn't work?

> In my real code I have other criteria to compare the slice items, but if they tie, I want to use the reverse of their original order. Oh, forgot to say: FWIW - I think reversing and then sort.SliceStable might be a solution - asymptotically reverse should be less complex than the sort, or pro

[go-nuts] Re: Why this simple sorting code doesn't work?

Just as an intuitive argument, we could do: sort.Slice(s, func(i, j int) bool { log.Println(i, j); return i > j }) The appearances of i and j per step recapitulate the logic of the sorting algo in some weak sense; not slice order On Tuesday, December 6, 2022 at 7:28:39 PM UTC-8 hey...@gmail.com w

Re: [go-nuts] Re: Why this simple sorting code doesn't work?

If you compare indexes then the elements are swapped you have messed up the order. Imagine the first comparison is 0,15 - you have now swapped those elements - there is no guarantee what order the elements are compared in. The index passed in is simply to look up the element. I am supposed th

[go-nuts] Re: Why this simple sorting code doesn't work?

> sorts defined by an ordering function purely dependent on the value of the element Hmm, I thought the function was agnostic to what really get compared? If it offers two index numbers, and the return value says the one with larger index number should be at the front, shouldn't the sort functi

Re: [go-nuts] Re: Why this simple sorting code doesn't work?

I do want to compare indexes. Is that something possible to do? In my real code I have other criteria to compare the slice items, but if they tie, I want to use the reverse of their original order. I expect `return i > j` to put items with larger index numbers at the front, why that doesn't see

[go-nuts] Re: Why this simple sorting code doesn't work?

Oh, to reverse by index ... I think this doesn't quite fit in the idea of sorts defined by an ordering function purely dependent on the value of the element. I think there may have been a feature request for a `slices.Reverse` function in golang.org/

Re: [go-nuts] Re: Why this simple sorting code doesn't work?

sort.Slice(s, func(i, j int) bool { return i > j }) You are comparing the indexes and not the values -Eric http://www.google.com/profiles/eric.hubbard On Tue, Dec 6, 2022 at 6:45 PM Andrew Harris wrote: > Subtly: > return s[i] > s[j] > > Is the right sort func > > I think it'd be recomme

[go-nuts] Re: Why this simple sorting code doesn't work?

Thanks for the quick reply. But that seems to compare values. I'd like to compare index numbers. The fact that original values follow index number order is a coincidence. > I think it'd be recommended to look at the generics slices package, which also has a sort Do you mean golang.org/x/exp/sl

[go-nuts] Re: Why this simple sorting code doesn't work?

Subtly: return s[i] > s[j] Is the right sort func I think it'd be recommended to look at the generics slices package, which also has a sort On Tuesday, December 6, 2022 at 6:39:29 PM UTC-8 hey...@gmail.com wrote: > Hi, > > I have this very simple sorting code: > > s := make([]int, 0, 10