Popular Ruby libraries such as Rails and Rubocop relying on the
previous behavior, even though it is technically a bug. The
correct behavior is probably raising RangeError, since that is what
an endless range raises.
Related to [Bug #17017]
Previously, for inclusive ranges, the max would show up as the
end of the range, even though the end was not an integer and would
not be the maximum value. For exclusive ranges, max/minmax would
previously raise a TypeError, even though it is possible to get the
correct maximum.
This change to max/minmax also uncovered a similar error in cover?,
which calls max in certain cases, so adjust the code there so that
cover? still works as expected.
Fixes [Bug #17017]
The implementation of Range#minmax added in d5c60214c4 causes the
following incorrect behaviour:
('a'...'c').minmax => ["a", ["a", "b"]]
instead of
('a'...'c').minmax => ["a", "b"]
This is because the C implementation of Range#minmax (range_minmax)
directly delegates to the C implementation of Range#min (range_min) and
Range#max (range_max), without changing the execution context.
Range#max's C implementation (range_max), when given a non-numeric
exclusive range, delegates to super, which is meant to call
Enumerable#max. However, because range_max is called directly by
range_minmax, super calls Enumerable#minmax instead, causing the
incorrect nesting.
Perhaps it is possible to change the execution context in an optimized
manner, but the simplest solution seems to be to just explicitly
delegate from Range#minmax to Range#min and Range#max.
Not every compilers understand that rb_raise does not return. When a
function does not end with a return statement, such compilers can issue
warnings. We would better tell them about reachabilities.
Saves comitters' daily life by avoid #include-ing everything from
internal.h to make each file do so instead. This would significantly
speed up incremental builds.
We take the following inclusion order in this changeset:
1. "ruby/config.h", where _GNU_SOURCE is defined (must be the very
first thing among everything).
2. RUBY_EXTCONF_H if any.
3. Standard C headers, sorted alphabetically.
4. Other system headers, maybe guarded by #ifdef
5. Everything else, sorted alphabetically.
Exceptions are those win32-related headers, which tend not be self-
containing (headers have inclusion order dependencies).
* Change === docs to mention it uses cover?
* Add different example to === docs to showcase
behavior better
* Change include? docs to mention cover?
and clarify the difference
This removes the related tests, and puts the related specs behind
version guards. This affects all code in lib, including some
libraries that may want to support older versions of Ruby.
Previously, Range#=== treated string ranges that were not endless or
beginless the same as include?, instead of the same as cover?.
I think this was an oversight in 989e07c0f2,
as the commit message did not indicate this behavior was desired.
This also makes some previously dead code no longer dead. Previously,
the conditionals were doing this:
if (RB_TYPE_P(beg, T_STRING)
if (NIL_P(beg)) # can never be true
This restructures it so at the NIL_P(beg) check, beg could possibly
be nil (beginless ranges).
Fixes [Bug #15449]
Range#minmax was previous not implemented, so calling #minmax on
range was actually calling Enumerable#minmax. This is a simple
implementation of #minmax by just calling range_min and range_max.
Fixes [Bug #15867]
Fixes [Bug #15807]
* range.c (range_step): fix the guard condition so that a beginless
range can be turned into a beginless arithmetic sequence.
* test/ruby/test_range.rb (test_step): add assertions for the above
change.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@67433 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Do not use the optimized version of Range#last when Range#each is
redefined.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66749 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
This change improves the performance of Range#last method for a range
of integer. This optimization directly computes only required values
only in a range instead of converting all values in the range to an
array. The optimized implementation is 129-16.7k times faster than
the previous one in the benchmark result given below.
=== Benchmark Result ===
```
$ make benchmark ITEM=range_last COMPARE_RUBY=/Users/mrkn/.rbenv/versions/2.6.0/bin/ruby
generating known_errors.inc
known_errors.inc unchanged
/Users/mrkn/src/github.com/ruby/ruby/revision.h unchanged
/Users/mrkn/.rbenv/shims/ruby --disable=gems -rrubygems -I/Users/mrkn/src/github.com/ruby/ruby/benchmark/lib /Users/mrkn/src/github.com/ruby/ruby/benchmark/benchmark-driver/exe/benchmark-driver \
--executables="compare-ruby::/Users/mrkn/.rbenv/versions/2.6.0/bin/ruby -I.ext/common --disable-gem" \
--executables="built-ruby::./miniruby -I/Users/mrkn/src/github.com/ruby/ruby/lib -I. -I.ext/common -r/Users/mrkn/src/github.com/ruby/ruby/prelude --disable-gem" \
$(find /Users/mrkn/src/github.com/ruby/ruby/benchmark -maxdepth 1 -name '*range_last*.yml' -o -name '*range_last*.rb' | sort)
Warming up --------------------------------------
(1..1_000_000).last(100) 35.600 i/s - 36.000 times in 1.011239s (28.09ms/i)
(1..1_000_000).last(1000) 36.204 i/s - 39.000 times in 1.077240s (27.62ms/i)
(1..1_000_000).last(10000) 36.470 i/s - 39.000 times in 1.069386s (27.42ms/i)
Calculating -------------------------------------
compare-ruby built-ruby
(1..1_000_000).last(100) 36.477 609.196k i/s - 106.000 times in 2.905950s 0.000174s
(1..1_000_000).last(1000) 35.936 50.350k i/s - 108.000 times in 3.005321s 0.002145s
(1..1_000_000).last(10000) 35.641 4.602k i/s - 109.000 times in 3.058233s 0.023685s
Comparison:
(1..1_000_000).last(100)
built-ruby: 609195.7 i/s
compare-ruby: 36.5 i/s - 16700.87x slower
(1..1_000_000).last(1000)
built-ruby: 50349.7 i/s
compare-ruby: 35.9 i/s - 1401.08x slower
(1..1_000_000).last(10000)
built-ruby: 4602.1 i/s
compare-ruby: 35.6 i/s - 129.12x slower
```
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66734 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Reject ArithmeticSequence in rb_range_values so that methods like
Array#[] raises TypeError for ArithmeticSequence as an index.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66478 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
New public C-API for extracting components of Enumerator::ArithmeticSequence
or Range.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66351 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Especially over checking argc then calling rb_scan_args just to
raise an ArgumentError.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66238 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* range.c (range_cover): add code for range argument.
If the argument is a Range, check it is or is not
covered by the reciver. If it can be treated as a
sequence, this method treats it that way.
* test/ruby/test_range.rb (class TestRange): add tests
for this feature.
This patch is written by Owen Stephens. thank you!
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64640 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
This commit introduces new core class Enumerator::ArithmeticSequence.
Enumerator::ArithmeticSequence is a subclass of Enumerator, and
represents a number generator of an arithmetic sequence.
After this commit, Numeric#step and Range#step without blocks
returned an ArithmeticSequence object instead of an Enumerator.
This class introduces the following incompatibilities:
- You can create a zero-step ArithmeticSequence,
and its size is not ArgumentError, but Infinity.
- You can create a negative-step ArithmeticSequence from a range.
[ruby-core:82816] [Feature #13904]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64205 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Koichi Sasada
Nobuyoshi Nakada
Jeremy Evans
Michael Kohl
Sam Bostock
卜部昌平
Yusuke Endoh
zverok
manga_osyo
nobu
mrkn
mame
stomar
marcandre
kazu
tarui