August 2025 - ruby-core - ml.ruby-lang.org

[ruby-core:123036] [Ruby Feature#17316] On memoization
by Dan0042 (Daniel DeLorme) 21 Aug '25

21 Aug '25

Issue #17316 has been updated by Dan0042 (Daniel DeLorme). The single-character syntax itself isn't a problem if limited to instance variables. `foo ?=` is already valid and shouldn't change, but `@foo ?=` isn't currently valid, so it could serve as "assign if ivar undefined." The problem is consistency. All operator-equals decompose uniformly (`a += b` -> `a = a + b`) but `?=` and its variations (like `@||=`) would be very different. What should happen with cases like: ```ruby foo ?= expr foo[key] ?= expr foo.bar ?= expr ``` If that's a syntax error, it's inconsistent with other operators like `+=` or `||=`. If it means "assign if not nil", it's inconsistent with `@foo ?= expr` as "assign if undefined". And if `@foo ?= expr` is changed to mean "assign if not nil" then we're back to the nil coalescing operator which is a different topic (#13820) An operator for "assign if undefined" is appealing, but the implications don't work out cleanly. ---------------------------------------- Feature #17316: On memoization https://bugs.ruby-lang.org/issues/17316#change-114347 * Author: sawa (Tsuyoshi Sawada) * Status: Open ---------------------------------------- I have seen so many attempts to memoize a value in the form: ```ruby @foo ||= some_heavy_calculation(...) ``` improperly, i.e., even when the value can potentially be falsy. This practice is wide spread, and since in most cases memoization is about efficiency and it would not be critical if it does not work correctly, people do not seem to care so much about correcting the wrong usage. In such case, the correct form would be: ```ruby unless instance_variable_defined?(:@foo) @foo = some_heavy_calculation(...) end ``` but this looks too long, and perhaps that is keeping people away from using it. What about allowing `Kernel#instance_variable_set` to take a block instead of the second argument, in which case the assignment should be done only when the instance variable is not defined? ```ruby instance_variable_set(:@foo){some_heavy_calculation(...)} ``` Or, if that does not look right or seems to depart from the original usage of `instance_variable_set`, then what about having a new method? ```ruby memoize(:foo){some_heavy_calculation(...)} ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:117216] [Ruby master Bug#20346] FiberScheduler.unblock not called by Thread#join when Thread body contains Ractor.take
by forthoney (Seong-Heon Jung) 21 Aug '25

21 Aug '25

Issue #20346 has been reported by forthoney (Seong-Heon Jung). ---------------------------------------- Bug #20346: FiberScheduler.unblock not called by Thread#join when Thread body contains Ractor.take https://bugs.ruby-lang.org/issues/20346 * Author: forthoney (Seong-Heon Jung) * Status: Open * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- When using a `Ractor.take` inside a different thread, `Thread#join` on the thread running `Ractor.take` fails to call `FiberScheduler.unblock`. The below code can replicate this behavior ```ruby require "async" class RactorWrapper def initialize @ractor = Ractor.new do Ractor.recv # Ractor doesn't start until explicitly told to # Do some calculations fib = ->(x) { x < 2 ? 1 : fib.call(x - 1) + fib.call(x - 2) } fib.call(20) end end def take_async @ractor.send(nil) Thread.new { @ractor.take }.join.value end end Async do |task| 10000.times do |i| task.async do RactorWrapper.new.take_async puts i end end end ``` The above code deadlocks, and when we leave a debugging print statement inside of `Async`'s scheduler's `block` and `unblock` method, we can confirm that we only call `Scheduler.block`, and never `Scheduler.unblock` -- https://bugs.ruby-lang.org/

4 3

[ruby-core:112206] [Ruby master Bug#19407] 2 threads taking from current ractor will hang forever
by luke-gru (Luke Gruber) 21 Aug '25

21 Aug '25

Issue #19407 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #19407: 2 threads taking from current ractor will hang forever https://bugs.ruby-lang.org/issues/19407 * Author: luke-gru (Luke Gruber) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- In the current implementation of Ractors, it's possible to `take` from the current ractor. This could be useful when co-ordinating threads: ```ruby t = Thread.new do obj = Ractor.current.take p obj # do some work with obj end t0 = Thread.new do obj = Ractor.current.take p obj # do some work with obj end Ractor.yield :go ``` However it hangs forever: ```ruby t = Thread.new do obj = Ractor.current.take p obj end t0 = Thread.new do obj = Ractor.current.take p obj end sleep 0.5 ``` Should "self-take" be disabled, or was it designed to allow it but this is just a bug? -- https://bugs.ruby-lang.org/

3 2

[ruby-core:123030] [Ruby Feature#17316] On memoization
by matz (Yukihiro Matsumoto) 21 Aug '25

21 Aug '25

Issue #17316 has been updated by matz (Yukihiro Matsumoto). Currently, `?=` means "a single character =". We don't want to break current available syntax, unless absolutely necessary. Matz. ---------------------------------------- Feature #17316: On memoization https://bugs.ruby-lang.org/issues/17316#change-114340 * Author: sawa (Tsuyoshi Sawada) * Status: Open ---------------------------------------- I have seen so many attempts to memoize a value in the form: ```ruby @foo ||= some_heavy_calculation(...) ``` improperly, i.e., even when the value can potentially be falsy. This practice is wide spread, and since in most cases memoization is about efficiency and it would not be critical if it does not work correctly, people do not seem to care so much about correcting the wrong usage. In such case, the correct form would be: ```ruby unless instance_variable_defined?(:@foo) @foo = some_heavy_calculation(...) end ``` but this looks too long, and perhaps that is keeping people away from using it. What about allowing `Kernel#instance_variable_set` to take a block instead of the second argument, in which case the assignment should be done only when the instance variable is not defined? ```ruby instance_variable_set(:@foo){some_heavy_calculation(...)} ``` Or, if that does not look right or seems to depart from the original usage of `instance_variable_set`, then what about having a new method? ```ruby memoize(:foo){some_heavy_calculation(...)} ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:123028] [Ruby Feature#17316] On memoization
by matheusrich (Matheus Richard) 21 Aug '25

21 Aug '25

Issue #17316 has been updated by matheusrich (Matheus Richard). @matz I propose `?=` as the uninitialized assignment operator: ```rb @foo ?= some_heavy_calculation(...) ``` ---------------------------------------- Feature #17316: On memoization https://bugs.ruby-lang.org/issues/17316#change-114338 * Author: sawa (Tsuyoshi Sawada) * Status: Open ---------------------------------------- I have seen so many attempts to memoize a value in the form: ```ruby @foo ||= some_heavy_calculation(...) ``` improperly, i.e., even when the value can potentially be falsy. This practice is wide spread, and since in most cases memoization is about efficiency and it would not be critical if it does not work correctly, people do not seem to care so much about correcting the wrong usage. In such case, the correct form would be: ```ruby unless instance_variable_defined?(:@foo) @foo = some_heavy_calculation(...) end ``` but this looks too long, and perhaps that is keeping people away from using it. What about allowing `Kernel#instance_variable_set` to take a block instead of the second argument, in which case the assignment should be done only when the instance variable is not defined? ```ruby instance_variable_set(:@foo){some_heavy_calculation(...)} ``` Or, if that does not look right or seems to depart from the original usage of `instance_variable_set`, then what about having a new method? ```ruby memoize(:foo){some_heavy_calculation(...)} ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:122987] [Ruby Bug#21547] SEGV after 2083fa commit
by watson1978 (Shizuo Fujita) 21 Aug '25

21 Aug '25

Issue #21547 has been reported by watson1978 (Shizuo Fujita). ---------------------------------------- Bug #21547: SEGV after 2083fa commit https://bugs.ruby-lang.org/issues/21547 * Author: watson1978 (Shizuo Fujita) * Status: Open * Target version: 3.5 * ruby -v: ruby 3.5.0dev (2025-08-13T17:54:56Z master 2083fa89fc) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I am maintaining [Fluentd](https://github.com/fluent/fluentd). When I run Fluentd's unit tests after [2083fa](https://github.com/ruby/ruby/commit/2083fa89fc29005035c1a098185c4b7… commit, Ruby causes SEGV. ``` $ git clone --depth 1 https://github.com/fluent/fluentd.git $ cd fluentd $ bundle install $ ruby -v ruby 3.5.0dev (2025-08-13T17:54:56Z master 2083fa89fc) +PRISM [x86_64-linux] $ bundle exec rake test TESTOPTS=-v TEST=test/plugin/test_in_exec.rb Source locally installed gems is ignoring #<Bundler::StubSpecification name=json version=2.13.2 platform=ruby> because it is missing extensions /home/watson/.rbenv/versions/3.5-debug/bin/ruby -w -I"lib:test" -Eascii-8bit:ascii-8bit /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/rake-13.3.0/lib/rake/rake_test_loader.rb "test/plugin/test_in_exec.rb" -v Source locally installed gems is ignoring #<Bundler::StubSpecification name=json version=2.13.2 platform=ruby> because it is missing extensions /home/watson/tmp/fluentd/test/plugin/test_in_exec.rb:240: warning: assigned but unused variable - tag /home/watson/tmp/fluentd/test/plugin/test_in_exec.rb:240: warning: assigned but unused variable - time /home/watson/tmp/fluentd/test/plugin/test_in_exec.rb:246: warning: assigned but unused variable - d /home/watson/tmp/fluentd/lib/fluent/plugin_helper.rb:46: warning: method redefined; discarding old inherited /home/watson/tmp/fluentd/lib/fluent/plugin_helper.rb:46: warning: previous definition of inherited was here Loaded suite /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/rake-13.3.0/lib/rake/rake_test_loader Started ExecInputTest: test: emit error message with read_with_stderr: .: (0.229405) test: emit with formats[default]: .: (0.908338) test: emit with formats[json]: .: (0.809623) test: emit with formats[msgpack]: /home/watson/tmp/fluentd/lib/fluent/plugin_helper/event_loop.rb:105: [BUG] Segmentation fault at 0x0000000000000024 ruby 3.5.0dev (2025-08-13T17:54:56Z master 2083fa89fc) +PRISM [x86_64-linux] -- Control frame information ----------------------------------------------- c:0054 p:---- s:0316 e:000315 CFUNC :detach c:0053 p:---- s:0313 e:000312 CFUNC :detach c:0052 p:0012 s:0309 e:000308 BLOCK /home/watson/tmp/fluentd/lib/fluent/plugin_helper/event_loop.rb:105 [FINISH] c:0051 p:---- s:0304 e:000303 CFUNC :reverse_each c:0050 p:0006 s:0300 e:000299 BLOCK /home/watson/tmp/fluentd/lib/fluent/plugin_helper/event_loop.rb:102 [FINISH] c:0049 p:---- s:0297 e:000296 CFUNC :synchronize c:0048 p:0006 s:0293 e:000292 METHOD /home/watson/tmp/fluentd/lib/fluent/plugin_helper/event_loop.rb:101 c:0047 p:0014 s:0289 e:000288 METHOD /home/watson/tmp/fluentd/lib/fluent/plugin_helper/child_process.rb:149 c:0046 p:0011 s:0283 e:000282 METHOD /home/watson/tmp/fluentd/lib/fluent/plugin_helper/parser.rb:126 c:0045 p:0016 s:0279 e:000278 BLOCK /home/watson/tmp/fluentd/lib/fluent/test/driver/base.rb:161 c:0044 p:0005 s:0276 e:000275 BLOCK /home/watson/tmp/fluentd/lib/fluent/test/driver/base.rb:150 c:0043 p:0064 s:0270 E:001588 METHOD /home/watson/tmp/fluentd/lib/fluent/test/driver/base.rb:161 c:0042 p:0123 s:0263 E:0022e0 METHOD /home/watson/tmp/fluentd/lib/fluent/test/driver/base.rb:100 c:0041 p:0045 s:0250 E:0003a8 METHOD /home/watson/tmp/fluentd/lib/fluent/test/driver/base_owner.rb:130 c:0040 p:0028 s:0239 e:000238 BLOCK /home/watson/tmp/fluentd/test/plugin/test_in_exec.rb:272 c:0039 p:0131 s:0229 e:000228 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/testcase.rb:911 c:0038 p:0003 s:0221 e:000220 BLOCK /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/testcase.rb:601 c:0037 p:0024 s:0218 e:000217 BLOCK /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/fixture.rb:276 c:0036 p:0024 s:0214 e:000213 BLOCK /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/fixture.rb:276 c:0035 p:0024 s:0210 e:000209 BLOCK /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/fixture.rb:276 c:0034 p:0052 s:0206 e:000205 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/fixture.rb:257 c:0033 p:0009 s:0197 e:000196 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/fixture.rb:292 c:0032 p:0004 s:0192 E:000318 BLOCK /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/testcase.rb:599 [FINISH] c:0031 p:---- s:0188 e:000187 CFUNC :catch c:0030 p:0046 s:0184 E:001d78 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/testcase.rb:598 c:0029 p:0045 s:0175 E:001730 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/test-suite-runner.rb:96 c:0028 p:0013 s:0163 e:000162 BLOCK /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/test-suite-runner.rb:62 [FINISH] c:0027 p:---- s:0159 e:000158 CFUNC :each c:0026 p:0009 s:0155 e:000154 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/test-suite-runner.rb:61 c:0025 p:0037 s:0147 e:000146 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/test-suite-runner.rb:39 c:0024 p:0030 s:0139 E:000ce8 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/testsuite.rb:56 c:0023 p:0045 s:0130 E:000090 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/test-suite-runner.rb:96 c:0022 p:0013 s:0118 e:000117 BLOCK /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/test-suite-runner.rb:62 [FINISH] c:0021 p:---- s:0114 e:000113 CFUNC :each c:0020 p:0009 s:0110 e:000109 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/test-suite-runner.rb:61 c:0019 p:0037 s:0102 e:000101 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/test-suite-runner.rb:39 c:0018 p:0030 s:0094 E:001318 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/testsuite.rb:56 c:0017 p:0028 s:0085 E:0015a0 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/ui/testrunnermediator.rb:72 c:0016 p:0041 s:0079 e:000078 BLOCK /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/ui/testrunnermediator.rb:49 [FINISH] c:0015 p:---- s:0075 e:000074 CFUNC :catch c:0014 p:0004 s:0071 e:000070 BLOCK /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/ui/testrunnermediator.rb:44 c:0013 p:0008 s:0067 e:000066 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/test-suite-runner.rb:19 c:0012 p:0006 s:0063 e:000062 BLOCK /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/ui/testrunnermediator.rb:43 c:0011 p:0038 s:0060 E:002668 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/ui/testrunnermediator.rb:107 c:0010 p:0033 s:0051 E:000d78 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/ui/testrunnermediator.rb:42 c:0009 p:0006 s:0044 e:000043 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/ui/testrunner.rb:40 c:0008 p:0019 s:0040 e:000039 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/ui/testrunner.rb:25 c:0007 p:0015 s:0036 e:000035 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/ui/testrunnerutilities.rb:24 c:0006 p:0010 s:0030 e:000029 BLOCK /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/autorunner.rb:499 c:0005 p:0019 s:0027 e:000026 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/autorunner.rb:564 c:0004 p:0182 s:0022 e:000021 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/autorunner.rb:498 c:0003 p:0057 s:0016 e:000015 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/autorunner.rb:68 c:0002 p:0017 s:0007 e:000005 BLOCK /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit.rb:518 [FINISH] c:0001 p:0000 s:0003 E:000410 DUMMY [FINISH] ...(snip)... ``` -- https://bugs.ruby-lang.org/

3 9

[ruby-core:123013] [Ruby Feature#12282] Hash#dig! for repeated applications of Hash#fetch
by matz (Yukihiro Matsumoto) 21 Aug '25

21 Aug '25

Issue #12282 has been updated by matz (Yukihiro Matsumoto). `fetch_path` is much better than `dig!` since this bang method is against our naming convention (if we have x and x!, a method with `!` (bang) should be more dangerous). At the same time, `_path` usually means file paths in Ruby, and possibly cause confusion, although **I** understand `path` here is totally valid. Matz. ---------------------------------------- Feature #12282: Hash#dig! for repeated applications of Hash#fetch https://bugs.ruby-lang.org/issues/12282#change-114317 * Author: robb (Robb Shecter) * Status: Open ---------------------------------------- A new feature for your consideration: #dig! which is to #fetch as #dig is to #[]. For me and maybe many others, Hash#fetch is used much more than Hash#[]. And traversing multiple fetches isn't very convenient nor Ruby-like, e.g.: places.fetch(:countries).fetch(:canada).fetch(ontario). Here's how it would work: ~~~ruby places = { countries: { canada: true } } places.dig :countries, :canada # => true places.dig! :countries, :canada # => true places.dig :countries, :canada, :ontario # => nil places.dig! :countries, :canada, :ontario # => KeyError: Key not found: :ontario ~~~ Here's an implementation and tests: https://gist.github.com/dogweather/819ccdb41c9db0514c163cfdb1c528e2 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:123006] [Ruby Feature#17316] On memoization
by matz (Yukihiro Matsumoto) 21 Aug '25

21 Aug '25

Issue #17316 has been updated by matz (Yukihiro Matsumoto). I understand the motivation, but the proposed "@||=" is unacceptable. Other suggestions were made, but I don't think any of them adequately express the intent. If there are no good operator name suggestions in the future, it would be better to explicitly use `defined?`. Matz. ---------------------------------------- Feature #17316: On memoization https://bugs.ruby-lang.org/issues/17316#change-114308 * Author: sawa (Tsuyoshi Sawada) * Status: Open ---------------------------------------- I have seen so many attempts to memoize a value in the form: ```ruby @foo ||= some_heavy_calculation(...) ``` improperly, i.e., even when the value can potentially be falsy. This practice is wide spread, and since in most cases memoization is about efficiency and it would not be critical if it does not work correctly, people do not seem to care so much about correcting the wrong usage. In such case, the correct form would be: ```ruby unless instance_variable_defined?(:@foo) @foo = some_heavy_calculation(...) end ``` but this looks too long, and perhaps that is keeping people away from using it. What about allowing `Kernel#instance_variable_set` to take a block instead of the second argument, in which case the assignment should be done only when the instance variable is not defined? ```ruby instance_variable_set(:@foo){some_heavy_calculation(...)} ``` Or, if that does not look right or seems to depart from the original usage of `instance_variable_set`, then what about having a new method? ```ruby memoize(:foo){some_heavy_calculation(...)} ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:122898] [Ruby Feature#21527] Proposal: Math.log1p and Math.expm1
by mame (Yusuke Endoh) 21 Aug '25

21 Aug '25

Issue #21527 has been reported by mame (Yusuke Endoh). ---------------------------------------- Feature #21527: Proposal: Math.log1p and Math.expm1 https://bugs.ruby-lang.org/issues/21527 * Author: mame (Yusuke Endoh) * Status: Open ---------------------------------------- Let's add `Math.log1p` and `Math.expm1`. * `Math.log1p(x)`: Computes `Math.log(x + 1)` * `Math.expm1(x)`: Computes `Math.exp(x) - 1` These methods are often more accurate than the straightforward computation, especially when `x` is close to zero. ``` # The current approach loses precision p Math.log(1 + 1.0e-16) #=> 0.0 p Math.exp(1.0e-16) - 1 #=> 0.0 # The proposed methods return the accurate result p Math.log1p(1.0e-16) #=> 1.0e-16 p Math.expm1(1.0e-16) #=> 1.0e-16 ``` Note that they are very standard; the C99 even defines `log1p()` and `expm1()`. Other major programming languages (Python, JavaScript, Java, Go, Rust, etc.) also provide them. PR: https://github.com/ruby/ruby/pull/14087 -- https://bugs.ruby-lang.org/

3 4

[ruby-core:122993] subscription alert
by NetfIix 20 Aug '25

20 Aug '25

1 0