Ah I just found another problem. Although c99 requires stdint.h to define these things, I am including sys/types.h which is not the accredited cross platform solution. I apparently consulted a dodgy document on the web which gets this wrong. On many systems sys/types.h #includes stdint.h, but apparently not on all systems.
I'll fix this too in FLINT 1.01. As for the *system* not being c99 compliant, I don't see how this can be. Isn't c99 a compiler standard? So if you have gcc 3.4.1 or later, there should be a stdint.h accessible. If not, then so much for gcc being c99 compliant from 3.4.1 onwards. Bill. On Dec 7, 8:51 am, Bill Hart <[EMAIL PROTECTED]> wrote: > 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/ -~----------~----~----~----~------~----~------~--~---
