digitalmars.D.learn - The return of std.algorithm.find
- RazvanN (8/8) Nov 15 2016 The find function which receives an input haystack and a needle
- drug (3/10) Nov 15 2016 I don't think so. You could use findSplit, it returns three ranges [1,
- drug (2/16) Nov 15 2016 See also SortedRange.trisect
- =?UTF-8?Q?Ali_=c3=87ehreli?= (13/29) Nov 15 2016 Indeed. This is what I was typing:
- RazvanN (4/12) Nov 15 2016 The whole function is find!"a <= b"(assumeSorted([1, 2, 4, 5, 6,
- drug (6/19) Nov 15 2016 IIRC find!"a <= b" will return the first element that is less or equal
- Stefan Koch (2/15) Nov 15 2016 Are you sure you don't want filter ?
- Steven Schveighoffer (5/12) Nov 15 2016 A sorted range provides better mechanisms to find values as members of
The find function which receives an input haystack and a needle returns the haystack advanced to the first occurrence of the needle. For normal ranges this is fine, but for sorted ranges (aka SortedRange) it is a bit odd. For example: find(assumeSorted[1, 2, 4, 5, 6, 7], 4) would return [4, 5, 6, 7]. This is in terms with the general policy of the find function, but is weird. Since we know the range is sorted, shouldn't the result be [1, 2, 4]?
Nov 15 2016
15.11.2016 12:43, RazvanN пишет:The find function which receives an input haystack and a needle returns the haystack advanced to the first occurrence of the needle. For normal ranges this is fine, but for sorted ranges (aka SortedRange) it is a bit odd. For example: find(assumeSorted[1, 2, 4, 5, 6, 7], 4) would return [4, 5, 6, 7]. This is in terms with the general policy of the find function, but is weird. Since we know the range is sorted, shouldn't the result be [1, 2, 4]?I don't think so. You could use findSplit, it returns three ranges [1, 2], [4], [5, 6, 7].
Nov 15 2016
15.11.2016 12:48, drug пишет:15.11.2016 12:43, RazvanN пишет:See also SortedRange.trisectThe find function which receives an input haystack and a needle returns the haystack advanced to the first occurrence of the needle. For normal ranges this is fine, but for sorted ranges (aka SortedRange) it is a bit odd. For example: find(assumeSorted[1, 2, 4, 5, 6, 7], 4) would return [4, 5, 6, 7]. This is in terms with the general policy of the find function, but is weird. Since we know the range is sorted, shouldn't the result be [1, 2, 4]?I don't think so. You could use findSplit, it returns three ranges [1, 2], [4], [5, 6, 7].
Nov 15 2016
On 11/15/2016 01:50 AM, drug wrote:15.11.2016 12:48, drug пишет:Indeed. This is what I was typing: import std.stdio; import std.range; void main() { auto r = assumeSorted([1, 2, 4, 5, 6, 7]); auto found = r.trisect(4); auto desired = chain(found[0], found[1]); writeln(desired); } Prints [1, 2, 4] Ali15.11.2016 12:43, RazvanN пишет:See also SortedRange.trisectThe find function which receives an input haystack and a needle returns the haystack advanced to the first occurrence of the needle. For normal ranges this is fine, but for sorted ranges (aka SortedRange) it is a bit odd. For example: find(assumeSorted[1, 2, 4, 5, 6, 7], 4) would return [4, 5, 6, 7]. This is in terms with the general policy of the find function, but is weird. Since we know the range is sorted, shouldn't the result be [1, 2, 4]?I don't think so. You could use findSplit, it returns three ranges [1, 2], [4], [5, 6, 7].
Nov 15 2016
On Tuesday, 15 November 2016 at 09:43:27 UTC, RazvanN wrote:The find function which receives an input haystack and a needle returns the haystack advanced to the first occurrence of the needle. For normal ranges this is fine, but for sorted ranges (aka SortedRange) it is a bit odd. For example: find(assumeSorted[1, 2, 4, 5, 6, 7], 4) would return [4, 5, 6, 7]. This is in terms with the general policy of the find function, but is weird. Since we know the range is sorted, shouldn't the result be [1, 2, 4]?The whole function is find!"a <= b"(assumeSorted([1, 2, 4, 5, 6, 7]), 4). And the result is the whole range [1, 2, 4, 5, 6, 7].
Nov 15 2016
15.11.2016 12:50, RazvanN пишет:On Tuesday, 15 November 2016 at 09:43:27 UTC, RazvanN wrote:IIRC find!"a <= b" will return the first element that is less or equal to needle, so this will be the whole range. To find all elements of SortedRange that are less or equal to needle you need to use SortedRange.lowerBoundThe find function which receives an input haystack and a needle returns the haystack advanced to the first occurrence of the needle. For normal ranges this is fine, but for sorted ranges (aka SortedRange) it is a bit odd. For example: find(assumeSorted[1, 2, 4, 5, 6, 7], 4) would return [4, 5, 6, 7]. This is in terms with the general policy of the find function, but is weird. Since we know the range is sorted, shouldn't the result be [1, 2, 4]?The whole function is find!"a <= b"(assumeSorted([1, 2, 4, 5, 6, 7]), 4). And the result is the whole range [1, 2, 4, 5, 6, 7].
Nov 15 2016
On Tuesday, 15 November 2016 at 09:50:40 UTC, RazvanN wrote:On Tuesday, 15 November 2016 at 09:43:27 UTC, RazvanN wrote:Are you sure you don't want filter ?The find function which receives an input haystack and a needle returns the haystack advanced to the first occurrence of the needle. For normal ranges this is fine, but for sorted ranges (aka SortedRange) it is a bit odd. For example: find(assumeSorted[1, 2, 4, 5, 6, 7], 4) would return [4, 5, 6, 7]. This is in terms with the general policy of the find function, but is weird. Since we know the range is sorted, shouldn't the result be [1, 2, 4]?The whole function is find!"a <= b"(assumeSorted([1, 2, 4, 5, 6, 7]), 4). And the result is the whole range [1, 2, 4, 5, 6, 7].
Nov 15 2016
On 11/15/16 4:43 AM, RazvanN wrote:The find function which receives an input haystack and a needle returns the haystack advanced to the first occurrence of the needle. For normal ranges this is fine, but for sorted ranges (aka SortedRange) it is a bit odd. For example: find(assumeSorted[1, 2, 4, 5, 6, 7], 4) would return [4, 5, 6, 7]. This is in terms with the general policy of the find function, but is weird. Since we know the range is sorted, shouldn't the result be [1, 2, 4]?A sorted range provides better mechanisms to find values as members of SortedRange. Don't use find(assumeSorted(...)), as it's still a linear search. -Steve
Nov 15 2016