| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Range#overlap? assumes that there is no minimum value.
This assumption makes
+(...-Float::INFINITY).overlap?((...-Float::INFINITY))+ returns true
while +(...-Float::INFINITY)+ is empty.
|
|
|
|
|
|
|
|
|
|
|
|
Caused by 04a92a6764bf678919cf4b68a27496a39d6b886a. This treats
unbounded ranges of arbitrary objects the same as how unbounded
string ranges are treated:
(..x) === y # (y <=> x) <= 0
(...x) === y # (y <=> x) < 0
(x..) === y # (x <=> y) <= 0
Fixes [Bug #19864]
|
|
|
|
Empty ranges do not overlap with any range.
Regarding benchmarks, PR#8242 is significantly faster in some cases,
but one of these two cases is a wrong result.
| |ActiveSupport| PR#8242|built-ruby|
|:--------------------------|------------:|-------:|---------:|
|(2..3).overlap?(1..1) | 7.761M| 15.053M| 32.368M|
| | -| 1.94x| 4.17x|
|(2..3).overlap?(2..4) | 25.720M| 55.070M| 21.981M|
| | 1.17x| 2.51x| -|
|(2..3).overlap?(4..5) | 7.616M| 15.048M| 21.730M|
| | -| 1.98x| 2.85x|
|(2..3).overlap?(2..1) | 25.585M| 56.545M| 32.786M|
| | -| 2.21x| 1.28x|
|(2..3).overlap?(0..1) | 7.554M| 14.755M| 32.545M|
| | -| 1.95x| 4.31x|
|(2..3).overlap?(...1) | 6.681M| 5.843M| 32.255M|
| | 1.14x| -| 5.52x|
|(2...3).overlap?(..2) | 6.676M| 5.817M| 21.572M|
| | 1.15x| -| 3.71x|
|(2...3).overlap?(3...) | 7.392M| 14.755M| 31.805M|
| | -| 2.00x| 4.30x|
|(2..3).overlap?('a'..'d') | 3.675M| 3.482M| 17.009M|
| | 1.06x| -| 4.89x|
|
|
Add a method that returns true if two range overlap, otherwise false.
```
(0..10).overlap?(5..15) #=> true
(0..10).overlap?(20..30) #=> false
```
|
|
On Range#bsearch for endless ranges, we try positions at `begin + 2**i` (i = 0, 1, 2, ...)
to find a point that satisfies a given condition.
Subsequently, we perform binary searching with the interval `[begin, begin + 2**n]`.
However, the interval `[begin + 2**(n-1), begin + 2**n]` is sufficient for binary search
because `begin + 2**(n-1)` does not satisfy the condition.
The same applies to beginless ranges.
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/7574
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/7574
|
|
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/7277
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/7005
Merged-By: nobu <[email protected]>
|
|
Prior to this commit the `OPTIMIZED_CMP` macro relied on a method lookup
to determine whether `<=>` was overridden. The result of the lookup was
cached, but only for the duration of the specific method that
initialized the cmp_opt_data cache structure.
With this method lookup, `[x,y].max` is slower than doing `x > y ?
x : y` even though there's an optimized instruction for "new array max".
(John noticed somebody a proposed micro-optimization based on this fact
in https://github.com/mastodon/mastodon/pull/19903.)
```rb
a, b = 1, 2
Benchmark.ips do |bm|
bm.report('conditional') { a > b ? a : b }
bm.report('method') { [a, b].max }
bm.compare!
end
```
Before:
```
Comparison:
conditional: 22603733.2 i/s
method: 19820412.7 i/s - 1.14x (± 0.00) slower
```
This commit replaces the method lookup with a new CMP basic op, which
gives the examples above equivalent performance.
After:
```
Comparison:
method: 24022466.5 i/s
conditional: 23851094.2 i/s - same-ish: difference falls within
error
```
Relevant benchmarks show an improvement to Array#max and Array#min when
not using the optimized newarray_max instruction as well. They are
noticeably faster for small arrays with the relevant types, and the same
or maybe a touch faster on larger arrays.
```
$ make benchmark COMPARE_RUBY=<master@5958c305> ITEM=array_min
$ make benchmark COMPARE_RUBY=<master@5958c305> ITEM=array_max
```
The benchmarks added in this commit also look generally improved.
Co-authored-by: John Hawthorn <[email protected]>
|
|
Beginless ranges previously raised TypeError for this case,
except for string ranges, which had unexpected behavior:
('a'..'z').include?('ww') # false
(..'z').include?('ww') # previously true, now TypeError
Use of include? with endless ranges could previously result
in an infinite loop.
This splits off a range_string_cover_internal function from
range_include_internal.
Fixes [Bug #18580]
Notes:
Merged: https://github.com/ruby/ruby/pull/6261
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/6721
|
|
Fixes [Bug #18983]
Notes:
Merged: https://github.com/ruby/ruby/pull/6604
|
|
[Bug #18994]
Notes:
Merged: https://github.com/ruby/ruby/pull/6324
|
|
[Misc #18891]
Notes:
Merged: https://github.com/ruby/ruby/pull/6094
|
|
Previously `(2..).cover?("2"..)` was false, but
`(..2).cover?(.."2")` was true. This changes it so both are false,
treating beginless ranges the same as endless ranges in regards to
type checks.
This also adds documentation to #cover? to describe behavior with
beginless and endless ranges, testing each documentation example,
which is how this bug was found.
Fixes [Bug #18155]
Notes:
Merged: https://github.com/ruby/ruby/pull/5831
|
|
|
|
Repaired What's Here sections for Range, String, Symbol, Struct.
Notes:
Merged-By: BurdetteLamar <[email protected]>
|
|
|
|
Previously, include? would return true for the end of the range,
when it should return false because the range is exclusive.
Research and Analysis by Victor Shepelev.
Fixes [Bug #18577]
Notes:
Merged: https://github.com/ruby/ruby/pull/5541
|
|
Once https://github.com/ruby/rdoc/pull/865 is merged, these hacks
are no longer needed.
|
|
|
|
I used this regex:
(?<=\[)#(?:class|module)-([A-Za-z]+)-label-([A-Za-z0-9\-\+]+)
And performed a global find & replace for this:
rdoc-ref:$1@$2
Notes:
Merged: https://github.com/ruby/ruby/pull/5530
|
|
I used this regex:
([A-Za-z]+)\.html#(?:class|module)-[A-Za-z]+-label-([A-Za-z0-9\-\+]+)
And performed a global find & replace for this:
rdoc-ref:$1@$2
Notes:
Merged: https://github.com/ruby/ruby/pull/5530
|
|
* Adding links to literals and Kernel
Notes:
Merged-By: BurdetteLamar <[email protected]>
|
|
* Some code replace and using RBOOL macro
* Fix indent
* Using RBOOL in syserr_eqq function
Notes:
Merged-By: nobu <[email protected]>
|
|
Code markup in RDoc must not be concatenated with anothr word.
|
|
|
|
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/4923
Merged-By: nobu <[email protected]>
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/4925
Merged-By: nobu <[email protected]>
|
|
In commit:7817a438eb1803e7b3358f43bd1f38479badfbdc, the implementation
of `Time#succ`, which had been deprecated for 10 years, was finally
removed.
During that time, there was an explicit `instance_of?` check in
source:range.c#L350 with a comment that the check should be removed
once `Time#succ` is removed.
Since `Time#succ` is now gone, this check should be removed.
Note: this should be coordinated with adding a version guard to the
corresponding check in ruby/spec as well.
Notes:
Merged: https://github.com/ruby/ruby/pull/4928
Merged-By: nobu <[email protected]>
|
|
Notes:
Merged-By: BurdetteLamar <[email protected]>
|
|
Notes:
Merged-By: BurdetteLamar <[email protected]>
|
|
Introductory material revised.
Notes:
Merged-By: BurdetteLamar <[email protected]>
|
|
Treated:
#to_s
#inspect
#===
#include?
#cover?
#count
Notes:
Merged-By: BurdetteLamar <[email protected]>
|
|
Notes:
Merged-By: BurdetteLamar <[email protected]>
|
|
Notes:
Merged-By: BurdetteLamar <[email protected]>
|
|
Notes:
Merged-By: BurdetteLamar <[email protected]>
|
|
* As the "doc/" prefix is specified by the `--page-dir` option,
remove from the rdoc references.
* Refer to the original .rdoc instead of the converted .html.
|
|
Treated:
#size
#to_a
#each
#begin
#end
#first
#last
Notes:
Merged-By: BurdetteLamar <[email protected]>
|
