[#35400] Fwd: [ruby-cvs:38176] Ruby:r30994 (trunk): * string.c (rb_str_byteslice): the resulted encoding should keep — "Martin J. Dst" <duerst@...>
I'm really surprised that the encoding is kept for an arbitrary byteslice.
[#35403] Why are hash keys sometimes duped? — Aaron Patterson <aaron@...>
Why are some objects duped when they are used as hash keys and other
Aaron Patterson <[email protected]> wrote:
[#35417] [Ruby 1.9 - Bug #4463][Open] [PATCH] release GVL for fcntl() for operations that may block — Eric Wong <normalperson@...>
> Issue #4463 has been reported by Eric Wong.
Hi
KOSAKI Motohiro <[email protected]> wrote:
Hi
[#35426] [Ruby 1.8 - Bug #4467][Open] Process.maxgroups= should only accept numeric values — Daniel Berger <djberg96@...>
[#35440] [Ruby 1.9 - Feature #1047] request: getters, setters for the GC — Narihiro Nakamura <authorNari@...>
[#35446] [Ruby 1.9 - Bug #4477][Open] Kernel:exec and backtick (`) don't work for certain system commands — Joachim Wuttke <j.wuttke@...>
[#35462] Source for 1.8 syck gram.y and token.re? — Kurt Stephens <ks@...>
I found bug in 1.8 ext/syck. The problem is in gram.c and/or token.c.
This is obviously dead and gone: http://whytheluckystiff.net/syck/
Syck is dead. 1.9 should make Psych/libyaml default. The fact that
I know syck is dead.
Maybe it's possible to bribe Aaron into releasing a Psych gem for 1.8?
[#35483] /proc/$PID/environ in Linux — Eric Wong <normalperson@...>
I wanted to inspect the environment of a long-running process[1] and I
[#35494] Re: can someone explain this? — Michael Edgar <adgar@...>
[+ruby-core]
[#35509] Why has defined? been changed for autoloaded constants in 1.9? — Nikolai Weibull <now@...>
Hi!
[#35513] String#upcase and UTF-8/Unicode not working — Nikolai Weibull <now@...>
Why does the following print =E2=80=9D=C3=A4BC=E2=80=9D instead of =E2=80=
[#35519] NoMethodError#message may take very long to execute — Adiel Mittmann <adiel@...>
Hello,
[#35528] [Ruby 1.9 - Feature #4512][Open] [PATCH] ext/fcntl/fcntl.c: add F_DUPFD_CLOEXEC constant — Eric Wong <normalperson@...>
[#35536] File.write take 4 — Roger Pack <rogerdpack2@...>
Hello all.
Could I get any feedback on my latest patch for File.write?
[#35552] [Ruby 1.9 - Feature #4523][Open] Kernel#require to return the path of the loaded file — Alex Young <alex@...>
On 18/03/12 10:22, nobu wrote:
On Mon, Mar 19, 2012 at 8:06 AM, Alex Young <[email protected]> wrote:
On 19/03/12 11:58, Luis Lavena wrote:
[#35555] [Ruby 1.9 - Bug #4527][Open] [PATCH] IO#close releases GVL if possible — Eric Wong <normalperson@...>
[#35565] [Ruby 1.9 - Feature #4531][Open] [PATCH 0/7] use poll() instead of select() in certain cases — Eric Wong <normalperson@...>
> ref: [ruby-core:35527]
KOSAKI Motohiro <[email protected]> wrote:
2011/3/29 Eric Wong <[email protected]>:
Comment for patch 2.
Motohiro KOSAKI <[email protected]> wrote:
diff --git a/ext/-test-/wait_for_single_fd/wait_for_single_fd.c
[#35566] [Ruby 1.9 - Feature #4532][Open] [PATCH] add IO#pread and IO#pwrite methods — Eric Wong <normalperson@...>
2011/3/28 Eric Wong <[email protected]>:
KOSAKI Motohiro <[email protected]> wrote:
[#35567] [Ruby 1.9 - Bug #4534][Open] ri does not open $PAGER with program name only — Robert Klemme <shortcutter@...>
[#35586] [Ruby 1.9 - Feature #4538][Open] [PATCH (cleanup)] avoid unnecessary select() calls before doing I/O — Eric Wong <normalperson@...>
Charles Nutter <[email protected]> wrote:
[ruby-core:35540] [Ruby 1.9 - Backport #3803] BigDecimal::ROUND_HALF_DOWN/ROUND_HALF_EVEN behave incorrectly (disagree with JRuby and the rest of the world)
Issue #3803 has been updated by Kenta Murata.
Target version changed from 1.9.3 to 1.9.2
----------------------------------------
Backport #3803: BigDecimal::ROUND_HALF_DOWN/ROUND_HALF_EVEN behave incorrectly (disagree with JRuby and the rest of the world)
http://redmine.ruby-lang.org/issues/3803
Author: Matthew Willson
Status: Assigned
Priority: Normal
Assignee: Yuki Sonoda
Category: ext
Target version: 1.9.2
The incorrect behaviour is that all fractional values between 0.5 (inclusive) and 0.6 (non-inclusive) are subject to the rounding policy for 'half', whereas it should only be applied for fractional values exactly equal to 0.5.
This means that, for example, 0.59 is rounded down to 0 by ROUND_HALF_DOWN and ROUND_HALF_EVEN:
>> BigDecimal.new("0.59").round(0, BigDecimal::ROUND_HALF_DOWN).to_s('F')
=> "0.0"
>> BigDecimal.new("0.56").round(0, BigDecimal::ROUND_HALF_EVEN).to_s('F')
=> "0.0"
The behaviour is actually specified this way in the RDoc:
> ROUND_HALF_DOWN: round up if the appropriate digit >= 6, otherwise truncate
But this is most definitely not what most people would expect from 'round half down' (see eg: http://en.wikipedia.org/wiki/Rounding#Round_half_down ). I would expect it to only round down if the fractional part is less than or *exactly equal* to 0.5. It needs to take into account more than just the first decimal digit to do this; while the first decimal digit of 0.59 may be 5, it is not equal to 0.5 and hence should not be subject to the 'half down' rounding policy. (Note that ROUND_HALF_UP still works correctly, since the correct behaviour here can indeed be implemented by only inspecting the first decimal digit; but this is not the case for ROUND_HALF_DOWN or in general for ROUND_HALF_EVEN)
Rather misleadingly, ROUND_HALF_EVEN is specified as being "banker's rounding":
> ROUND_HALF_EVEN: round towards the even neighbor (Banker’s rounding)
But since it incorrectly applies the 'half towards even' policy not just to 0.5, but to all values in the [0.5, 0.6) interval, it is not "banker's rounding" as this is usually defined, and is surely a biased rounding policy, which is exactly what banker's rounding is seeking to avoid (see eg http://en.wikipedia.org/wiki/Rounding#Round_half_to_even )
I note (as just one example) that Java's BigDecimal specifies and implements ROUND_HALF_DOWN in the correct way: http://download-llnw.oracle.com/javase/6/docs/api/java/math/BigDecimal.html#ROUND_HALF_DOWN
> Rounding mode to round towards "nearest neighbor" unless both neighbors are equidistant, in which case round down.
And that JRuby's BigDecimal appears to be based on this, hence is correct and hence disagrees with MRI when (for example) applying ROUND_HALF_DOWN to 0.59:
irb(main):004:0> RUBY_PLATFORM
=> "java"
irb(main):005:0> BigDecimal.new("0.59").round(0, BigDecimal::ROUND_HALF_DOWN).to_s('F')
=> "1.0"
Backport to 1.8.7 would be nice if this gets fixed.
--
http://redmine.ruby-lang.org