flint-devel — Development list for the FLINT project

Re: [flint-devel] use of long in the FLINT API

[Bill H. <goo...@go...>]

Damn, I was hoping to get to SD12, but I'm going to miss it. Oh well, have fun.

Bill.

2009/1/16 Michael Abshoff <mab...@go...>:
> On Thu, Jan 15, 2009 at 5:22 PM, Bill Hart <goo...@go...> wrote:
>> Hi Michael,
>
> Hi Bill,
>
>> you are set to go. I've checked you have write access to the flint
>> repo. Thanks for offering to help with this.
>
> Well, I have great planes, but let's hope it actually translates into
> patches. The first step for me would be to get MinGW 64 bit up and
> running as well as make eMPIRe build in 64 bit mode. My time until the
> end of SD12 is basically filled with Solaris work, but after that you
> need to gently remind me to do some friggin' work :)
>
>> Bill.
>
> Cheers,
>
> Michael
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> flint-devel mailing list
> fli...@li...
> https://lists.sourceforge.net/lists/listinfo/flint-devel
>

Re: [flint-devel] use of long in the FLINT API

[Michael A. <mab...@go...>]

On Thu, Jan 15, 2009 at 5:15 PM, Bill Hart <goo...@go...> wrote:

Hi Bill,

> It's ok to keep the discussion on list, but you are also welcome to
> take it offline.

I only meant to discuss the details of potentially meeting up at UW to
work on this. All the technical discussion should happen on list.

> You are welcome to check out FLINT and start modifying files if you
> want. One complication is that modifications for the FLINT 1.1 series
> need to be made to trunk *and* the flint-1.1 branch. There is no way
> to merge the changes to both automatically as the two directories
> differ. Note that there are more files in the trunk than the flint-1.1
> branch, but all files that appear in flint-1.1 also appear in trunk.

Ok, it seems like I should be working on the development version then
and if we get that to work we can always back port the relevant
changes. This allows for more flexibility and won't impact the stable
branch.

> I am the only person committing code at present and I am likely to
> spend time only in the files F_zmod_poly.c/h, F_zmod_poly-test.c and
> packed_vec.c/h (which only exist in trunk) for the next couple of
> days. Otherwise you are welcome to edit the other files as you wish.
> When it comes to modifying the files I am currently working on I'll do
> a commit so you can work on them.

Sure. As mentioned in the other mail my time for the next 10 or so
days is booked.

> I will enable write access to the flint-svn via your sourceforge
> username in a few moments. But can I ask that you tell me which files
> you're modifying two or three at a time so I can complain if
> necessary. :-)

Thanks, will do.

> You will also need to replace long with something. I don't know what
> to call it. slong will probably have to do, though it is very close to
> a rude Australian swear word,

Not only Australian :)

But I am wondering if using something closer to a C99 unsigned long
and signed long type might make the nature of ulong and "slong" more
clear. But I think this will cause confusion with the underlying gmp
types. I need to think about this more. Either way, signed and
unsignled long types should be consistent in naming convention if
possible. But in the end I can certainly live with

 ulong
 slong

> i.e. FLINT should use ulong instead of
> unsigned long and slong instead of long throughout. Finding where
> pointers are assigned to a ulong will be difficult to find. Looking
> for all occurrences of **, fmpz_t and ****alloc*** (e.g.
> flint_heap_alloc, malloc, flint_stack_alloc, flint_stack_alloc_small,
> flint_stack_alloc_bytes, etc) should get many of them.

Ok. There is a new valgrind tool called exp-ptrcheck that catches the
use of 32 bit pointers when interacting with 64 bit pointers. It
doesn't run on anything but Linux and I can't see a way yet to make
long on 64 bit platforms 32 bit without impacting all the other things
FLINT uses. There is no LLP Linux box AFAIK, so maybe using purify in
Windows might lead some assistance. In the end it might have to be
good old fashioned debugging :)

> Bill.

Cheers,

Michael

Re: [flint-devel] use of long in the FLINT API

[Michael A. <mab...@go...>]

On Thu, Jan 15, 2009 at 5:22 PM, Bill Hart <goo...@go...> wrote:
> Hi Michael,

Hi Bill,

> you are set to go. I've checked you have write access to the flint
> repo. Thanks for offering to help with this.

Well, I have great planes, but let's hope it actually translates into
patches. The first step for me would be to get MinGW 64 bit up and
running as well as make eMPIRe build in 64 bit mode. My time until the
end of SD12 is basically filled with Solaris work, but after that you
need to gently remind me to do some friggin' work :)

> Bill.

Cheers,

Michael

Re: [flint-devel] use of long in the FLINT API

[Bill H. <goo...@go...>]

Hi Michael,

you are set to go. I've checked you have write access to the flint
repo. Thanks for offering to help with this.

Bill.

2009/1/16 Michael Abshoff <mab...@go...>:
> On Thu, Jan 15, 2009 at 4:23 PM, Bill Hart <goo...@go...> wrote:
>> Hi Michael,
>
> Hi Bill.
>
>> the timetable for FLINT 2.0 is not so uncertain. It should be out for
>> Christmas this
>
> Sure, but this is roughly a year away :)
>
>> year. But you don't want to wait that ulong.
>
> Nice pun.
>
>> Doing a search and replace of unsigned long for ulong is certainly
>> something you can go ahead and do. It won't break FLINT 1.1 (I don't
>> think).
>
> It won't aside from some C compiler throwing a couple new warnings.
> But if you are willing to risk it I am game.
>
>> Replacing integers that hold pointers with intptr_t will not break
>> FLINT 1.1 on any of the systems it currently works on, as intptr_t
>> will be a 32 or 64 bit integer on a 32 and 64 bit machine
>> respectively. But it isn't a magic bullet for LLP and SFU machines.
>> FLINT still won't work on those machines without human intervention.
>> It is that job which I need to find the time to complete.
>
> Absolutely, but given its extensive test suite and a little compiler
> magic I think I can help out finding and fixing those issues by using
> MinGW 64.
>
>> Assuming the rest was already done, I guess I could look at it in a
>> little over a month. Would that screw with your timetable too much?
>
> Well, the timetable for the Windows port has been slipping so bad I
> hope I won't be pulling a Vista :)
>
> But in all seriousness: The Solaris port is nearing completion and
> hopefully the remaining few issues will be sorted out at SD 12. Then
> my focus will shift to the Cygwin as well as 32 bit SFU port which I
> hope I will get done in about two months, i.e. by the end of March.
> Then the 64 bit SFU port would be next where issues like the ones in
> FLINT will likely pop up in many other places, too, but I am hoping
> this won't take the rest of the year to fix.
>
>> Perhaps I would have time to do it at UW in April or May, but that
>> seems to be an appalling waste of time, and William may not approve. I
>> suppose Sage days at UW is one time I might get away with it!
>
> Well, I can assure you that the Windows port is very important for
> William, but your time at UW is probably better spend mostly on
> something else. I had originally planned to spend some time at UW in
> February and March, but things have moved around. Maybe coordinating
> me being at UW for at least a couple weeks in the time frame you are
> there and then planning to work on the 64 bit Windows issues for FLINT
> among other things might be a good idea. I.e. I could imagine me
> asking a bunch of questions every couple days and then coming back
> with patches for you to look at so that the impact for your work at UW
> is rather minimal.
>
> We can take this part of the discussion off-list with William since
> not too many people on flint-devel will care I guess :)
>
>> Bill.
>
> Cheers,
>
> Michael
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> flint-devel mailing list
> fli...@li...
> https://lists.sourceforge.net/lists/listinfo/flint-devel
>

Re: [flint-devel] use of long in the FLINT API

[Michael A. <mab...@go...>]

On Thu, Jan 15, 2009 at 4:23 PM, Bill Hart <goo...@go...> wrote:
> Hi Michael,

Hi Bill.

> the timetable for FLINT 2.0 is not so uncertain. It should be out for
> Christmas this

Sure, but this is roughly a year away :)

> year. But you don't want to wait that ulong.

Nice pun.

> Doing a search and replace of unsigned long for ulong is certainly
> something you can go ahead and do. It won't break FLINT 1.1 (I don't
> think).

It won't aside from some C compiler throwing a couple new warnings.
But if you are willing to risk it I am game.

> Replacing integers that hold pointers with intptr_t will not break
> FLINT 1.1 on any of the systems it currently works on, as intptr_t
> will be a 32 or 64 bit integer on a 32 and 64 bit machine
> respectively. But it isn't a magic bullet for LLP and SFU machines.
> FLINT still won't work on those machines without human intervention.
> It is that job which I need to find the time to complete.

Absolutely, but given its extensive test suite and a little compiler
magic I think I can help out finding and fixing those issues by using
MinGW 64.

> Assuming the rest was already done, I guess I could look at it in a
> little over a month. Would that screw with your timetable too much?

Well, the timetable for the Windows port has been slipping so bad I
hope I won't be pulling a Vista :)

But in all seriousness: The Solaris port is nearing completion and
hopefully the remaining few issues will be sorted out at SD 12. Then
my focus will shift to the Cygwin as well as 32 bit SFU port which I
hope I will get done in about two months, i.e. by the end of March.
Then the 64 bit SFU port would be next where issues like the ones in
FLINT will likely pop up in many other places, too, but I am hoping
this won't take the rest of the year to fix.

> Perhaps I would have time to do it at UW in April or May, but that
> seems to be an appalling waste of time, and William may not approve. I
> suppose Sage days at UW is one time I might get away with it!

Well, I can assure you that the Windows port is very important for
William, but your time at UW is probably better spend mostly on
something else. I had originally planned to spend some time at UW in
February and March, but things have moved around. Maybe coordinating
me being at UW for at least a couple weeks in the time frame you are
there and then planning to work on the 64 bit Windows issues for FLINT
among other things might be a good idea. I.e. I could imagine me
asking a bunch of questions every couple days and then coming back
with patches for you to look at so that the impact for your work at UW
is rather minimal.

We can take this part of the discussion off-list with William since
not too many people on flint-devel will care I guess :)

> Bill.

Cheers,

Michael

Re: [flint-devel] use of long in the FLINT API

[Bill H. <goo...@go...>]

Hi Michael,

the timetable for FLINT 2.0 is not so uncertain. It should be out for
Christmas this year. But you don't want to wait that ulong.

Doing a search and replace of unsigned long for ulong is certainly
something you can go ahead and do. It won't break FLINT 1.1 (I don't
think).

Replacing integers that hold pointers with intptr_t will not break
FLINT 1.1 on any of the systems it currently works on, as intptr_t
will be a 32 or 64 bit integer on a 32 and 64 bit machine
respectively. But it isn't a magic bullet for LLP and SFU machines.
FLINT still won't work on those machines without human intervention.
It is that job which I need to find the time to complete.

Assuming the rest was already done, I guess I could look at it in a
little over a month. Would that screw with your timetable too much?
Perhaps I would have time to do it at UW in April or May, but that
seems to be an appalling waste of time, and William may not approve. I
suppose Sage days at UW is one time I might get away with it!

Bill.

2009/1/16 Michael Abshoff <mab...@go...>:
> On Thu, Jan 15, 2009 at 3:48 PM, Bill Hart <goo...@go...> wrote:
>
> Hi Bill,
>
>> The plan by the way will be to use intptr_t everywhere in FLINT where
>> integers are needed to hold a pointer. Of course it is easier said
>> than done.
>
> Sure, but I can help with "menial" tasks like that. The big question
> is whether any of those changes could be in FLINT 1.1 since it would
> potentially break API. Given the rather unclear time table for FLINT
> 2.0 I don't want to depend on that to get a 64 bit SFU version of Sage
> going.
>
>> Bill.
>>
>> 2009/1/15 Bill Hart <goo...@go...>:
>>> Hi Michael,
>>>
>>> At present I always assume that a ulong and a GMP limb are the same
>>> size. The plan is to replace unsigned long with ulong throughout the
>>> code. Then I guess you could simply change ulong in flint.h to
>>> whatever you want, though there is no point changing it to something
>>> that is not the same size as a limb, otherwise FLINT will certainly
>>> break.
>>>
>>> There's quite a bit of code to go through. But I *think* just doing a
>>> search and replace for unsigned long and replacing it with ulong
>>> should not break anything. That at least makes FLINT work on a machine
>>> where the limb size is not the same as an unsigned long. One just
>>> defines a ulong to be something that is the same size as a limb in
>>> flint.h.
>
> Yes. Note that neither gmp nor eMPIRe compiled on MinGW 64 due to it
> using long instead of long long as basic 64 bit type. There was a
> patch on the gmp list many months ago that added a check if
> sizeof(long)==sizeof(long long) and it it failed used long long. This
> is something that is done in a similar way for Brian's 64 bit MSVC
> build, but I am hazy on the details.
>
> Once we have eMPIRe build on MinGW 64 we can easily test FLINT in 64
> bit mode on Windows without the need to do a port to MSVC which should
> make things much easier.
>
>>> The bigger issue is that I also currently assume that pointer
>>> arithmetic can always be done with a ulong and in some cases I even
>>> assume that a pointer can be cast to a ulong. That is not so easy to
>>> fix at present, though this problem should occur less often throughout
>>> the code.
>>>
>>> These issues will *definitely* be fixed for FLINT 2.0. But beyond that
>>> I don't know when I will get them fixed.
>>>
>>> Another minor issue is that I assume that a double can fit in a ulong
>>> on a 64 bit machine. But whether or not the machine is 64 bit is
>>> defined in flint.h, so this problem is trivial to fix.
>
> Ok.
>
>>> I certainly won't have time to do anything about these problem for a
>>> few months. I have so much on at the moment it isn't funny.
>
> Sure, I am not complaining, I want to help you. Obviously my time
> table is about as empty as your's, so no promises here :)
>
>>> Bill.
>
> Cheers,
>
> Michael
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> flint-devel mailing list
> fli...@li...
> https://lists.sourceforge.net/lists/listinfo/flint-devel
>

Re: [flint-devel] use of long in the FLINT API

[Michael A. <mab...@go...>]

On Thu, Jan 15, 2009 at 3:48 PM, Bill Hart <goo...@go...> wrote:

Hi Bill,

> The plan by the way will be to use intptr_t everywhere in FLINT where
> integers are needed to hold a pointer. Of course it is easier said
> than done.

Sure, but I can help with "menial" tasks like that. The big question
is whether any of those changes could be in FLINT 1.1 since it would
potentially break API. Given the rather unclear time table for FLINT
2.0 I don't want to depend on that to get a 64 bit SFU version of Sage
going.

> Bill.
>
> 2009/1/15 Bill Hart <goo...@go...>:
>> Hi Michael,
>>
>> At present I always assume that a ulong and a GMP limb are the same
>> size. The plan is to replace unsigned long with ulong throughout the
>> code. Then I guess you could simply change ulong in flint.h to
>> whatever you want, though there is no point changing it to something
>> that is not the same size as a limb, otherwise FLINT will certainly
>> break.
>>
>> There's quite a bit of code to go through. But I *think* just doing a
>> search and replace for unsigned long and replacing it with ulong
>> should not break anything. That at least makes FLINT work on a machine
>> where the limb size is not the same as an unsigned long. One just
>> defines a ulong to be something that is the same size as a limb in
>> flint.h.

Yes. Note that neither gmp nor eMPIRe compiled on MinGW 64 due to it
using long instead of long long as basic 64 bit type. There was a
patch on the gmp list many months ago that added a check if
sizeof(long)==sizeof(long long) and it it failed used long long. This
is something that is done in a similar way for Brian's 64 bit MSVC
build, but I am hazy on the details.

Once we have eMPIRe build on MinGW 64 we can easily test FLINT in 64
bit mode on Windows without the need to do a port to MSVC which should
make things much easier.

>> The bigger issue is that I also currently assume that pointer
>> arithmetic can always be done with a ulong and in some cases I even
>> assume that a pointer can be cast to a ulong. That is not so easy to
>> fix at present, though this problem should occur less often throughout
>> the code.
>>
>> These issues will *definitely* be fixed for FLINT 2.0. But beyond that
>> I don't know when I will get them fixed.
>>
>> Another minor issue is that I assume that a double can fit in a ulong
>> on a 64 bit machine. But whether or not the machine is 64 bit is
>> defined in flint.h, so this problem is trivial to fix.

Ok.

>> I certainly won't have time to do anything about these problem for a
>> few months. I have so much on at the moment it isn't funny.

Sure, I am not complaining, I want to help you. Obviously my time
table is about as empty as your's, so no promises here :)

>> Bill.

Cheers,

Michael

Re: [flint-devel] use of long in the FLINT API

[Bill H. <goo...@go...>]

The plan by the way will be to use intptr_t everywhere in FLINT where
integers are needed to hold a pointer. Of course it is easier said
than done.

Bill.

2009/1/15 Bill Hart <goo...@go...>:
> Hi Michael,
>
> At present I always assume that a ulong and a GMP limb are the same
> size. The plan is to replace unsigned long with ulong throughout the
> code. Then I guess you could simply change ulong in flint.h to
> whatever you want, though there is no point changing it to something
> that is not the same size as a limb, otherwise FLINT will certainly
> break.
>
> There's quite a bit of code to go through. But I *think* just doing a
> search and replace for unsigned long and replacing it with ulong
> should not break anything. That at least makes FLINT work on a machine
> where the limb size is not the same as an unsigned long. One just
> defines a ulong to be something that is the same size as a limb in
> flint.h.
>
> The bigger issue is that I also currently assume that pointer
> arithmetic can always be done with a ulong and in some cases I even
> assume that a pointer can be cast to a ulong. That is not so easy to
> fix at present, though this problem should occur less often throughout
> the code.
>
> These issues will *definitely* be fixed for FLINT 2.0. But beyond that
> I don't know when I will get them fixed.
>
> Another minor issue is that I assume that a double can fit in a ulong
> on a 64 bit machine. But whether or not the machine is 64 bit is
> defined in flint.h, so this problem is trivial to fix.
>
> I certainly won't have time to do anything about these problem for a
> few months. I have so much on at the moment it isn't funny.
>
> Bill.
>
> 2009/1/15 Michael Abshoff <mab...@go...>:
>> Hi Bill,
>>
>> at SD 10 we had a chat about using "long" in the FLINT headers and in
>> general. Since we integration with FLINT and Sage is getting tighter
>> and tighter, i.e. #4965 in Sage's trac, I am wondering what the long
>> term plan is here because of the Windows port. In the development
>> version's flint.h you already have something like
>>
>> #define ulong unsigned long
>>
>> #if FLINT_BITS == 32
>> #define half_ulong uint16_t
>> #define half_long int16_t
>> #define HALF_FLINT_BITS 16
>> #else
>> #define half_ulong uint32_t
>> #define half_long int32_t
>> #define HALF_FLINT_BITS 32
>> #endif
>>
>> Would it be possible to also declare appropriate 64 bit types here
>> since we cannot assume that sizeof(long)==8 on 64 bit platforms in
>> general? Obviously the native Windows port won't happen next week, but
>> since FLINT 2.0 is a while out it might be good to think about this
>> now :) The SFU port of Sage also has to deal with sizeof(long)==4 in
>> 64 bit mode AFAIK, so this is a lot more concrete than I want it to
>> be.
>>
>> Cheers,
>>
>> Michael
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by:
>> SourcForge Community
>> SourceForge wants to tell your story.
>> http://p.sf.net/sfu/sf-spreadtheword
>> _______________________________________________
>> flint-devel mailing list
>> fli...@li...
>> https://lists.sourceforge.net/lists/listinfo/flint-devel
>>
>

Re: [flint-devel] use of long in the FLINT API

[Bill H. <goo...@go...>]

Hi Michael,

At present I always assume that a ulong and a GMP limb are the same
size. The plan is to replace unsigned long with ulong throughout the
code. Then I guess you could simply change ulong in flint.h to
whatever you want, though there is no point changing it to something
that is not the same size as a limb, otherwise FLINT will certainly
break.

There's quite a bit of code to go through. But I *think* just doing a
search and replace for unsigned long and replacing it with ulong
should not break anything. That at least makes FLINT work on a machine
where the limb size is not the same as an unsigned long. One just
defines a ulong to be something that is the same size as a limb in
flint.h.

The bigger issue is that I also currently assume that pointer
arithmetic can always be done with a ulong and in some cases I even
assume that a pointer can be cast to a ulong. That is not so easy to
fix at present, though this problem should occur less often throughout
the code.

These issues will *definitely* be fixed for FLINT 2.0. But beyond that
I don't know when I will get them fixed.

Another minor issue is that I assume that a double can fit in a ulong
on a 64 bit machine. But whether or not the machine is 64 bit is
defined in flint.h, so this problem is trivial to fix.

I certainly won't have time to do anything about these problem for a
few months. I have so much on at the moment it isn't funny.

Bill.

2009/1/15 Michael Abshoff <mab...@go...>:
> Hi Bill,
>
> at SD 10 we had a chat about using "long" in the FLINT headers and in
> general. Since we integration with FLINT and Sage is getting tighter
> and tighter, i.e. #4965 in Sage's trac, I am wondering what the long
> term plan is here because of the Windows port. In the development
> version's flint.h you already have something like
>
> #define ulong unsigned long
>
> #if FLINT_BITS == 32
> #define half_ulong uint16_t
> #define half_long int16_t
> #define HALF_FLINT_BITS 16
> #else
> #define half_ulong uint32_t
> #define half_long int32_t
> #define HALF_FLINT_BITS 32
> #endif
>
> Would it be possible to also declare appropriate 64 bit types here
> since we cannot assume that sizeof(long)==8 on 64 bit platforms in
> general? Obviously the native Windows port won't happen next week, but
> since FLINT 2.0 is a while out it might be good to think about this
> now :) The SFU port of Sage also has to deal with sizeof(long)==4 in
> 64 bit mode AFAIK, so this is a lot more concrete than I want it to
> be.
>
> Cheers,
>
> Michael
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> flint-devel mailing list
> fli...@li...
> https://lists.sourceforge.net/lists/listinfo/flint-devel
>

[flint-devel] use of long in the FLINT API

[Michael A. <mab...@go...>]

Hi Bill,

at SD 10 we had a chat about using "long" in the FLINT headers and in
general. Since we integration with FLINT and Sage is getting tighter
and tighter, i.e. #4965 in Sage's trac, I am wondering what the long
term plan is here because of the Windows port. In the development
version's flint.h you already have something like

#define ulong unsigned long

#if FLINT_BITS == 32
#define half_ulong uint16_t
#define half_long int16_t
#define HALF_FLINT_BITS 16
#else
#define half_ulong uint32_t
#define half_long int32_t
#define HALF_FLINT_BITS 32
#endif

Would it be possible to also declare appropriate 64 bit types here
since we cannot assume that sizeof(long)==8 on 64 bit platforms in
general? Obviously the native Windows port won't happen next week, but
since FLINT 2.0 is a while out it might be good to think about this
now :) The SFU port of Sage also has to deal with sizeof(long)==4 in
64 bit mode AFAIK, so this is a lot more concrete than I want it to
be.

Cheers,

Michael

Re: [flint-devel] long_extras-test failure on z_isprime_nm1()

[Bill H. <goo...@go...>]

Hi Peter,

Thanks for the fix. I'm currently in the north of England seeing some
sights and without proper net access. But I'll be back home tomorrow
and will merge this.

I'm pretty sure it only affects trunk and not the other branches, so
Sage won't be affected.

Bill.

On 29/12/2008, Peter Shrimpton <ps...@gm...> wrote:
> Hey all
>
> z_isprime_nm1() is producing a floating point exception which is easy to
> fix. All that needs to be done is change the line:
>
> z_factor_partial(&factors, n1, cuberoot, 1);
>
> to
>
> cofactor=z_factor_partial(&factors, n1, cuberoot, 1);
>
> Hope this helps
>
> Peter
>

[flint-devel] long_extras-test failure on z_isprime_nm1()

[Peter S. <ps...@gm...>]

Hey all

z_isprime_nm1() is producing a floating point exception which is easy to
fix. All that needs to be done is change the line:

z_factor_partial(&factors, n1, cuberoot, 1);

to

cofactor=z_factor_partial(&factors, n1, cuberoot, 1);

Hope this helps

Peter

Re: [flint-devel] newlines in makefile

[Michael A. <mab...@go...>]

On Thu, Dec 25, 2008 at 9:54 AM, Bill Hart <goo...@go...> wrote:
> OK, I've issued 1.0.21 which fixes these issues. It isn't immediately
> clear to me whether this bug was in previous versions or not. It
> wasn't an introduced bug as such, but it may have been created when
> another bug was fixed. Either way, things are done differently in
> later versions of FLINT and so they won't be an issue.
>
> Bill.

Thanks, I will update the spkg and try again.

Cheers,

Michael

Re: [flint-devel] newlines in makefile

[Bill H. <goo...@go...>]

OK, I've issued 1.0.21 which fixes these issues. It isn't immediately
clear to me whether this bug was in previous versions or not. It
wasn't an introduced bug as such, but it may have been created when
another bug was fixed. Either way, things are done differently in
later versions of FLINT and so they won't be an issue.

Bill.

2008/12/25 Bill Hart <goo...@go...>:
> I've fixed the bug (the same bug caused both problems) and will issue
> FLINT 1.0.21 in a couple of minutes. It was as I thought, using 32 bit
> primes instead of 31 bits.
>
> This bug does not exist in FLINT 1.1 or 1.2.
>
> Bill.
>
> 2008/12/25 Michael Abshoff <mab...@go...>:
>> On Thu, Dec 25, 2008 at 8:36 AM, Bill Hart <goo...@go...> wrote:
>>
>> Hi Bill,
>>
>>> I'll reply to both posts at once.
>>
>> Ok.
>>
>>> The test failures will be cases hit because of different random seeds
>>> on those 32 machines. They should be trivial to fix. There is an
>>> outside chance I can do it tonight, but if I have access to the
>>> machines involved, this will be easier.
>>
>> The linux box is cicero on SkyNet, but I am currently valgrind there,
>> so I am keeping that box busy. The other one is varro also on SkyNet,
>> but I don't think your account works there, so you should ping Mariah.
>>
>>> Upgrading to 1.1 should not be painful, unless you want to incorporate
>>> lots of the new functionality (which I hope you will :-)). In that
>>> case there's the wrapper to write. But otherwise things should be
>>> quite stable. I've done very long runs with most of the new functions,
>>> and no problems. I don't think SAGE uses any of the functionality
>>> where the interface has changed.
>>
>> Ok.
>>
>>> I've only just noticed that these failures are being reported for
>>> FLINT 1.0.20. That's odd, because only bug fixes have gone into that
>>> branch for some time now, so presumably these bugs have been there for
>>> a while, and have been triggered due to different random seeds after
>>> rebuilding.
>>
>> Yes, I just turned tests on since I figured it cannot hurt and I was
>> just as surprised that on both 32 bit test boxen things didn't work
>> too well.
>>
>>> If the bugs are in 1.0.20 they are also likely in 1.1, just not
>>> triggered because of different random seeds.
>>
>> Good to know. Once I am done with 1.0.20 I will test 1.1 on the same box.
>>
>>> Bill.
>>
>> Cheers,
>>
>> Michael
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> flint-devel mailing list
>> fli...@li...
>> https://lists.sourceforge.net/lists/listinfo/flint-devel
>>
>

Re: [flint-devel] newlines in makefile

[Bill H. <goo...@go...>]

I've fixed the bug (the same bug caused both problems) and will issue
FLINT 1.0.21 in a couple of minutes. It was as I thought, using 32 bit
primes instead of 31 bits.

This bug does not exist in FLINT 1.1 or 1.2.

Bill.

2008/12/25 Michael Abshoff <mab...@go...>:
> On Thu, Dec 25, 2008 at 8:36 AM, Bill Hart <goo...@go...> wrote:
>
> Hi Bill,
>
>> I'll reply to both posts at once.
>
> Ok.
>
>> The test failures will be cases hit because of different random seeds
>> on those 32 machines. They should be trivial to fix. There is an
>> outside chance I can do it tonight, but if I have access to the
>> machines involved, this will be easier.
>
> The linux box is cicero on SkyNet, but I am currently valgrind there,
> so I am keeping that box busy. The other one is varro also on SkyNet,
> but I don't think your account works there, so you should ping Mariah.
>
>> Upgrading to 1.1 should not be painful, unless you want to incorporate
>> lots of the new functionality (which I hope you will :-)). In that
>> case there's the wrapper to write. But otherwise things should be
>> quite stable. I've done very long runs with most of the new functions,
>> and no problems. I don't think SAGE uses any of the functionality
>> where the interface has changed.
>
> Ok.
>
>> I've only just noticed that these failures are being reported for
>> FLINT 1.0.20. That's odd, because only bug fixes have gone into that
>> branch for some time now, so presumably these bugs have been there for
>> a while, and have been triggered due to different random seeds after
>> rebuilding.
>
> Yes, I just turned tests on since I figured it cannot hurt and I was
> just as surprised that on both 32 bit test boxen things didn't work
> too well.
>
>> If the bugs are in 1.0.20 they are also likely in 1.1, just not
>> triggered because of different random seeds.
>
> Good to know. Once I am done with 1.0.20 I will test 1.1 on the same box.
>
>> Bill.
>
> Cheers,
>
> Michael
>
> ------------------------------------------------------------------------------
> _______________________________________________
> flint-devel mailing list
> fli...@li...
> https://lists.sourceforge.net/lists/listinfo/flint-devel
>

Re: [flint-devel] newlines in makefile

[Michael A. <mab...@go...>]

On Thu, Dec 25, 2008 at 8:36 AM, Bill Hart <goo...@go...> wrote:

Hi Bill,

> I'll reply to both posts at once.

Ok.

> The test failures will be cases hit because of different random seeds
> on those 32 machines. They should be trivial to fix. There is an
> outside chance I can do it tonight, but if I have access to the
> machines involved, this will be easier.

The linux box is cicero on SkyNet, but I am currently valgrind there,
so I am keeping that box busy. The other one is varro also on SkyNet,
but I don't think your account works there, so you should ping Mariah.

> Upgrading to 1.1 should not be painful, unless you want to incorporate
> lots of the new functionality (which I hope you will :-)). In that
> case there's the wrapper to write. But otherwise things should be
> quite stable. I've done very long runs with most of the new functions,
> and no problems. I don't think SAGE uses any of the functionality
> where the interface has changed.

Ok.

> I've only just noticed that these failures are being reported for
> FLINT 1.0.20. That's odd, because only bug fixes have gone into that
> branch for some time now, so presumably these bugs have been there for
> a while, and have been triggered due to different random seeds after
> rebuilding.

Yes, I just turned tests on since I figured it cannot hurt and I was
just as surprised that on both 32 bit test boxen things didn't work
too well.

> If the bugs are in 1.0.20 they are also likely in 1.1, just not
> triggered because of different random seeds.

Good to know. Once I am done with 1.0.20 I will test 1.1 on the same box.

> Bill.

Cheers,

Michael

Re: [flint-devel] newlines in makefile

[Bill H. <goo...@go...>]

OK, I see I do have access. Didn't read the posts properly on my
IPhone. Back home now.

Bill.

2008/12/25 Bill Hart <goo...@go...>:
> I'll reply to both posts at once.
>
> The test failures will be cases hit because of different random seeds
> on those 32 machines. They should be trivial to fix. There is an
> outside chance I can do it tonight, but if I have access to the
> machines involved, this will be easier.
>
> Upgrading to 1.1 should not be painful, unless you want to incorporate
> lots of the new functionality (which I hope you will :-)). In that
> case there's the wrapper to write. But otherwise things should be
> quite stable. I've done very long runs with most of the new functions,
> and no problems. I don't think SAGE uses any of the functionality
> where the interface has changed.
>
> I've only just noticed that these failures are being reported for
> FLINT 1.0.20. That's odd, because only bug fixes have gone into that
> branch for some time now, so presumably these bugs have been there for
> a while, and have been triggered due to different random seeds after
> rebuilding.
>
> If the bugs are in 1.0.20 they are also likely in 1.1, just not
> triggered because of different random seeds.
>
> Bill.
>
> 2008/12/25 Michael Abshoff <mab...@go...>:
>> On Thu, Dec 25, 2008 at 6:50 AM, Burcin Erocal <bu...@er...> wrote:
>>> On Thu, 25 Dec 2008 14:39:37 +0000
>>> "Bill Hart" <goo...@go...> wrote:
>>
>> Hi,
>>
>>>> There's only Z/pZ[x] factoring so far, not Z[x]. I'll fix the test
>>>> failures as soon as I can. What architecture was it? I *think* the
>>>> failure is probably due to using 32 bit primes not 31 bit, but I need
>>>> to check it out.
>>
>> Ok.
>>
>>> OK, good to know. I only saw the factor functions when I was skimming
>>> the zmod_poly section for the Zn[x] wrapper in Sage, and somehow
>>> assumed they were available for Z[x] as well.
>>>
>>> This means even less work to update to 1.1.0 instead of 1.0.20. :)
>>> FWIW, I tested 1.1.0 on some of the 32-bit machines I have access to,
>>> and all tests passed.
>>
>> Sure, but I am reluctant to switch to 1.1 so late in the game for
>> 3.2.3 given the need to do 3.3 in less than a week. So if the 1.1
>> update is more or less painless I would want to do that in 3.3, but if
>> anything is turned up by valgrinding 1.0.20 on 32 bit boxen I would be
>> curious if this is worth fixing via 1.0.21 in 3.2.3 or if we should
>> just move to 1.1 in 3.3.
>>
>>>
>>> Cheers,
>>>
>>> Burcin
>>
>> Cheers,
>>
>> Michael
>>
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> flint-devel mailing list
>>> fli...@li...
>>> https://lists.sourceforge.net/lists/listinfo/flint-devel
>>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> flint-devel mailing list
>> fli...@li...
>> https://lists.sourceforge.net/lists/listinfo/flint-devel
>>
>

Re: [flint-devel] newlines in makefile

[Bill H. <goo...@go...>]

I'll reply to both posts at once.

The test failures will be cases hit because of different random seeds
on those 32 machines. They should be trivial to fix. There is an
outside chance I can do it tonight, but if I have access to the
machines involved, this will be easier.

Upgrading to 1.1 should not be painful, unless you want to incorporate
lots of the new functionality (which I hope you will :-)). In that
case there's the wrapper to write. But otherwise things should be
quite stable. I've done very long runs with most of the new functions,
and no problems. I don't think SAGE uses any of the functionality
where the interface has changed.

I've only just noticed that these failures are being reported for
FLINT 1.0.20. That's odd, because only bug fixes have gone into that
branch for some time now, so presumably these bugs have been there for
a while, and have been triggered due to different random seeds after
rebuilding.

If the bugs are in 1.0.20 they are also likely in 1.1, just not
triggered because of different random seeds.

Bill.

2008/12/25 Michael Abshoff <mab...@go...>:
> On Thu, Dec 25, 2008 at 6:50 AM, Burcin Erocal <bu...@er...> wrote:
>> On Thu, 25 Dec 2008 14:39:37 +0000
>> "Bill Hart" <goo...@go...> wrote:
>
> Hi,
>
>>> There's only Z/pZ[x] factoring so far, not Z[x]. I'll fix the test
>>> failures as soon as I can. What architecture was it? I *think* the
>>> failure is probably due to using 32 bit primes not 31 bit, but I need
>>> to check it out.
>
> Ok.
>
>> OK, good to know. I only saw the factor functions when I was skimming
>> the zmod_poly section for the Zn[x] wrapper in Sage, and somehow
>> assumed they were available for Z[x] as well.
>>
>> This means even less work to update to 1.1.0 instead of 1.0.20. :)
>> FWIW, I tested 1.1.0 on some of the 32-bit machines I have access to,
>> and all tests passed.
>
> Sure, but I am reluctant to switch to 1.1 so late in the game for
> 3.2.3 given the need to do 3.3 in less than a week. So if the 1.1
> update is more or less painless I would want to do that in 3.3, but if
> anything is turned up by valgrinding 1.0.20 on 32 bit boxen I would be
> curious if this is worth fixing via 1.0.21 in 3.2.3 or if we should
> just move to 1.1 in 3.3.
>
>>
>> Cheers,
>>
>> Burcin
>
> Cheers,
>
> Michael
>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> flint-devel mailing list
>> fli...@li...
>> https://lists.sourceforge.net/lists/listinfo/flint-devel
>>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> flint-devel mailing list
> fli...@li...
> https://lists.sourceforge.net/lists/listinfo/flint-devel
>

Re: [flint-devel] newlines in makefile

[Michael A. <mab...@go...>]

On Thu, Dec 25, 2008 at 6:50 AM, Burcin Erocal <bu...@er...> wrote:
> On Thu, 25 Dec 2008 14:39:37 +0000
> "Bill Hart" <goo...@go...> wrote:

Hi,

>> There's only Z/pZ[x] factoring so far, not Z[x]. I'll fix the test
>> failures as soon as I can. What architecture was it? I *think* the
>> failure is probably due to using 32 bit primes not 31 bit, but I need
>> to check it out.

Ok.

> OK, good to know. I only saw the factor functions when I was skimming
> the zmod_poly section for the Zn[x] wrapper in Sage, and somehow
> assumed they were available for Z[x] as well.
>
> This means even less work to update to 1.1.0 instead of 1.0.20. :)
> FWIW, I tested 1.1.0 on some of the 32-bit machines I have access to,
> and all tests passed.

Sure, but I am reluctant to switch to 1.1 so late in the game for
3.2.3 given the need to do 3.3 in less than a week. So if the 1.1
update is more or less painless I would want to do that in 3.3, but if
anything is turned up by valgrinding 1.0.20 on 32 bit boxen I would be
curious if this is worth fixing via 1.0.21 in 3.2.3 or if we should
just move to 1.1 in 3.3.

>
> Cheers,
>
> Burcin

Cheers,

Michael

>
> ------------------------------------------------------------------------------
> _______________________________________________
> flint-devel mailing list
> fli...@li...
> https://lists.sourceforge.net/lists/listinfo/flint-devel
>

Re: [flint-devel] newlines in makefile

[Burcin E. <bu...@er...>]

On Thu, 25 Dec 2008 14:39:37 +0000
"Bill Hart" <goo...@go...> wrote:

> There's only Z/pZ[x] factoring so far, not Z[x]. I'll fix the test
> failures as soon as I can. What architecture was it? I *think* the
> failure is probably due to using 32 bit primes not 31 bit, but I need
> to check it out.

OK, good to know. I only saw the factor functions when I was skimming
the zmod_poly section for the Zn[x] wrapper in Sage, and somehow
assumed they were available for Z[x] as well.

This means even less work to update to 1.1.0 instead of 1.0.20. :)
FWIW, I tested 1.1.0 on some of the 32-bit machines I have access to,
and all tests passed.


Cheers,

Burcin

Re: [flint-devel] newlines in makefile

[Bill H. <goo...@go...>]

There's only Z/pZ[x] factoring so far, not Z[x]. I'll fix the test
failures as soon as I can. What architecture was it? I *think* the
failure is probably due to using 32 bit primes not 31 bit, but I need
to check it out.

Bill.

On 25/12/2008, Michael Abshoff <mab...@go...> wrote:
> On Thu, Dec 25, 2008 at 4:53 AM, Burcin Erocal <bu...@er...> wrote:
>> On Tue, 23 Dec 2008 16:19:53 -0800
>> "Michael Abshoff" <mab...@go...> wrote:
>
> Hi Burcin,
>
>>> On Tue, Dec 23, 2008 at 3:36 PM, Michael Abshoff
>>> <mab...@go...> wrote:
>> <snip>
>>> Hopefully we will upgrade to FLINT 1.1 during SD 12, but we will see
>>> how that goes.
>>
>> Do you have an spkg for 1.1 already?
>
> Nope, but it shouldn't be too hard to do. We need to fix some
> dependency issues due to David's zn_poly, but other than that I wanted
> to clean up spkg-install and spkg-check in Sage's flint.spkg since
> they are pretty messy.
>
>>  If you send it my way I can
>> quickly see if the update breaks anything, and move ZZ[x] polynomials
>> to use FLINT for factoring as well.
>
> Cool.
>
>> I will also wait for the updated spkg to push my zmod_poly wrapper
>> upstream. The new derivative and factor methods will save me some time.
>
> :)
>
>> Cheers,
>>
>> Burcin
>
> Cheers,
>
> Michael
>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> flint-devel mailing list
>> fli...@li...
>> https://lists.sourceforge.net/lists/listinfo/flint-devel
>>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> flint-devel mailing list
> fli...@li...
> https://lists.sourceforge.net/lists/listinfo/flint-devel
>

Re: [flint-devel] newlines in makefile

[Michael A. <mab...@go...>]

On Thu, Dec 25, 2008 at 4:53 AM, Burcin Erocal <bu...@er...> wrote:
> On Tue, 23 Dec 2008 16:19:53 -0800
> "Michael Abshoff" <mab...@go...> wrote:

Hi Burcin,

>> On Tue, Dec 23, 2008 at 3:36 PM, Michael Abshoff
>> <mab...@go...> wrote:
> <snip>
>> Hopefully we will upgrade to FLINT 1.1 during SD 12, but we will see
>> how that goes.
>
> Do you have an spkg for 1.1 already?

Nope, but it shouldn't be too hard to do. We need to fix some
dependency issues due to David's zn_poly, but other than that I wanted
to clean up spkg-install and spkg-check in Sage's flint.spkg since
they are pretty messy.

>  If you send it my way I can
> quickly see if the update breaks anything, and move ZZ[x] polynomials
> to use FLINT for factoring as well.

Cool.

> I will also wait for the updated spkg to push my zmod_poly wrapper
> upstream. The new derivative and factor methods will save me some time.

:)

> Cheers,
>
> Burcin

Cheers,

Michael

> ------------------------------------------------------------------------------
> _______________________________________________
> flint-devel mailing list
> fli...@li...
> https://lists.sourceforge.net/lists/listinfo/flint-devel
>

Re: [flint-devel] newlines in makefile

[Burcin E. <bu...@er...>]

On Tue, 23 Dec 2008 16:19:53 -0800
"Michael Abshoff" <mab...@go...> wrote:

> On Tue, Dec 23, 2008 at 3:36 PM, Michael Abshoff
> <mab...@go...> wrote:
<snip> 
> Hopefully we will upgrade to FLINT 1.1 during SD 12, but we will see
> how that goes.

Do you have an spkg for 1.1 already? If you send it my way I can
quickly see if the update breaks anything, and move ZZ[x] polynomials
to use FLINT for factoring as well.

I will also wait for the updated spkg to push my zmod_poly wrapper
upstream. The new derivative and factor methods will save me some time.

Cheers,

Burcin

[flint-devel] Testsuite failures of 1.0.20 on 32 bit platforms

[Michael A. <mab...@go...>]

Hi Bill,

while testing 1.0.20 I came across two test suite hangs/failures, both
of them 32 bit (OSX and Linux). All 64 bit tests worked fine.

The problems:

32 bit Linux:

Testing fmpz_poly_CRT()... ok
Testing fmpz_poly_gcd_subresultant()... ok
Testing fmpz_poly_gcd_modular()... FAIL!
Testing fmpz_poly_resultant()... ok
Testing fmpz_poly_2norm()... ok
Testing fmpz_poly_invmod_modular()...[hang]

[mabshoff@cicero sage-3.2.3.alpha0-cicero-gcc432]$ gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /usr/local/gcc-4.3.2/src/gcc-4.3.2/configure
--enable-languages=c,c++,fortran
--with-gmp=/usr/local/gmp-4.2.3/x86-Linux-fc8-gcc-4.3.1
--with-mpfr=/usr/local/mpfr-2.3.2/x86-Linux-fc8-gmp-4.2.3-gcc-4.3.1
--prefix=/usr/local/gcc-4.3.2/x86-Linux-fc8
Thread model: posix
gcc version 4.3.2 (GCC)


32 bit OSX 10.4:

Testing fmpz_poly_power_trunc_n()... ok
Testing fmpz_poly_content()... ok
Testing fmpz_poly_CRT_unsigned()... ok
Testing fmpz_poly_CRT()... ok
Testing fmpz_poly_gcd_subresultant()... ok
Testing fmpz_poly_gcd_modular()...[hang]

varro:~/sage-3.2.3.alpha0-varro mabshoff$ gcc -v
Using built-in specs.
Target: powerpc-apple-darwin8
Configured with: /var/tmp/gcc/gcc-5370~2/src/configure
--disable-checking -enable-werror --prefix=/usr --mandir=/share/man
--enable-languages=c,objc,c++,obj-c++
--program-transform-name=/^[cg][^.-]*$/s/$/-4.0/
--with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib
--build=powerpc-apple-darwin8 --host=powerpc-apple-darwin8
--target=powerpc-apple-darwin8
Thread model: posix
gcc version 4.0.1 (Apple Computer, Inc. build 5370)

I am poking around with valgrind to see if I can find anything.

Cheers,

Michael

Re: [flint-devel] newlines in makefile

[William H. <ha...@ya...>]

Thanks for the report.

I've merged this into FLINT 1.1.0 and FLINT 1.2-devel. As no one else is likely to have hit this problem yet and we just released a major version, I did not update the minor revision number. But I did update the CHANGELOG, effectively tacking the fix on to the end of the major revision.

Bill.

--- On Wed, 12/24/08, Michael Abshoff <mab...@go...> wrote:

> From: Michael Abshoff <mab...@go...>
> Subject: Re: [flint-devel] newlines in makefile
> To: "Development list for FLINT" <fli...@li...>
> Date: Wednesday, December 24, 2008, 11:19 AM
> On Tue, Dec 23, 2008 at 3:36 PM, Michael Abshoff
> <mab...@go...> wrote:
> > Hi Bill,
> >
> > I am just updating to FLINT 1.0.20 in Sage and I
> noticed an issue I
> > never reported upstream: src/makefile has DOS line
> endings, i.e. ^M.
> > This causes a BSD make to throw in the towel.
> >
> > One way to fix this via vim would be to to
> ":s/^M//g: :)
> 
> Ok, I got it all wrong and the problem was a patch I had
> that caused
> rejections, so please ignore this dumb mistake.
> 
> > subversion should also offer the option to convert all
> the newlines
> > automatically.
> >
> > Cheers,
> >
> > Michael
> 
> I just checked the diff I had for the makefile in Sage vs.
> vanilla and
> the only relevant change is this:
> 
> +libflint.dylib64: $(FLINTOBJ)
> +	$(CC) -m64 -single_module -fPIC -dynamiclib -o
> libflint.dylib
> $(FLINTOBJ) $(LIBS)
> +
> 
> I.e. I need to add an extra -m64 flag to get a 64 bit OSX
> dylib.
> 
> Hopefully we will upgrade to FLINT 1.1 during SD 12, but we
> will see
> how that goes.
> 
> Cheers,
> 
> Michael
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> flint-devel mailing list
> fli...@li...
> https://lists.sourceforge.net/lists/listinfo/flint-devel