Just FYI, there is very little performance gain in using MPFR for a
tiny number of bits compared to, say, a default of 60 (because the
underlying data still fits inside a single word). I'm almost certain
calculating the exact precision would be more expensive than using a
reasonable default
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Wait, it gets even better! We can actually get a fairly good
estimate on the precision we need, on-the-fly.
Suppose we are given the integer x. If the base is 2, then
the amount of precision we need is
prec=sizeinbase(sizeinbase(x,2),2)
or some
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
OK, that's what I was wondering about. An integer with 2^53 binary
digits eats up 1024 terabytes,
so it's gonna be a while before we run into trouble. Besides, we
could have an optional precision
argument that defaults to 53 at the moment, but can b
On Jan 28, 2008, at 11:05 PM, Alex Ghitza wrote:
Robert Bradshaw wrote:
I'm not a fan of the (seemingly arbitrary) 256 limit. Real
intervals have been suggested, why not do something like
def exact_log(x, base=10): x = abs(x) approx = floor(RIF(x).log() /
RIF(base).log()) min, max = int(approx
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robert Bradshaw wrote:
> I'm not a fan of the (seemingly arbitrary) 256 limit. Real
> intervals have been suggested, why not do something like
>
> def exact_log(x, base=10): x = abs(x) approx = floor(RIF(x).log() /
> RIF(base).log()) min, max = int(ap
On Jan 28, 2008, at 6:31 PM, David Harvey wrote:
> On Jan 28, 2008, at 6:47 PM, Alex Ghitza wrote:
>
>> OK, I'm quite happy with this (thanks David for suggesting it
>> and Carl for telling me how to do it!)
>>
>> I've put this in and played around with it. It is definitely
>> *much* faster for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Fair enough. One could try to modify mpz_sizeinbase to accept
larger bases, although I'm not sure how easy it would be to
make it work with *arbitrary* bases. Anyway, this is a bit more
involved than what I'm willing to try now. It's definitely
som
On Jan 28, 2008, at 6:47 PM, Alex Ghitza wrote:
> OK, I'm quite happy with this (thanks David for suggesting it
> and Carl for telling me how to do it!)
>
> I've put this in and played around with it. It is definitely
> *much* faster for the huge examples that I tried, and it's
> also fast enou
On Jan 28, 3:47 pm, Alex Ghitza <[EMAIL PROTECTED]> wrote:
> I'll post a new patch for #1014 shortly. David, is it ok if I
> replace the current exact_log() function with
>
> return self.ndigits(m) - 1
>
> (after checking self is positive, etc.)?
It looks like mpz_sizeinbase() only works for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
OK, I'm quite happy with this (thanks David for suggesting it
and Carl for telling me how to do it!)
I've put this in and played around with it. It is definitely
*much* faster for the huge examples that I tried, and it's
also fast enough on smaller
On Jan 27, 8:14 pm, David Harvey <[EMAIL PROTECTED]> wrote:
> On Jan 27, 2008, at 10:55 PM, David Harvey wrote:
>
> >> We actually know what the first few digits (or, actually, all of
> >> them)
> >> of *compare* are: 1000...
>
> > Sorry, you're right, I wasn't very coherent.
>
> > What I thin
On Jan 28, 5:14 am, David Harvey <[EMAIL PROTECTED]> wrote:
>
> (and is this is a bug:
>
> sage: I**10
> [2.0985787164673874e323228496 .. +infinity]
I don't think so, just a blowup of interval enclosures + an overflow
in the exponent. afaik mpfi has a limit in the exponent (should chang
On Jan 27, 2008, at 10:55 PM, David Harvey wrote:
>> We actually know what the first few digits (or, actually, all of
>> them)
>> of *compare* are: 1000...
>
> Sorry, you're right, I wasn't very coherent.
>
> What I think I meant was to quickly compute the top few *binary*
> digits of "com
On Jan 27, 2008, at 10:44 PM, Alex Ghitza wrote:
> David's suggestion was:
> - -
> * instead of computing the whole power, just estimate the top
> couple of
> digits using MPFR (much much much faster than computing the whole
> power)
> * keep increasing precision until we ca
14 matches
Mail list logo
