[#86787] [Ruby trunk Feature#14723] [WIP] sleepy GC — ko1@...
Issue #14723 has been updated by ko1 (Koichi Sasada).
13 messages
2018/05/01
[#86790] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC
— Eric Wong <normalperson@...>
2018/05/01
ko1@atdot.net wrote:
[#86791] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC
— Koichi Sasada <ko1@...>
2018/05/01
On 2018/05/01 12:18, Eric Wong wrote:
[#86792] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC
— Eric Wong <normalperson@...>
2018/05/01
Koichi Sasada <ko1@atdot.net> wrote:
[#86793] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC
— Koichi Sasada <ko1@...>
2018/05/01
On 2018/05/01 12:47, Eric Wong wrote:
[#86794] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC
— Eric Wong <normalperson@...>
2018/05/01
Koichi Sasada <ko1@atdot.net> wrote:
[#86814] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC
— Koichi Sasada <ko1@...>
2018/05/02
[#86815] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC
— Eric Wong <normalperson@...>
2018/05/02
Koichi Sasada <ko1@atdot.net> wrote:
[#86816] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC
— Koichi Sasada <ko1@...>
2018/05/02
On 2018/05/02 11:49, Eric Wong wrote:
[#86847] [Ruby trunk Bug#14732] CGI.unescape returns different instance between Ruby 2.3 and 2.4 — me@...
Issue #14732 has been reported by jnchito (Junichi Ito).
3 messages
2018/05/02
[#86860] [Ruby trunk Feature#14723] [WIP] sleepy GC — sam.saffron@...
Issue #14723 has been updated by sam.saffron (Sam Saffron).
6 messages
2018/05/03
[#86862] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC
— Eric Wong <normalperson@...>
2018/05/03
sam.saffron@gmail.com wrote:
[#86935] [Ruby trunk Bug#14742] Deadlock when autoloading different constants in the same file from multiple threads — elkenny@...
Issue #14742 has been reported by eugeneius (Eugene Kenny).
5 messages
2018/05/08
[#87030] [Ruby trunk Feature#14757] [PATCH] thread_pthread.c: enable thread caceh by default — normalperson@...
Issue #14757 has been reported by normalperson (Eric Wong).
4 messages
2018/05/15
[#87093] [Ruby trunk Feature#14767] [PATCH] gc.c: use monotonic counters for objspace_malloc_increase — ko1@...
Issue #14767 has been updated by ko1 (Koichi Sasada).
3 messages
2018/05/17
[#87095] [Ruby trunk Feature#14767] [PATCH] gc.c: use monotonic counters for objspace_malloc_increase — ko1@...
Issue #14767 has been updated by ko1 (Koichi Sasada).
9 messages
2018/05/17
[#87096] Re: [Ruby trunk Feature#14767] [PATCH] gc.c: use monotonic counters for objspace_malloc_increase
— Eric Wong <normalperson@...>
2018/05/17
ko1@atdot.net wrote:
[#87166] Re: [Ruby trunk Feature#14767] [PATCH] gc.c: use monotonic counters for objspace_malloc_increase
— Eric Wong <normalperson@...>
2018/05/18
Eric Wong <normalperson@yhbt.net> wrote:
[#87486] Re: [Ruby trunk Feature#14767] [PATCH] gc.c: use monotonic counters for objspace_malloc_increase
— Eric Wong <normalperson@...>
2018/06/13
I wrote:
[ruby-core:87201] [Ruby trunk Bug#13754] bigdecimal with lower precision that Float
From:
foldes.laszlo2@...
Date:
2018-05-20 21:16:42 UTC
List:
ruby-core #87201
Issue #13754 has been updated by karatedog (F旦ldes L叩szl坦).
That is the same problem as here: https://bugs.ruby-lang.org/issues/8826
#/ is the same method as #quo (according to documentation both methods are defined in 'bigdecimal.c' at line 1281). Currently you can divide a bigdecimal by using #/, #quo and #div but I don't really understand the design behind these methods (on a "which should do what" level).
#div accepts a precision argument, while #quo does not. Without precision argument #div returns Fixnum even if its first argument is a Float, it even returns Fixnum if both divisor and dividend are Float..
Thus far I don't know any method that could be able to calculate a division AND set the proper precision on the result. What you can do is to manually set precision by using #div. If you set the precision to the same amount as the divisor, you will not miss any significant digits, the drawback is that you will see a lot of digit repetition for most of the numbers.
(1019 is a long prime, its reciprocal has 1018 significant digits)
~~~ ruby
> BigDecimal(1).div(1019,1019).to_s
~~~
----------------------------------------
Bug #13754: bigdecimal with lower precision that Float
https://bugs.ruby-lang.org/issues/13754#change-72190
* Author: lionel_perrin (Lionel PERRIN)
* Status: Assigned
* Priority: Normal
* Assignee: mrkn (Kenta Murata)
* Target version:
* ruby -v: ruby 2.4.1p111 (2017-03-22 revision 58053) [x64-mingw32]
* Backport: 2.2: UNKNOWN, 2.3: UNKNOWN, 2.4: UNKNOWN
----------------------------------------
Hello,
I'm not sure if I've misunderstood the bigdecimal class but in the following example, I only get 12 significant digits using bigdecimal while using Float, I get a correct value with 17 significant digits.
~~~ ruby
# using floats
101/0.9163472602589686 # 110.22022368622177 (OK: floating point computation)
# using bigdecimal
a = BigDecimal('101'); a.precs # [9, 18]
b = BigDecimal('0.9163472602589686'); b.precs # [18, 27]
c = a/b; c.precs # [18, 36] (OK: I understand that c is computed with 18 significant digits)
c.to_s # "0.110220223686e3" (Mmm: I see only 12 significant digits)
c - BigDecimal('0.110220223686e3') # 0.0 (Looks like c only stores 12 significant digits and not 18)
~~~
Using the Rational class, I've seen that the value I'm expecting is about:
~~~ ruby
BigDecimal.new(Rational(101/Rational('0.9163472602589686')), 25) # 0.1102202236862217746799312e3
~~~
--
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>