Re:Go is not an easy language
by chinmaythosar on Sunday February 21, 2021 @11:30PM
(#26220880)
Linear search if it's not sorted. If it's sorted binary search will be much faster. So you need a flag for the function to tell it to use one of the two. This is why writing generic functions can be tricky. Programmers may use something inefficient just because it makes their lives easier.
[ Parent
| on HN ]
linear search can be faster than binary search for small arrays, depending on your processor architecture.
writing generic functions is difficult, so it's nice if a language allows people to do so, otherwise you get N inefficient and/or buggy reimplementations of the function in every project needing it. (not sure if that is your point)
Linear search is also quite a bit faster than maps for small arrays (in Go at least, last time I tested it).
obligatory link: https://www.evanjones.ca/linear-search.html
Re:Go is not an easy language
by chinmaythosar on Monday February 22, 2021 @12:29AM
(#26221199)
my point was that the author uses an example like search and called go not an easy language. so i was trying to give an example where it's not necessary a linear search or search is trivial ...
Re:Go is not an easy language
by anonymoushn on Monday February 22, 2021 @01:19AM
(#26221425)
If your developers hand write a binary search to delete an element you are extremely likely to end up with bugs. So it would be nice if there was a generic binary search too.
Re:Go is not an easy language
by BenFrantzDale on Monday February 22, 2021 @06:51AM
(#26223458)
That Go doesn’t have the equivalent of `std::lower_bound` is pretty ridiculous.
Binary search won’t be any faster (in big O) because it’s backed by an array: you’ll still need to copy every element after the removed one from slot n to n-1.
Does Ruby track that a list is already sorted? If not, you are still adding cognitive overhead for the programmer to track it