I don't know the answer but here is a conjecture : slices grow at the end
(through append), so a recent un-sortedness would be likely to be found
near the end of the slice.
(slices are the most commonly used types for "data", correct me if I'm
wrong)
On a related note, a while ago I microbenchmarked accessing all the
elements of a slice, forwards or backwards : both traversals had very
similar timings (which is not true when accessing in a scrambled
permutation order). Thus, I wouldn't expect the end-to-beginning loop to
cause a performance penalty.
Val
On Thursday, April 20, 2017 at 3:49:49 PM UTC+2, Ivan Kurnosov wrote:
>
> Hi
>
> At the moment it is implemented as
>
> 295 func IsSorted(data Interface) bool { 296 n :=
> data.Len() 297 for i := n - 1; i > 0; i-- { 298
> if data.Less(i, i-1) { 299 return false
> 300 } 301 } 302 return true 303
> }
>
>
> Is there any practical (technical) reason for this loop to be
> end-to-beginning, or is it just a preference of someone who implemented it?
>
--
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.
For more options, visit https://groups.google.com/d/optout.
