Actually, upon measuring this, first(searchsorted(v)) is only 20% slower
than searchsortedfirst(v), and it's actually quite hard to even concoct a
case where this takes a measurable amount of time – O(log(n)) is an amazing
thing. I'm tempted to just deprecate searchsorted{first,last}.On Fri, Feb 6, 2015 at 10:26 AM, Stefan Karpinski <[email protected]> wrote: > Yes, my point was really that I'd like to delete searchsorted{first,last} > and just write first(searchsorted(v)) and last(searchsorted(v)). The only > reason this hasn't happened is that there's a slight performance hit to > doing that. If we could get the performance the same, I would delete them. > > On Thu, Feb 5, 2015 at 7:03 PM, Kevin Squire <[email protected]> > wrote: > >> (renamed topic because it diverges from the original) >> >> On Thu, Feb 5, 2015 at 12:29 PM, Stefan Karpinski <[email protected]> >> wrote: >> >>> The general philosophy is that for user code, having underscores in >>> names is fine, especially when the name refers to a composite thing. In >>> Base Julia, we consider long names with underscores to be a library design >>> smell that suggests that we're exposing something that's not sufficiently >>> atomic. The example of searchsortedlast and searchsortedfirst is in line >>> with this – I've never liked these names and would generally prefer to >>> simply have searchsorted returning a range from the first to last index >>> where the value occurs (which is an empty range when the value does not >>> occur at all). >>> >> >> Isn't this what searchsorted already does? >> >> julia> searchsorted([1,2,3,3,3,5], 3) >> 3:5 >> >> julia> searchsorted([1,2,3,3,3,5], 4) >> 6:5 >> >> As we discussed a couple of years ago >> <https://groups.google.com/d/topic/julia-dev/s7Xu-Jvo3Yw/discussion>, >> unexporting them is an option. That got some pushback (from one person) at >> the time, but going through one round of deprecation should indicate how >> much people use these functions. >> >> Cheers, >> >> Kevin >> > >
