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 this works
at all. For example, compare 1,20 - swap - then compare 1,20 again - the sort
would expect the inverse Boolean value to be returned - and it won’t be - so
your comparison function is not valid/stable.
You can’t use a sort like this to do what you want.
> On Dec 6, 2022, at 9:28 PM, hey...@gmail.com <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 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/5fb85879-b356-4d6d-9645-778d3e7c549an%40googlegroups.com.
--
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/3CCE315C-01EE-4146-B793-E818B6277284%40ix.netcom.com.
