[#56333] [CommonRuby - Feature #8723][Open] Array.any? predicate returns true for empty array. — "nurettin (Nurettin Onur TUGCU)" <onurtugcu@...>

12 messages 2013/08/02

[#56368] [ruby-trunk - Bug #8730][Open] "rescue Exception" rescues Timeout::ExitException — "takiuchi (Genki Takiuchi)" <genki@...21g.com>

15 messages 2013/08/04

[#56407] [ruby-trunk - misc #8741][Open] email notification on bugs.ruby-lang.org is broken — "rits (First Last)" <redmine@...>

18 messages 2013/08/05

[#56524] [ruby-trunk - Bug #8770][Open] [PATCH] process.c: avoid EINTR from Process.spawn — "normalperson (Eric Wong)" <normalperson@...>

19 messages 2013/08/10

[#56536] [ruby-trunk - Feature #8772][Open] Hash alias #| merge, and the case for Hash and Array polymorphism — "trans (Thomas Sawyer)" <redmine@...>

24 messages 2013/08/11

[#56544] [ruby-trunk - Bug #8774][Open] rb_file_dirname return wrong encoding string when dir is "." — jiayp@... (贾 延平) <jiayp@...>

10 messages 2013/08/11

[#56569] [ruby-trunk - Feature #8781][Open] Use require_relative() instead of require() if possible — "ko1 (Koichi Sasada)" <redmine@...>

31 messages 2013/08/12
[#56582] [ruby-trunk - Feature #8781] Use require_relative() instead of require() if possible — "drbrain (Eric Hodel)" <drbrain@...7.net> 2013/08/12

[#56584] Re: [ruby-trunk - Feature #8781] Use require_relative() instead of require() if possible — SASADA Koichi <ko1@...> 2013/08/12

(2013/08/13 2:25), drbrain (Eric Hodel) wrote:

[#56636] Re: [ruby-trunk - Feature #8781] Use require_relative() instead of require() if possible — Aaron Patterson <tenderlove@...> 2013/08/16

On Tue, Aug 13, 2013 at 07:38:01AM +0900, SASADA Koichi wrote:

[#56634] [ruby-trunk - Feature #8788][Open] use eventfd on newer Linux instead of pipe for timer thread — "normalperson (Eric Wong)" <normalperson@...>

11 messages 2013/08/16

[#56648] [ruby-trunk - Bug #8795][Open] "Null byte in string error" on Marshal.load — "mml (McClain Looney)" <m@...>

17 messages 2013/08/16

[#56824] [ruby-trunk - Feature #8823][Open] Run trap handler in an independent thread called "Signal thread" — "ko1 (Koichi Sasada)" <redmine@...>

14 messages 2013/08/27

[#56878] [ruby-trunk - misc #8835][Open] Introducing a semantic versioning scheme and branching policy — "knu (Akinori MUSHA)" <knu@...>

11 messages 2013/08/30

[#56890] [ruby-trunk - Feature #8839][Open] Class and module should return the class or module that was opened — "headius (Charles Nutter)" <headius@...>

26 messages 2013/08/30

[#56894] [ruby-trunk - Feature #8840][Open] Yielder#state — "marcandre (Marc-Andre Lafortune)" <ruby-core@...>

14 messages 2013/08/30

[ruby-core:56408] Re: [ruby-trunk - Feature #6083][Open] Hide a Bignum definition

From: Tanaka Akira <akr@...>
Date: 2013-08-06 01:11:02 UTC
List: ruby-core #56408
2012/2/25 Koichi Sasada <redmine@ruby-lang.org>:
> Feature #6083: Hide a Bignum definition
> https://bugs.ruby-lang.org/issues/6083
>
> Now, the struct RBignum which is a definition of Bignum in C is located in include/ruby/ruby.h.  It means we can't change implementation of Bignum.  For example, using GMP as Bignum representation.
>
> I propose to move the struct RBignum definition from include/ruby/ruby.h to bignum.c.  I believe no one use struct RBignum directly (except core).
>
> It has possibility to break binary compatibility.

I like this proposal.

However I think GMP or other multiprecision arithmetic library can be used
for slow operations such as multiplication and division
without hiding internal of struct RBignum.

The format conversion between RBignum and such library's implementation
should be O(n) (n is number of bits of the input numbers).
O(n) cost is negligible for operations slower than O(n), if input
numbers are big enough.

The conversion cost is not negligible for O(n) operations such as bitwise and.
But I doubt how such library is faster than Ruby for such operations.
-- 
Tanaka Akira
_______________________________________________
ruby-core mailing list
ruby-core@ruby-lang.org
http://lists.ruby-lang.org/cgi-bin/mailman/listinfo/ruby-core

In This Thread