On Fri, Aug 14, 2015 at 6:08 PM, <20100.delecr...@gmail.com> wrote:
>
> Pull request for a new function mpq_cmp_mpz at
> https://github.com/wbhart/mpir/pull/157
>
> It is essentially a copy/paste of mpq_cmp with a lot of simplification since
> one denominator is just one.
A minor suggestion
On Fri, Jan 17, 2014 at 12:00 PM, Bill Hart wrote:
> Hi all,
>
> as many of you know, I've been planning my time well in advance for some
> time now. This helps with productivity and with general well-being.
>
> To that end, you will find my current schedule below, followed by a
> discussion of ai
On Wed, Oct 23, 2013 at 4:17 PM, Bill Hart wrote:
> I have made a number of speedups to the precomputed inverse code I announced
> earlier, and removed two unneeeded functions. It is now up to 20% faster
> than ordinary 2n x n division for n = 1 limb and from n = 3-15 limbs and up
> to 2.2 times a
On Tue, Apr 16, 2013 at 4:51 PM, Burcin Erocal wrote:
> On Tue, 16 Apr 2013 15:26:53 +0100
> Bill Hart wrote:
>
> > I can imagine there being a kind of p-adic algorithm for this. Could
> > this be what Burcin is referring to? I am not aware of references for
> > such an algorithm though. Perhaps
On Fri, Mar 29, 2013 at 7:38 PM, Bill Hart wrote:
> So the conclusion is very clear. Even though my division basecase is
> slightly slower in BSDNT, the BSDNT divconquer code ends up being
> nearly twice as fast as MPIR!
>
Could you show the ratios for 2n by n division versus n by n multiplicatio
On Fri, Mar 29, 2013 at 7:38 PM, Bill Hart wrote:
> So the conclusion is very clear. Even though my division basecase is
> slightly slower in BSDNT, the BSDNT divconquer code ends up being
> nearly twice as fast as MPIR!
>
That's quite amazing! If it turns out to be nearly as much an improvement
On Sat, Mar 9, 2013 at 7:52 PM, Bill Hart wrote:
> Thanks. We'll put that patch in at the next release.
>
> Does 3x seem to be optimal?
>
I don't know if it's optimal, but it seems reasonable (if the FFT threshold
is assumed to be accurate for balanced multiplication). It should be ok
since I'm n
On Sat, Mar 9, 2013 at 4:35 PM, Bill Hart wrote:
> OK, well I'll add this to the long MPIR todo list.
>
> When we next update MPIR we'll attempt to find a robust patch for this.
I just changed the FFT threshold test in mpn/generic/mul.c to
if (ABOVE_THRESHOLD (un + vn, 2*MUL_FFT_FULL_THRESHOLD
On Sat, Mar 9, 2013 at 4:03 PM, Bill Hart wrote:
> In theory, the FFT should handle very unbalance operands just fine.
> But as you can see it is a matter of tuning at some points.
>
> Obviously we should be using something else at this size.
>
> The right way to handle really unbalanced operands
There seems to be a pretty serious tuning issue with (highly)
unbalanced multiplication in mpir-2.6.0:
38 x 1400 bits takes 155 us
39 x 1400 bits takes 895 us
This is with
model name : Intel(R) Xeon(R) CPU X5675 @ 3.07GHz
and
gmp-mparam.h -> mpn/x86_64/nehalem/westm
On Fri, Nov 2, 2012 at 12:06 AM, Bill Hart wrote:
> Dear all,
>
> I am sorry to report that Jason Moxham, long time contributor and for
> some years, maintainer of MPIR, has passed away. I just received this
> sad news from his family.
>
> Jason was an extremely talented assembly language develope
On Wed, Oct 17, 2012 at 8:57 PM, Bill Hart wrote:
> It's so long since I looked at this, I don't remember. But I had
> thought it was because these functions were not universally exported
> in mpir.
>
> If they are macros in flint, then I don't see the problem anyway. They
> don't get exported as
On Wed, Oct 17, 2012 at 8:31 PM, Bill Hart wrote:
> On 17 October 2012 19:04, Fredrik Johansson
> wrote:
>> On Wed, Oct 17, 2012 at 6:10 PM, Bill Hart
>> wrote:
>>> Hi all,
>>>
>>> I am just working on the release of MPIR 2.6.0 and it has been
On Wed, Oct 17, 2012 at 6:10 PM, Bill Hart wrote:
> Hi all,
>
> I am just working on the release of MPIR 2.6.0 and it has been noted
> (by Fredrik I think) that there are symbol clashes between the two
> libraries. This is not in general a problem if the library order is
> correct, but the mistake
On Tue, Oct 9, 2012 at 10:02 AM, Jean-Pierre Flori wrote:
>
>
> On Tuesday, October 9, 2012 8:29:03 AM UTC+2, Fredrik Johansson wrote:
>>
>>
>> I found that I could get the right versions by compiling code with
>> -lflint -lmpir and not the other way aroun
Hello,
I've just found out that there are namespace collisions between
FLINT's ulong_extras module and some internal MPIR functions with an
"n_" prefix defined in likely_prime_p.c. This wouldn't cause too much
problem if the functions were equivalent, but unfortunately, the MPIR
functions don't se
On Sun, Aug 21, 2011 at 5:37 PM, David Cleaver wrote:
> Hello all,
>
> Not too long ago I needed some mathematical functions that I couldn't really
> find implemented anywhere. I eventually stumbled on someone's
> implementation and was able to code it up with GMP. I was wondering, would
> there
Hi,
Valgrind revealed another possible error, in mpz_gcd, occurring for
specific inputs. In this case both operands have exactly size ==
alloc, and the second operand has exactly 64 trailing zero bits (this
is probably significant).
This is as before with MPIR 2.1.1 on a Pentium T4400, 64 bit Ubu
Hi,
On my system, valgrind detects an invalid read in mpn_mul when the
operands have certain sizes. For example, it happens when both operand
lengths are 2601 limbs. I'm attaching a test .c program and valgrind
output.
I just re-ran "make check" to be sure no MPIR tests were failing.
System is an
On Thu, Jul 8, 2010 at 5:24 PM, Jason Moxham wrote:
>
> maybe , I would have to look it up , basically mulhi goes like this
>
> calculate mul_short (either basecase or divide and conquer)
> mul_short is like mul_high but with 2 extra digits calculated , these 2
> extra
> digits give enough info t
On Thu, Jul 8, 2010 at 4:51 PM, Jason Moxham wrote:
>
> The mulhi and mullo are exact unlike the mulmid , we could do an
> approximate
> mulhi which would be marginally faster.
>
> Jason
>
Yes, that would be very nice. I assume approximate mulhi would be give the
exact result +/- 1?
Fredrik
--
On Wed, Jul 7, 2010 at 11:36 PM, Jason Moxham wrote:
> On Tuesday 06 July 2010 10:49:35 Bill Hart wrote:
> > Frederick is working on mpz_mulhi, however one thing we *really* need
> > (since the interesting case for his applications is for a small number
> > of limbs) is an x86_64 assembly version
Since Bill asked...
* "short" integer multiplication
* fmpz style mpzs (an alternative project would be to switch Sage
Integers over to fmpz without modifying MPIR... is FLINT2 ready for
such a thing?)
Maybe I'll think of some other things later...
Fredrik
--
You received this message because
Hi,
What is the best way to scan an mpz for 1s or 0s in the direction towards
less significant bits (mpz_scan0, mpz_scan1 scan towards more significant
bits)?
Would it be possible to add functions to MPIR for this?
Fredrik
--
You received this message because you are subscribed to the Google G
On Thu, Oct 15, 2009 at 7:34 PM, Jason Moxham wrote:
>
> - Original Message -
> From: "Fredrik Johansson"
> To:
> Sent: Thursday, October 15, 2009 7:01 AM
> Subject: [mpir-devel] Function requests
>
>
>>
>> Hi all,
>>
>> I
Hi all,
I'm currently looking for fast ways to sum exponential-type Taylor
series in fixed point arithmetic using mpz (see
http://code.google.com/p/fastfunlib/)). I'm mainly interested in low
precision (say a few hundred or thousand bits), so I don't think
binary splitting is worthwhile (but I co
On Sat, Jun 6, 2009 at 4:11 PM, Jason Moxham wrote:
> Looking at the existing toom code there are a lot of
> mpn_addmul_1(,2^k)
> we should change this to
> mpn_addlsh_n(,k)
> and write asm functions for this , for K8 this would be a macro to call
> addmul_1 , and for core2,K10 a new func
27 matches
Mail list logo
