[#2748] Proposal: New Bignum — "Evan Webb" <evan@...>
During some experiments with ruby cryptography, I found some problems with
11 messages
2004/04/06
[#2749] Re: Proposal: New Bignum
— matz@... (Yukihiro Matsumoto)
2004/04/06
Hi,
[#2764] RDoc :enddoc: — Tanaka Akira <akr@...17n.org>
I found that RDoc document some method after :enddoc:. Is it
7 messages
2004/04/10
[#2788] Problems building ext/io/wait.c in 1.8 branch — Gavin Sinclair <gsinclair@...>
I can't get io/wait installed. The main problem is that it doesn't
6 messages
2004/04/17
[#2799] Re: Problems building ext/io/wait.c in 1.8 branch
— Gavin Sinclair <gsinclair@...>
2004/04/21
On Saturday, April 17, 2004, 4:42:14 PM, Gavin wrote:
[#2800] Re: Problems building ext/io/wait.c in 1.8 branch
— ts <decoux@...>
2004/04/21
>>>>> "G" == Gavin Sinclair <gsinclair@soyabean.com.au> writes:
[#2801] Re: Problems building ext/io/wait.c in 1.8 branch
— Gavin Sinclair <gsinclair@...>
2004/04/21
On Thursday, April 22, 2004, 1:21:29 AM, ts wrote:
[#2805] Bug 1318 — Steven Jenkins <steven.jenkins@...>
Any comments on
9 messages
2004/04/23
[#2814] Tempfile strangeness in 1.9.0 — Steven Jenkins <steven.jenkins@...>
I didn't open a bug for this because it's from the CVS head, but it
5 messages
2004/04/24
Re: Proposal: New Bignum
From:
"Evan Webb" <evan@...>
Date:
2004-04-06 17:58:55 UTC
List:
ruby-core #2756
I believe that Matz concern is centered around where autoconversion between types would yield objects of an unexpected type, and thus certain operations would not behave the same and/or wouldn't be present. Here's an example: m.class # MBignum n.class # MBignum i = m - n # i == 1; i.class == Fixnum i.exptmod(e,p) # raises UnknownMethod This assumes current conversion rules, that any operation on Bignum's that yields a result of less then the Fixnum threshold is down converted into a Fixnum. In the current implementation, MBignum's do not do auto conversion, thus the in the above example, i would be a MBignum even if it's value is 1. I think of this as the preserve-type model. My suggestion is that we use the preserve-type model wherever possible, but it is most likely what the programmer is expecting. And then with some nice use of coerce, we can actually provide the same functionality as the auto-convert, but we do it at requested operation time. In other words, if we return to my above example, say that we are using the preserve-model, so the above example works as expected, but we add j = 2 * i As the next statement. Here we see that the a Fixnum is trying to be multiplied by a MBignum. Here's where coerce comes into play. The MBignum is asked to 'become' a Fixnum, and because it is less then the Fixnum threshold, it does. Thus the result j is a Fixnum. In addition, anywhere in the code that requests a Fixnum can be wrapped to do the same coercion, for example, in NUM2INT. A benefit to this is that it's more likely that the programmer receives the type of object they expect back from an operation. Evan M. Webb // evan@fallingsnow.net > -----Original Message----- > From: Eivind Eklund [mailto:eivind@FreeBSD.org] > Sent: Tuesday, April 06, 2004 7:12 AM > To: ruby-core@ruby-lang.org > Subject: Re: Proposal: New Bignum > > On Tue, Apr 06, 2004 at 04:18:10PM +0900, Yukihiro Matsumoto wrote: > > I'm not sure whether replacing current bignum is a good idea. The > > integer values in Ruby go back and forth between Fixnum and Bignum > > according to its value range, which might not be a desired behavior > > for cryptogram calculation etc. > > Why would this be a problem for cryptography? (I'm probably being > stupid here...) > > Eivind.