rb_num_negative_int_p is equivalent to calling the "<" method on
Integer (and checking whether it is overridden), where in this case we
are interested in whether the "actual" value can fit inside an unsigned
int.
This also was slow because rb_num_negative_int_p calls
rb_method_basic_definition_p, doing a method lookup to check for < being
overridden.
This replaces the check in both rb_fix2uint and rb_fix2ushort with FIXNUM_NEGATIVE_P which simply checks
whether the VALUE is signed.
ndigits higher than 14 can result in values that are slightly too
large due to floating point limitations. Converting to rational
for the calculation and then back to float fixes these issues.
Fixes [Bug #14635]
Fixes [Bug #17183]
Co-authored by: Yusuke Endoh <mame@ruby-lang.org>
This speeds up performance by multiple orders of magnitude for
large integers.
Fixes [Bug #14391]
Co-authored-by: tompng (tomoya ishida) <tomoyapenguin@gmail.com>
The previous implementation could result in a returned
float that is 1/(10**ndigits) too low. First try adding
one before dividing, and if that results in a value that is
greater than the initial number, then try the original
calculation.
Spec added for ciel, but the issue doesn't appear to affect
ciel, at least not for the same number. If the issue does
effect ciel, a similar fix could probably work for it.
Fixes [Bug #18018]
* Improve perfomance for Integer#size method [Feature #17135]
* re-run ci
* Let MJIT frame skip work for Integer#size
Co-authored-by: Takashi Kokubun <takashikkbn@gmail.com>
Depending on the float range, there could be an off-by-one error,
where the last result that should be in the range was missed. Fix
this by checking if the computed value for the expected value
outside the range is still inside the range, and if so, increment
the step size.
Fixes [Bug #16612]
Previously, the result was incorrect:
4.remainder(-Float::INFINITY)
Before: => NaN
After: => 4
4.2.remainder(-Float::INFINITY)
Before: => NaN
After: => 4.2
Fixes [Bug #6120]
The error message has an integer overflow because it treats an unsigned int as a signed int.
Before:
```
> 3_000_000_000.chr
-1294967296 out of char range (RangeError)
```
After:
```
> 3_000_000_000.chr
3000000000 out of char range (RangeError)
```
Redmine ticket: https://bugs.ruby-lang.org/issues/17186
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.
A prerequisite to fix https://bugs.ruby-lang.org/issues/15589 with JIT.
This commit alone doesn't make a significant difference yet, but I thought
this commit should be committed independently.
This method override was discussed in [Misc #16961].
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).
With these macros implemented we can write codes just like we can assume
the compiler being clang. MSC_VERSION_SINCE is defined to implement
those macros, but turned out to be handy for other places. The -fdeclspec
compiler flag is necessary for clang to properly handle __has_declspec().
These functions are used from within a compilation unit so we can
make them static, for better binary size. This changeset reduces
the size of generated ruby binary from 26,590,128 bytes to
26,584,472 bytes on my macihne.
only when its receiver and the argument are both Integers.
Since 6bedbf4625, Integer#[] has supported a range extraction.
This means that Integer#[] now accepts multiple arguments, which made
the method very slow unfortunately.
This change fixes the performance issue by adding a special handling for
its traditional use case: `num[idx]` where both `num` and `idx` are
Integers.
* numeric.c (int_pow): fix infinite loop in the case of y equal 1
and power of x does not overflow.
[ruby-core:91734] [Bug #15651]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@67203 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* complex.c (rb_complex_new_polar): renamed with _new to clarify
that it creates a new instance, but is not an instance method.
* complex.c (rb_complex_polar): deprecated.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66359 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
In C, division by zero is undefined, even if the expression is double
(cf: ISO/IEC 9899:1990 section 6.3.5). OTOH we have tests about such
operations and results, means we expect no exceptional situation shall
occur. We need to carefully reroute the situation, and generate what
is needed.
See also: https://travis-ci.org/ruby/ruby/jobs/452680646#L2943
PS: Recently (last two decades), C have Annex. F document. It
normatively specifies that the division operator is IEEE 754's
division operator (cf: ISO/IEC 9899:1999 section F.3). If we could
move to such newer version this could be no problem. But that is not
possible today.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65642 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* complex.c (rb_dbl_complex_polar_pi): suffixed with _pi to
clarify that `ang` is not radian, but multiplied by PI.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65522 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* complex.c (rb_complex_pow): calculate power of a Fixnum without
allocating intermediate Complex objects, and avoid unexpected
NaNs.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65190 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
* include/ruby/ruby.h (UNREACHABLE_RETURN): UNREACHABLE at the end
of non-void functions.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64025 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* complex.c (rb_dbl_complex_polar): utility function, which
returns more precise value in right angle cases.
* bignum.c (rb_big_pow): use rb_dbl_complex_polar().
* numeric.c (rb_float_pow, fix_pow): create a Complex by polar
form.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@63678 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* bignum.c (int_pow_tmp3): get rid of redefined Integer#> on
internal calculations, as well as the GMP version.
* bignum.c (rb_int_powm): ditto.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@63660 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Typical usages:
```
p ary[1..] # drop the first element; identical to ary[1..-1]
(1..).each {|n|...} # iterate forever from 1; identical to 1.step{...}
```
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@63192 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Since 2.5, Numeric instances can be cloned and duplicated.
[Fix GH-1850]
From: Miguel Landaeta <miguel@miguel.cc>
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@63112 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
John Hawthorn
Jeremy Evans
S.H
Nobuyoshi Nakada
Burdette Lamar
Takashi Kokubun
Alan Wu
Kenta Murata
Stefan Stüben
Peter Zhu
Kazuhiro NISHIYAMA
卜部昌平
Yusuke Endoh
NARUSE, Yui
git
Hiroshi SHIBATA
nobu
mrkn
shyouhei
kazu
mame