> 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 probably there are other variations that don't require
reimplementing sorting.
On Tuesday, December 6, 2022 at 7:47:04 PM UTC-8 Andrew Harris wrote:
> 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 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 larger
>> index number should be at the front, shouldn't the sort function simply do
>> that, since during the sorting, the passed index number should be stable?
>> On Wednesday, December 7, 2022 at 11:14:37 AM UTC+8 harr...@spu.edu
>> wrote:
>>
>>> 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
>>> <https://github.com/golang/go/issues/47988> for a `slices.Reverse`
>>> function in golang.org/x/exp/slices - I'm not sure what the status or
>>> reasoning is on this. FWIW it's not the only approach that might make sense
>>> for traversing a slice in reverse order, and it can be naive when working
>>> with e.g. bytes holding utf8.
>>>
>>> I think this works but I haven't really thought about edge cases...
>>>
>>> `reverse(&s)`
>>>
>>> func reverse[T any](s *[]T) {
>>> z := len(*s)
>>> for a := 0; a < len(*s)/2; a++ {
>>> (*s)[a], (*s)[z-a-1] = (*s)[z-a-1], (*s)[a]
>>> }
>>> }
>>>
>>> On Tuesday, December 6, 2022 at 6:54:38 PM UTC-8 hey...@gmail.com wrote:
>>>
>>>> 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/slices? That also seems to only compare
>>>> values.
>>>>
>>>>
>>>> On Wednesday, December 7, 2022 at 10:45:33 AM UTC+8 harr...@spu.edu
>>>> wrote:
>>>>
>>>>> 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, 100)
>>>>>> for i := 1; i <= 20; i++ {
>>>>>> s = append(s, i)
>>>>>> }
>>>>>> sort.Slice(s, func(i, j int) bool { return i > j })
>>>>>> log.Print(s)
>>>>>>
>>>>>> I expect it to print numbers in reverse order, since items with
>>>>>> larger index numbers should be at the front. However, at lease in
>>>>>> go1.19.3,
>>>>>> it prints
>>>>>>
>>>>>> [9 1 8 5 16 3 20 2 10 7 12 13 14 15 6 4 19 18 17 11]
>>>>>>
>>>>>> I guess I must have misunderstood how the sort package works, but
>>>>>> rereading sort's doc multiple time doesn't help answer the question.
>>>>>>
>>>>>> Could anyone shed some light?
>>>>>>
>>>>>
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/fc580aef-809d-4315-8726-ce2f1bde823bn%40googlegroups.com.
