On 7 Dec, 04:30, mabshoff <[EMAIL PROTECTED]
dortmund.de> wrote:
> 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 ;)
Oops, You are right. long_extras is being compiled when you do make
library.
OK, these u_int64_t's should all be uint64_t's. And indeed uint64_t
should be long long on SPARC32.
Since the compiler should be c99, probably just changing this to
uint64_t everywhere will fix the problem, since manifestly the machine
has a 64 bit type.
I've changed it in the FLINT code and will commit it to SVN soon. This
is basically a bug, so I'll have to change it in FLINT 1.0 as well,
i.e. release FLINT 1.01. There are also a few typos on the manual
which I will commit at the same time.
>
> > 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.
Well surely the only relevant file here is the stdint.h file. That is
the one that c99 is required to provide.
>
>
>
> > You definitely should not be defining uint64_t if you are in 32 bit
> > mode.
So this is now wrong. uint64_t does need to be defined after all. But
I still maintain that c99 should provide it for you on this machine.
Hopefully we aren't targetting any machines which don't have a 64 bit
type available otherwise the quadratic sieve is not going to work.
None of this has any bearing on the failing test though. For that,
uint64_t is irrelevant.
> > 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.
>
OK, all the info here should be correct, so I'll be interested to hear
what you come up with. Essentially you just need a 5 line program
which #includes flint.h and prints off the values above. I don't think
I have access to SPARC32 myself.
>
>
> > 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 ;)
OK, thanks for your hard work.
Bill.
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
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/
-~----------~----~----~----~------~----~------~--~---
