Certainly the code is available by svn.
2010/1/5 Case Vanhorsen :
> On Tue, Jan 5, 2010 at 12:26 PM, Cactus wrote:
>>
>>
>> On Jan 5, 8:03 pm, Bill Hart wrote:
>>> Excellent work Brian!
>>
>> I hope Case will see whether these changes have had any impact on his
>> memory allocation dicovery and
On Tue, Jan 5, 2010 at 12:26 PM, Cactus wrote:
>
>
> On Jan 5, 8:03 pm, Bill Hart wrote:
>> Excellent work Brian!
>
> I hope Case will see whether these changes have had any impact on his
> memory allocation dicovery and his bug.
>
> The change to alloca makes some things faster and others slower
On Jan 5, 8:03 pm, Bill Hart wrote:
> Excellent work Brian!
I hope Case will see whether these changes have had any impact on his
memory allocation dicovery and his bug.
The change to alloca makes some things faster and others slower :-(
Brian
--
You received this message because you are
Of course. As making a release candidate is currently very difficult
and slow, I will wait until we have a few things to include.
Bill.
2010/1/5 Cactus :
>
>
> On Jan 5, 6:34 pm, Bill Hart wrote:
>> After persisting for some hours, I managed to manually fix all the
>> errors in the Makefiles whi
HP has apparently tried to patent what looks to me (the description is
too vague to be sure) like breaking decimal numbers up into chunks
which fit into words.
http://www.wikipatents.com/7523150.html-1
Anyhow, there is an article on slashdot that the GMP authors were
invited to comment on the pat
On Jan 5, 6:34 pm, Bill Hart wrote:
> After persisting for some hours, I managed to manually fix all the
> errors in the Makefiles which autotools spews out, and thus I have
> cobbled together a new rc4 for testing. I did check it does actually
> build and pass make check on at least one machine
Excellent work Brian!
Bill.
2010/1/5 Cactus :
>
>
> On Jan 5, 7:11 pm, Bill Hart wrote:
>> I doubt it. In the test code you have:
>>
>> ASSERT_ALWAYS (putc ((size >> (j*8)) & 0xFF, fp) != EOF);
>>
>> should that 0xFF be 0xFFLL or something like that on Windows?
>
> I found the bug - its in lines
On Jan 5, 7:11 pm, Bill Hart wrote:
> I doubt it. In the test code you have:
>
> ASSERT_ALWAYS (putc ((size >> (j*8)) & 0xFF, fp) != EOF);
>
> should that 0xFF be 0xFFLL or something like that on Windows?
I found the bug - its in lines 80-82 in inp_raw.c
if (sizeof (csize) > 4 && csize & 0x8
I doubt it. In the test code you have:
ASSERT_ALWAYS (putc ((size >> (j*8)) & 0xFF, fp) != EOF);
should that 0xFF be 0xFFLL or something like that on Windows?
Bill.
2010/1/5 Cactus :
>
>
> On Jan 5, 8:10 am, Cactus wrote:
>> On Jan 4, 8:02 pm, Cactus wrote:
>>
>> > On Jan 4, 6:56 pm, Bill Har
On Jan 5, 8:10 am, Cactus wrote:
> On Jan 4, 8:02 pm, Cactus wrote:
>
> > On Jan 4, 6:56 pm, Bill Hart wrote:
>
> > > It looks like we have the following in mpir.h:
>
> > > #if defined (_CRAY) && ! defined (_CRAYMPP)
> > > /* plain `int' is much faster (48 bits) */
> > > #define __GMP_MP_SIZE_
After persisting for some hours, I managed to manually fix all the
errors in the Makefiles which autotools spews out, and thus I have
cobbled together a new rc4 for testing. I did check it does actually
build and pass make check on at least one machine!
Note that tickets #270, #271 and #272 have n
David Kirkby reported a bug on Solaris related to using stlport4 which
is a newer version of their library. It's our trac ticket #272.
A few days ago, whilst investigating this, I found the following from
Marc Glisse on the gmp mailing list which seems to be a comment
directed at us
http://gm
David Kirkby has pointed out that MPIR currently doesn't build on his
HP-UX machine.
Does anyone have one of these and would you like to work on getting it
going on HP-UX?
I think it used to at least nearly work on that platform (I seem to
remember testing on some HP testdrive machine way back),
2010/1/5 Cactus :
>
>
> On Jan 5, 12:27 pm, Bill Hart wrote:
>> I assume this is on 64 bit Windows? I'll open a ticket.
>>
>> #273
>
> I have solved it - the count leading/trailing zeroes macros on Windows
> were unsafe to use with long long result types (its the 32/64 bit int
> issue).
>
> I real
I tried the (2^{3B}+1) = (2^B + 1)(2^{2B}-2^B+1) trick. It works
relatively well for small multiplications. So here are the new timings
for the range of numbers affected.
519168/1: 29.5s / 33.9s (14.9%)
584064/1: 32.0 / 34.1s (6.6%)
648960/1000: 3.7s / 3.9s (5.4%)
713856/1000: 4.0s / 4.3s
On Jan 5, 12:27 pm, Bill Hart wrote:
> I assume this is on 64 bit Windows? I'll open a ticket.
>
> #273
I have solved it - the count leading/trailing zeroes macros on Windows
were unsafe to use with long long result types (its the 32/64 bit int
issue).
I really should use inlines instead - now
I assume this is on 64 bit Windows? I'll open a ticket.
#273
Bill.
2010/1/5 Cactus :
>
> On Jan 5, 11:11 am, Bill Hart wrote:
>> It is worth checking that this specific prime still passes the test
>> with reentrant switched on and that the error is not just going away
>> because of different ra
GPL and not LGPL? I suppose that is not a problem, so long as it is
not built as part of the library...
Bill.
2010/1/5 Cactus :
>
>
> On Jan 5, 8:10 am, Cactus wrote:
>> On Jan 4, 8:02 pm, Cactus wrote:
>>
>>
>>
>> > On Jan 4, 6:56 pm, Bill Hart wrote:
>>
>> > > It looks like we have the follo
On Jan 5, 8:10 am, Cactus wrote:
> On Jan 4, 8:02 pm, Cactus wrote:
>
>
>
> > On Jan 4, 6:56 pm, Bill Hart wrote:
>
> > > It looks like we have the following in mpir.h:
>
> > > #if defined (_CRAY) && ! defined (_CRAYMPP)
> > > /* plain `int' is much faster (48 bits) */
> > > #define __GMP_MP_S
On Jan 5, 11:11 am, Bill Hart wrote:
> It is worth checking that this specific prime still passes the test
> with reentrant switched on and that the error is not just going away
> because of different random seeds or something. Perhaps try inserting
> this number explicitly into the test code to
It is worth checking that this specific prime still passes the test
with reentrant switched on and that the error is not just going away
because of different random seeds or something. Perhaps try inserting
this number explicitly into the test code to check it is not declared
composite. It is in fa
On Jan 5, 10:16 am, Cactus wrote:
> I am seeing an error reported on the mpz_likely_prime test:
>
> mpz_likely_prime_p
> 18158515892286259199 is declared composite
>
> I know we had issues in the past but I thought that they had been
> sorted.
>
> Is this not so?
I have found that this bug is t
I am seeing an error reported on the mpz_likely_prime test:
mpz_likely_prime_p
18158515892286259199 is declared composite
I know we had issues in the past but I thought that they had been
sorted.
Is this not so?
Brian
--
You received this message because you are subscribed to the Google Gr
On Jan 4, 8:02 pm, Cactus wrote:
> On Jan 4, 6:56 pm, Bill Hart wrote:
>
>
>
> > It looks like we have the following in mpir.h:
>
> > #if defined (_CRAY) && ! defined (_CRAYMPP)
> > /* plain `int' is much faster (48 bits) */
> > #define __GMP_MP_SIZE_T_INT 1
> > typedef int
24 matches
Mail list logo
