[#81999] [Ruby trunk Bug#13737] "can't modify frozen String" when installing bundled gems — ko1@...
Issue #13737 has been updated by ko1 (Koichi Sasada).
4 messages
2017/07/11
[#82005] [Ruby trunk Bug#13737] "can't modify frozen String" when installing bundled gems — nobu@...
Issue #13737 has been updated by nobu (Nobuyoshi Nakada).
3 messages
2017/07/12
[#82102] Re: register_fstring_tainted:FL_TEST_RAW(str, RSTRING_FSTR) — Eric Wong <normalperson@...>
Koichi Sasada <ko1@atdot.net> wrote:
4 messages
2017/07/18
[#82151] [Ruby trunk Feature#13637] [PATCH] tool/runruby.rb: test with smallest possible machine stack — Rei.Odaira@...
Issue #13637 has been updated by ReiOdaira (Rei Odaira).
3 messages
2017/07/24
[ruby-core:81900] [Ruby trunk Bug#13711] Unexpected behavior of bit_length method on negative integers
From:
jzakiya@...
Date:
2017-07-04 15:01:07 UTC
List:
ruby-core #81900
Issue #13711 has been updated by jzakiya (Jabari Zakiya). Thanks for the explanation. This morning I went and looked at the documentation for **bit_length** and it clearly describes its behavior. After reading it, and your explanation, I now understand the logic for its behavior. http://ruby-doc.org/core-2.4.1/Integer.html ``` bit_length → integer click to toggle source Returns the number of bits of the value of int. "the number of bits" means that the bit position of the highest bit which is different to the sign bit. (The bit position of the bit 2**n is n+1.) If there is no such bit (zero or minus one), zero is returned. ``` ---------------------------------------- Bug #13711: Unexpected behavior of bit_length method on negative integers https://bugs.ruby-lang.org/issues/13711#change-65629 * Author: jzakiya (Jabari Zakiya) * Status: Open * Priority: Normal * Assignee: * Target version: * ruby -v: * Backport: 2.2: UNKNOWN, 2.3: UNKNOWN, 2.4: UNKNOWN ---------------------------------------- The two's complement representation of negative integers produces unexpected results when the **bit_length** method is applied to them. ``` 5.bit_length => 3 4.bit_length => 3 3.bit_length => 2 2.bit_length => 2 1.bit_length => 1 0.bit_length => 0 (-1).bit_length => 0 (-2).bit_length => 1 (-3).bit_length => 2 (-4).bit_length => 2 (-5).bit_length => 3 (-6).bit_length => 3 (-7).bit_length => 3 (-8).bit_length => 3 (-9).bit_length => 4 ``` I would have thought that **bit_length** on a negative integer would return the number of bits it takes to represent a two's complement number on the given cpu/os. Since the two's complement of negative integers are of the form: ``` -1 => 111111111111111111 -2 => 111111111111111110 -3 => 111111111111111101 -4 => 111111111111111100 -5 => 111111111111111011 -6 => 111111111111111010 -7 => 111111111111111001 -8 => 111111111111111000 -9 => 111111111111110111 ``` it thus appears for negative integers **bit_length** returns the bit position of the left most **0** of the two's complement representation. Is this correct? Is this intentional? If so, can an explanation of this behavior/rationale be given. -- 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>