On Dec 7, 12:02 am, Bill Hart <[EMAIL PROTECTED]> wrote:
> You hopefully mean uint64_t, not u_int64_t. There should be no
> occurrences of u_int64_t left in FLINT. If that's not the case, please
> let me know.
[EMAIL PROTECTED] flint-1.0$ grep -r u_int64_t *
src/long_extras.c: static u_int64_t randval = 4035456057U;
src/long_extras.c: randval =
((u_int64_t)randval*(u_int64_t)1025416097U+(u_int64_t)286824430U)%
(u_int64_t)4294967311U;
src/QS/block_lanczos.h:u_int64_t get_null_entry(u_int64_t *, long,
long);
src/QS/block_lanczos.h:u_int64_t * block_lanczos(unsigned long,
unsigned long, unsigned long, la_col_t*);
Hey, it is *your* code, but I am always glad to help out ;)
> Also, if uint32_t is not available in 32 bit mode, your compiler is
> either not c99 compliant or the machine does not have both a native 32
> bit type and a native 16 bit type, in which case FLINT will not work
> on this machine. This is why the test fails.
>
gcc has a stdint.h in its own header tree under tr1, so I am not too
happy about that. But there are various sys/types.h sys/int_types.h,
sys/types32.h and so on in /usr/include. Since gmp works perfectly
fine on that box (I believe longlong.h originates from there, but I
didn't check) I should figure out what gmp does in that case.
> You definitely should not be defining uint64_t if you are in 32 bit
> mode. But you do need to define uint16_t. The fact that it compiles at
> all suggests something is very, very wrong. If the compiler is c99
> compliant, you should not need to define anything to make it compile.
> If you do, FLINT can't support the machine at present.
>
> To debug this you need to know the values of:
>
> 1) FLINT_BITS (it's a macro in flint.h)
>
> 2) sizeof(uint32_t)
>
> 3) sizeof(uint16_t)
>
> If the machine truly is running in 32 bit mode the values you get
> should be 32, 4 and 2. Only then will the FLINT tests pass.
>
> If you get 64 for number (1) then uint64_t and uint32_t should be
> defined. In that case you should look at the values of
>
> 1) FLINT_BITS
>
> 2) sizeof(uint64_t)
>
> 3) sizeof(uint32_t)
>
> The values you should get in this case should be 64, 8, 4. Only then
> will the FLINT tests pass.
>
I will dig into this in the next couple days, after I got ATLAS and
PolyBoRi merged. Please ping me in a week or so if nothing happens.
> As for the quadratic sieve, yes it is included in FLINT 1.0, but is a
> completely new beast (and much faster). Simply make QS to build it.
> The program is called mpQS. It is fairly similar to the old
> QuadraticSieve program, and with any luck the output is formatted the
> same.
>
> The program now *requires* that the input is not prime, is not a
> perfect power and has no small factors, i.e. you should remove all
> factors up to 1000 and run the elliptic curve method for a few rounds
> before calling the sieve. If you don't do this, mpQS will fail
> silently. Paul Zimmerman opened a ticket at SD6 explaining precisely
> how long to run GMP-ECM before running the quadratic sieve. I leave it
> up to you whether to sort this out now or keep the old sieve for now.
> There have been and will be no further changes to the old sieve so
> nothing needs changing if you want to stick with the old sieve until
> someone can sort out the trial factoring and ECM.
Ok, that sounds great. I remember the ticket that Paul did and I
*should* work on that to actually learn something about mathematics
for once, but the way my current schedule looks right now that seems
unlikely to happen for a couple weeks. So if anybody else wants to do
this I certainly won't mind ;)
> Bill.
>
Cheers,
Michael
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~----------~----~----~----~------~----~------~--~---
