[#100309] How to use backport custom field — Jun Aruga <jaruga@...>
Please allow my ignorance.
9 messages
2020/10/06
[#100310] Re: How to use backport custom field
— "NARUSE, Yui" <naruse@...>
2020/10/06
"Backport custom field" is only available for tickets whose tracker is "Bug".
[#100311] Re: How to use backport custom field
— Jun Aruga <jaruga@...>
2020/10/06
On Tue, Oct 6, 2020 at 4:44 PM NARUSE, Yui <naruse@airemix.jp> wrote:
[#100314] Re: How to use backport custom field
— "NARUSE, Yui" <naruse@...>
2020/10/06
Thank you for confirmation.
[#100322] Re: How to use backport custom field
— Jun Aruga <jaruga@...>
2020/10/07
On Tue, Oct 6, 2020 at 7:25 PM NARUSE, Yui <naruse@airemix.jp> wrote:
[#100326] Re: How to use backport custom field
— "NARUSE, Yui" <naruse@...>
2020/10/07
I added you to "Reporter" role in the project
[#100327] Re: How to use backport custom field
— Jun Aruga <jaruga@...>
2020/10/07
On Wed, Oct 7, 2020 at 1:42 PM NARUSE, Yui <naruse@airemix.jp> wrote:
[#100358] [BUG] ruby 2.6.6 warning with encdb.so — shiftag <shiftag@...>
Hello,
1 message
2020/10/10
[ruby-core:100374] [Ruby master Bug#17257] Integer#pow(0, 1) returns 1, which is incorrect
From:
midnight_w@...
Date:
2020-10-11 13:18:07 UTC
List:
ruby-core #100374
Issue #17257 has been updated by midnight (Sarun R). The point of undefinition is: There is nothing definitely right or wrong. Neither 0 nor 1 is wrong; it is just a different point of view. You are thinking that 0 ** 0 == 1 is useful because you are looking from the perspective of x ** 0 == 1 for most of x while 0 ** x == 0 is also true for most of x too, and it is as useful as x ** 0 == 1. Weather 0 ** 0 should return 0 or 1 is subjective, and whatever the actual implementation is, it is not entirely wrong, same for little-endian vs. big-endian. This is the reason why the value is undefined. Regardless of mathematical definitions, I second for `x.pow(y, 1)` should return 0, as I said initially, `% m` is the space and every value inside `% 1` space is 0. Mathematical wise this is considered undefined behavior. Implementation wise there is an advantage that we follow other popular languages in this matter. I just want to point out that people who oppose the behavior change has some merit. Even if the current behavior sounds wildly wrong, most people are not going to care, because the value is mathematically undefined in the first place. And no practical result will be obtained from `% 1` space. Anyway, `x % 1 == 0` sound more "correct" to me too. ---------------------------------------- Bug #17257: Integer#pow(0, 1) returns 1, which is incorrect https://bugs.ruby-lang.org/issues/17257#change-87984 * Author: universato (Yoshimine Sato) * Status: Assigned * Priority: Normal * Assignee: mrkn (Kenta Murata) * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN ---------------------------------------- Ruby 2.5.8, 2.6.6, 2.7.1 ```ruby p -1.pow(0, 1) #=> 1 p 0.pow(0, 1) #=> 1 p 1.pow(0, 1) #=> 1 p 1234567890.pow(0, 1) #=> 1 ``` These return values should be 0. Patch for test: Let's add some boundary value tests to `test_pow` of [test_numeric.rb](https://github.com/ruby/ruby/blob/e014e6bf6685f681998238ff005f6d161d43ce51/test/ruby/test_numeric.rb). ```ruby integers = [-2, -1, 0, 1, 2, 3, 6, 1234567890123456789] integers.each do |i| assert_equal(0, i.pow(0, 1), '[Bug #17257]') assert_equal(1, i.pow(0, 2)) assert_equal(1, i.pow(0, 3)) assert_equal(1, i.pow(0, 6)) assert_equal(1, i.pow(0, 1234567890123456789)) assert_equal(0, i.pow(0, -1)) assert_equal(-1, i.pow(0, -2)) assert_equal(-2, i.pow(0, -3)) assert_equal(-5, i.pow(0, -6)) assert_equal(-1234567890123456788, i.pow(0, -1234567890123456789)) end assert_equal(0, 0.pow(2, 1)) assert_equal(0, 0.pow(3, 1)) assert_equal(0, 2.pow(3, 1)) assert_equal(0, -2.pow(3, 1)) -- https://bugs.ruby-lang.org/ Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>