[sage-devel] Re: a 7(!) year old (Singular) overflow issue still holds
On Monday, 10 October 2016 12:31:25 UTC+2, Dima Pasechnik wrote: > > > > On Sunday, October 9, 2016 at 4:48:31 PM UTC, Bill Hart wrote: >> >> >> >> On Sunday, 9 October 2016 18:08:29 UTC+2, Dima Pasechnik wrote: >>> >>> >>> >>> On Sunday, October 9, 2016 at 3:35:57 PM UTC, Bill Hart wrote: By default, Singular uses 16 bit exponents. But it is perfectly capable of working with exponents up to 64 bits. That will be slower of course. why? I presume arithmetic on 16-bit integers is not faster than on >>> 32-bit, or even 64-bit. >>> >> >> It's the exponent arithmetic, not the coefficients we are talking about. >> > > sure - I was thinking about univariate case; in the multivariate case, if > you want fast arithmetic on exponents of monomials given as integer vectors > in year 2016, you probably would want to use GPU > > >> The exponents are packed, with four 16 bit field in a 64 bit word. This >> is *much* faster. I use the same trick, as does just about every decent >> computer algebra system out there. >> >> Interestingly, Magma only allows exponents up to about 30 bits, but it >> takes a few minutes to compute x^(2^30 - 1). >> > > I wonder why this happens - a Flint issue? : > > sage: R.=QQ[] > sage: x^(2^30)-1 > Exception (FLINT memory_manager). Unable to allocate memory. > I'm not precisely sure why that happens. How much memory did you have available on your machine? This should create the polynomial x, then try to raise it to the power of 2^30, which is about a billion I think. Along the way it will use the FFT, which is a bit of a memory hog. One day we ought to fix the powering code to handle monomials separately. It is 2016 after all. > sage: x^(2^30-1) > Killed > > (which appears to indicate that the recovery from the exception was not > complete) > > On the other hand: > > sage: timeit('x^(2^20-1)') > 125 loops, best of 3: 1.66 ms per loop > sage: 2^20-1 > 1048575 > sage: timeit('x^1048575') > 125 loops, best of 3: 1.66 ms per loop > sage: timeit('x^10') > 625 loops, best of 3: 381 ns per loop > sage: 2^30-1 > 1073741823 > sage: timeit('x^1073741823') > 5 loops, best of 3: 1.72 s per loop > sage: timeit('x^(2^30-1)') > 5 loops, best of 3: 1.71 s per loop > > but then > > sage: x^(2^30-1) > > at 0x7fbb07bd7910>) failed: MemoryError> > > There's some caching in Flint I guess, though I'm not entirely sure why that would matter here. Bill. > > looks quite strange... > Dima > > >> >>> >>> >>> I guess it isn't easy for Sage to change the relevant ring upon overflow to one using 64 bit exponents. I can't say whether it would be easy or hard for Singular to automatically change the exponent size for you. For basic arithmetic, I have implemented precisely this in the code I've been writing. But Singular is almost infinitely more complex than the very simple cases I've been dealing with in my own code. At this stage I couldn't even hazard a guess. I'll ask Hans if I remember. But either way, I believe this would be an *extremely* time consuming thing to fix. How important is it? Bill. On Wednesday, 5 October 2016 01:10:31 UTC+2, Jakob Kroeker wrote: > > > https://trac.sagemath.org/ticket/6472 > > even for recent singular upgrade > > https://trac.sagemath.org/ticket/17254 > > and it was not(?) reported to upstream... > > > > > > > > > > > > > > > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: NTL v10
I looked at the singular patch, regarding the use of nothrow new. I dug up "ticket #852" which lead to that patch. In all honesty, it looks like singular is doing something wrong, so "fixing" NTL is just the wrong thing to do. So I won't implement that patch in NTL. This is a problem that should be fixed in singular, if it hasn't been already. On Saturday, October 8, 2016 at 4:21:14 PM UTC-4, Victor Shoup wrote: > > I hope this is of some interest to the Sage community. > I've just released a new version of NTL at http://www.shoup.net/ntl > > Here is a summary of changes. > > *New License: LGPLv2.1* > >- With the permission of all relevant contributors, NTL is now >licensed under LGPLv2.1+ (the Lesser GNU Public License version 2.1 or >later). >- Previously, NTL was licensed under the GPL. This new, less >restrictive licensing should hopefully increase the impact of NTL. > > > *Long integer package restructuring* > >- I've restructured the long integer package so that the GMP and >"classical LIP" modules share much of the same code base. >- This greatly reduces the amount of redundant code, which will make >maintenance easier moving forward. >- As a bonus, the classical LIP module is simpler, faster, and >(finally) thread safe. >- As another bonus, the GMP module now is much closer to being >compatible with "non-empty nails". Although it has not been tested in that >mode as of yet, it may eventually be helpful in the future if I want to >replace some GMP code with code that exploits AVX-512 IFMA instructions. >- As a part of this transition, "make check" now includes much more >extensive "unit testing" of the long integer package. >- Despite the drastic changes "under the hood", this restructuring >should not affect at all any NTL client code that relies only on the >documented interface, including even the ancient legacy interfaces >pre-dating NTLv5a from 2000. > > > *File name restructuring* > >- I've renamed all the ".c" files to ".cpp" files in the Unix >distribution. This seems to be more in line with common practice, and >should make it easier to work with compilers and other software > development >tools. > > > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: a 7(!) year old (Singular) overflow issue still holds
See also the comments in https://trac.sagemath.org/ticket/12589 -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] NTL v10
And actually I said some stuff without revisiting what is done in Gentoo and in sage and I am not sure which one is overkill anymore. I inherit cruft from someone else (possibly me in the past). I need to sort it out. To go back to: Second, in the patch, you write $(LINK) $(LIBTOOL_FLAGS) whereas it seems to me more logical to put $(LIBTOOL_FLAGS) $(LINK) I think libtool is able to figure it regardless of the order. This flag is only used for cygwin in sage. It is then set to “-no-undefined” which is definitely recognised as a special argument for -mode=link and it will be treated specially. But the libtool manual doesn’t say it has to be specified before or after the “linking” command. People are more comfortable with it being part of the linking command I guess. I’d say the way it is done in the patch is the most usual way to do it. François > On 11/10/2016, at 13:26, Victor Shoup wrote: > > Anyway, like I said, I'm pretty much done, modulo a couple > of things that I asked about two posts above. > Hopefully, someone can clarify those points soon, > and then there will be a distribution of NTL that does > not require any patching :-) > > On Monday, October 10, 2016 at 8:16:17 PM UTC-4, François wrote: > Autotools is nicer for a lot of things. sage does patch > to use libtools and I stayed away from that in Gentoo. > The main advantage as far as I am concerned is that it makes > it easier to produce shared libraries, correctly on a variety > of platforms. Just for linux, and OS X, you don’t strictly > need to do that but it is a good investment in the future. > > In that regard the current sage solution is a bit of a halfway point. > You really should couple it with automake and autoconf but that’s > more work. > > But we should have pestered you about make/$(MAKE) a lot more > as it is a much bigger sin ;) > > François > > > On 11/10/2016, at 13:03, Victor Shoup wrote: > > > > First, you are definitely wrong about punch cards. I started programming > > with Fortran on punch cards in the 70s. > > > > Second, a complete transition to auto tools still feels like overkill at > > this point. > > But I agree that it could come one day. > > In any case, I am almost done with all the requested changes. > > I will follow up with a couple of quick questions, though. > > > > On Monday, October 10, 2016 at 5:09:48 PM UTC-4, Dima Pasechnik wrote: > > > > > > On Monday, October 10, 2016 at 9:09:38 PM UTC+1, François wrote: > > On 11/10/16 01:58, Victor Shoup wrote: > > > Another issue. I'm not sure if $(MAKE) is specific to gnu make or if it > > > is universal. > > > In general, I don't want to assume gnu. But I can certainly make this the > > > default, > > > and provide a config variable to override. > > > > I'll have another go at this when you use > > $(MAKE) inside a makefile you are making sure > > that the make command used is the same one that > > you called on the initial makefile. > > > > As other people mentioned it enable parallel make > > to proceed nicely, and in the case where there is > > several make command installed on the system > > you avoid funny things happening. I have AIX > > system which comes with its own posix make > > command. Something like ntl probably require > > gmake (GNU make), calling AIX make in the > > middle is not a good idea. > > > > > > Perhaps the most natural solution would be to change NTL build system so > > that > > it uses the standard autotools chain (autoconf/automake etc), not only > > libtool. > > Given that it uses very few external libraries, it ought to be an easy > > task. > > > > Given that I am perhaps the only person in this thread who learned to > > program using punch cards, > > I am a dinosaur from an earlier period, yet, I look into the future :-) > > > > Dima > > > > > > > > Francois > > > > -- > > You received this message because you are subscribed to the Google Groups > > "sage-devel" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to sage-devel+...@googlegroups.com. > > To post to this group, send email to sage-...@googlegroups.com. > > Visit this group at https://groups.google.com/group/sage-devel. > > For more options, visit https://groups.google.com/d/optout. > > > -- > You received this message because you are subscribed to the Google Groups > "sage-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-devel@googlegroups.com. > Visit this group at https://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.co
Re: [sage-devel] NTL v10
Anyway, like I said, I'm pretty much done, modulo a couple of things that I asked about two posts above. Hopefully, someone can clarify those points soon, and then there will be a distribution of NTL that does not require any patching :-) On Monday, October 10, 2016 at 8:16:17 PM UTC-4, François wrote: > > Autotools is nicer for a lot of things. sage does patch > to use libtools and I stayed away from that in Gentoo. > The main advantage as far as I am concerned is that it makes > it easier to produce shared libraries, correctly on a variety > of platforms. Just for linux, and OS X, you don’t strictly > need to do that but it is a good investment in the future. > > In that regard the current sage solution is a bit of a halfway point. > You really should couple it with automake and autoconf but that’s > more work. > > But we should have pestered you about make/$(MAKE) a lot more > as it is a much bigger sin ;) > > François > > > On 11/10/2016, at 13:03, Victor Shoup > > wrote: > > > > First, you are definitely wrong about punch cards. I started programming > > with Fortran on punch cards in the 70s. > > > > Second, a complete transition to auto tools still feels like overkill at > this point. > > But I agree that it could come one day. > > In any case, I am almost done with all the requested changes. > > I will follow up with a couple of quick questions, though. > > > > On Monday, October 10, 2016 at 5:09:48 PM UTC-4, Dima Pasechnik wrote: > > > > > > On Monday, October 10, 2016 at 9:09:38 PM UTC+1, François wrote: > > On 11/10/16 01:58, Victor Shoup wrote: > > > Another issue. I'm not sure if $(MAKE) is specific to gnu make or if > it is universal. > > > In general, I don't want to assume gnu. But I can certainly make this > the default, > > > and provide a config variable to override. > > > > I'll have another go at this when you use > > $(MAKE) inside a makefile you are making sure > > that the make command used is the same one that > > you called on the initial makefile. > > > > As other people mentioned it enable parallel make > > to proceed nicely, and in the case where there is > > several make command installed on the system > > you avoid funny things happening. I have AIX > > system which comes with its own posix make > > command. Something like ntl probably require > > gmake (GNU make), calling AIX make in the > > middle is not a good idea. > > > > > > Perhaps the most natural solution would be to change NTL build system so > that > > it uses the standard autotools chain (autoconf/automake etc), not only > libtool. > > Given that it uses very few external libraries, it ought to be an easy > task. > > > > Given that I am perhaps the only person in this thread who learned to > program using punch cards, > > I am a dinosaur from an earlier period, yet, I look into the future :-) > > > > Dima > > > > > > > > Francois > > > > -- > > You received this message because you are subscribed to the Google > Groups "sage-devel" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to sage-devel+...@googlegroups.com . > > To post to this group, send email to sage-...@googlegroups.com > . > > Visit this group at https://groups.google.com/group/sage-devel. > > For more options, visit https://groups.google.com/d/optout. > > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] NTL v10
Autotools is nicer for a lot of things. sage does patch to use libtools and I stayed away from that in Gentoo. The main advantage as far as I am concerned is that it makes it easier to produce shared libraries, correctly on a variety of platforms. Just for linux, and OS X, you don’t strictly need to do that but it is a good investment in the future. In that regard the current sage solution is a bit of a halfway point. You really should couple it with automake and autoconf but that’s more work. But we should have pestered you about make/$(MAKE) a lot more as it is a much bigger sin ;) François > On 11/10/2016, at 13:03, Victor Shoup wrote: > > First, you are definitely wrong about punch cards. I started programming > with Fortran on punch cards in the 70s. > > Second, a complete transition to auto tools still feels like overkill at this > point. > But I agree that it could come one day. > In any case, I am almost done with all the requested changes. > I will follow up with a couple of quick questions, though. > > On Monday, October 10, 2016 at 5:09:48 PM UTC-4, Dima Pasechnik wrote: > > > On Monday, October 10, 2016 at 9:09:38 PM UTC+1, François wrote: > On 11/10/16 01:58, Victor Shoup wrote: > > Another issue. I'm not sure if $(MAKE) is specific to gnu make or if it is > > universal. > > In general, I don't want to assume gnu. But I can certainly make this the > > default, > > and provide a config variable to override. > > I'll have another go at this when you use > $(MAKE) inside a makefile you are making sure > that the make command used is the same one that > you called on the initial makefile. > > As other people mentioned it enable parallel make > to proceed nicely, and in the case where there is > several make command installed on the system > you avoid funny things happening. I have AIX > system which comes with its own posix make > command. Something like ntl probably require > gmake (GNU make), calling AIX make in the > middle is not a good idea. > > > Perhaps the most natural solution would be to change NTL build system so that > it uses the standard autotools chain (autoconf/automake etc), not only > libtool. > Given that it uses very few external libraries, it ought to be an easy task. > > Given that I am perhaps the only person in this thread who learned to program > using punch cards, > I am a dinosaur from an earlier period, yet, I look into the future :-) > > Dima > > > > Francois > > -- > You received this message because you are subscribed to the Google Groups > "sage-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-devel@googlegroups.com. > Visit this group at https://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] NTL v10
I am almost done with everything!! I have just a couple of remaining questions. First, I am having a hard time understanding why singular is having a hard time with the definition of NTL_NEW_OP. It is defined that way for a reason, and this is completely standard C++ (standard, as in C++98). Could somebody explain what is going on? The suggested patch, here https://github.com/sagemath/sage/blob/master/build/pkgs/ntl/patches/new_singular.patch is not really the correct semantics. Second, I have two questions about the libtool flags patch, here: https://github.com/sagemath/sage/blob/master/build/pkgs/ntl/patches/libtool_flag.patch First, it would seem more logical to me to have a different flag for each libtool mode (i.e., compile, link, etc). That is easy enough to do. Does that seem right? Or is one global flag OK (but it will get added to every invocation of libtool). Second, in the patch, you write $(LINK) $(LIBTOOL_FLAGS) whereas it seems to me more logical to put $(LIBTOOL_FLAGS) $(LINK) so that the libtool flags come towards the beginning of the invocation of libtool. Otherwise, these are acting more like compiler flags. Maybe it would be much clearer if I knew what the typical use case of LIBTOOL_FLAGS actually was. Thanks! The sooner you clarify the issues, the sooner I can release the patched up version. I'm already done with all the other libtool and $(MAKE) issues. On Monday, October 10, 2016 at 5:58:05 AM UTC-4, Jean-Pierre Flori wrote: > > Thanks for the hint, we are already a few versions behind. > > I've opened #21676 for us to update, if anyone wants to review it: > * https://trac.sagemath.org/ticket/21676#ticket > > By the way we are still shipping a few patches, have a look at: > * https://github.com/sagemath/sage/blob/master/build/pkgs/ntl/patches/ > > I'd say the most annoying one is: > * > https://github.com/sagemath/sage/blob/master/build/pkgs/ntl/patches/configure.ac > We're just making an empty autotool project, running autoreconf, and > repackaging your tarball so that it provides its own version of libtool. > (All of this is done by this script: > * https://github.com/sagemath/sage/blob/master/build/pkgs/ntl/spkg-src > ) > Indeed some systems do not provide any "default" libtool script. > > And surely the following one is about using $MAKE rather than make in your > makefile: > * > https://github.com/sagemath/sage/blob/master/build/pkgs/ntl/patches/make.patch > Its purpose is quite obvious :) > > And finally, giving the ability to pass flags to libtool: > * > https://github.com/sagemath/sage/blob/master/build/pkgs/ntl/patches/libtool_flag.patch > This is useful when building on cygwin/mingw where libtool wants an > -no-undefined flag to even try to build a shared lib (without it it does > not even try). > > Best, > JPF > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] NTL v10
First, you are definitely wrong about punch cards. I started programming with Fortran on punch cards in the 70s. Second, a complete transition to auto tools still feels like overkill at this point. But I agree that it could come one day. In any case, I am almost done with all the requested changes. I will follow up with a couple of quick questions, though. On Monday, October 10, 2016 at 5:09:48 PM UTC-4, Dima Pasechnik wrote: > > > > On Monday, October 10, 2016 at 9:09:38 PM UTC+1, François wrote: >> >> On 11/10/16 01:58, Victor Shoup wrote: >> > Another issue. I'm not sure if $(MAKE) is specific to gnu make or if it >> is universal. >> > In general, I don't want to assume gnu. But I can certainly make this >> the default, >> > and provide a config variable to override. >> >> I'll have another go at this when you use >> $(MAKE) inside a makefile you are making sure >> that the make command used is the same one that >> you called on the initial makefile. >> >> As other people mentioned it enable parallel make >> to proceed nicely, and in the case where there is >> several make command installed on the system >> you avoid funny things happening. I have AIX >> system which comes with its own posix make >> command. Something like ntl probably require >> gmake (GNU make), calling AIX make in the >> middle is not a good idea. >> >> > Perhaps the most natural solution would be to change NTL build system so > that > it uses the standard autotools chain (autoconf/automake etc), not only > libtool. > Given that it uses very few external libraries, it ought to be an easy > task. > > Given that I am perhaps the only person in this thread who learned to > program using punch cards, > I am a dinosaur from an earlier period, yet, I look into the future :-) > > Dima > > > > Francois >> > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] NTL v10
On Monday, October 10, 2016 at 9:09:38 PM UTC+1, François wrote: > > On 11/10/16 01:58, Victor Shoup wrote: > > Another issue. I'm not sure if $(MAKE) is specific to gnu make or if it > is universal. > > In general, I don't want to assume gnu. But I can certainly make this > the default, > > and provide a config variable to override. > > I'll have another go at this when you use > $(MAKE) inside a makefile you are making sure > that the make command used is the same one that > you called on the initial makefile. > > As other people mentioned it enable parallel make > to proceed nicely, and in the case where there is > several make command installed on the system > you avoid funny things happening. I have AIX > system which comes with its own posix make > command. Something like ntl probably require > gmake (GNU make), calling AIX make in the > middle is not a good idea. > > Perhaps the most natural solution would be to change NTL build system so that it uses the standard autotools chain (autoconf/automake etc), not only libtool. Given that it uses very few external libraries, it ought to be an easy task. Given that I am perhaps the only person in this thread who learned to program using punch cards, I am a dinosaur from an earlier period, yet, I look into the future :-) Dima Francois > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] NTL v10
On 11/10/16 01:58, Victor Shoup wrote: Another issue. I'm not sure if $(MAKE) is specific to gnu make or if it is universal. In general, I don't want to assume gnu. But I can certainly make this the default, and provide a config variable to override. I'll have another go at this when you use $(MAKE) inside a makefile you are making sure that the make command used is the same one that you called on the initial makefile. As other people mentioned it enable parallel make to proceed nicely, and in the case where there is several make command installed on the system you avoid funny things happening. I have AIX system which comes with its own posix make command. Something like ntl probably require gmake (GNU make), calling AIX make in the middle is not a good idea. Francois -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] NTL v10
About the make variable... I can definitely see it's utility with make -j... I would guess that's the main advantage, and that's easy enough to fix in the makefile itself. The other calls to make from other scripts are a bit more problematic. Would you say they are a priority? And if so, would one assume that a user would set the environment variable MAKE? As I understand it, in gnuc make, the variable MAKE is not an ordinary environment variable. It is a special variable with extra magic specific to make (including -j magic). -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] NTL v10
Hum sorry I did not read the previous posts completely. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] NTL v10
Using MAKE also let you trigger parallel build for subtargets with MAKE="make -j128". Given the current use of make within the makefile it is not really the case. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Giving Sage AI-based step-by-step equation solving abilities
Matthieu wrote: > Is this solver works only for systems of linear equations ? The solver I am writing is based on an AI program written in the 1970s named PRESS (PRolog Equation Solving System), and PRESS was designed to solve R Elementary equations, which can contain polynomial, trigonometric, exponential and logarithmic functions. I have not implemented all of PRESS's capabilities in my solver yet, but I am in the process of doing so. Ted -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] NTL v10
On 2016-10-10 16:13, Victor Shoup wrote: One more question, relating to $(MAKE). There are a number of scripts besides the makefile that also invoke make. Should these also be modified? But then the mechanism would have to be different (environment variable?). Before I can sort that out, I would like to know what is the goal here? Is system make really not used in some environments? Or is there some magic in $(MAKE) within a makefile that is being used? If the latter, then I can probably just keep the other invocations of make are OK as is. In other scripts, I think that "$MAKE" is mainly used to allow using a different version of make. For example, some systems might have a GNU make (installed as gmake) and a non-GNU make (installed as make). The MAKE environment variable can be set to the chosen make variant. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] NTL v10
On Monday, October 10, 2016 at 3:53:34 PM UTC+2, Victor Shoup wrote: > > Let me get this straight... > You say that the tarball does not contain a libtool script, but rather, > contains a directory that contains files that will build a libtool script > at compile time. Is that right? Which tarball? NTL tarball does not contain anything providing libtool, it relies on the availibility of a systemwide one, which is not standard, but can be provided by installing some packages as John does. Unfortunately the mondane user will just feel lost and won't be able to perform this step (or does not want to pollute her system with yet another package). The repackaged tarball Sage ships contains: * the verbatim content of the NTL upstream tarball in a ntl folder, * an additional libtool folder where you can run "./configure" to produce a "libtool" script. Note that all that is contained in this folder was produced running autoreconf on a configure.ac file on a "development" machine. Then when one want to build Sage and its version of ntl on her machine, the "configure" script is run and produces a "libtool" script to be used by the compilation chain in the ntl folder. So you could call this step configuration time or compilation time. What is sure is that calling the "configure" script is performed on the machine where NTL will be compiled, not on the machine where "autoreconf" was run to produce "configure" and "ltmain.sh" from the quite empty "configure.ac". In fact running "configure" on the "development" machine rather than on the "compilation" machine, maybe hoping to provide a universal libtool script, would be wrong. The "configure" and "ltmain.sh" scripts made by autoreconf are meant to be portable, the "libtool" script they produce is much less. So maybe the answer to your question is "yes": the best solution would be that the ntl upstream tarball contains waht is needed to produce the libtool script on the machine where ntl will be compiled. And the answer to the question "how to produce that stuff easily and without changing all of ntl build system" is: * make a quite empty autotools project, that is a configure.ac file like the one at: $ https://github.com/sagemath/sage/blob/master/build/pkgs/ntl/patches/configure.ac * modify ntl's configure script to run the configure script that will be produced by autoreconf at distribution time * modify the ntl's makefile to use the libtool script that will be produced by configure * when you want to ship a new release: $ run autoreconf where configure.ac $ make your tarball Another option would be to migrate all ntl build system to autotools but that would be much more time consuming... with the above steps you just hack to get a portable way to produce a libtool script (and not relying anymore on the user installing a system wide one). -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] NTL v10
One more question, relating to $(MAKE). There are a number of scripts besides the makefile that also invoke make. Should these also be modified? But then the mechanism would have to be different (environment variable?). Before I can sort that out, I would like to know what is the goal here? Is system make really not used in some environments? Or is there some magic in $(MAKE) within a makefile that is being used? If the latter, then I can probably just keep the other invocations of make are OK as is. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] NTL v10
Let me get this straight... You say that the tarball does not contain a libtool script, but rather, contains a directory that contains files that will build a libtool script at compile time. Is that right? -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] NTL v10
On 10 October 2016 at 14:46, Victor Shoup wrote: > Ok, thanks. I will try to get this done this week. Your explanation was very > helpful. Hopefully, I can piece together a solution based on the scripts you > pointed to in your previous reply. > > I admit, I've been quite a dinosaur when it comes to autotools stuff...when I > started, none of this really existed, and at any particular point in time, it > seemed easier to "roll my own" scripts than to figure out autotools. In the > short term, I will probably not change too much, but I agree that this > libtool issue really needs to be fixed. > Note from another dinosaur: I have my own notes to help me install pari, mpir, mpfr, flint and ntl on a new machine, propr to being able to work on eclib. And in the NTL section (only!) there's a line (You may need to now do "sudo apt install libtool-bin") John > -- > You received this message because you are subscribed to the Google Groups > "sage-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-devel@googlegroups.com. > Visit this group at https://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] NTL v10
Ok, thanks. I will try to get this done this week. Your explanation was very helpful. Hopefully, I can piece together a solution based on the scripts you pointed to in your previous reply. I admit, I've been quite a dinosaur when it comes to autotools stuff...when I started, none of this really existed, and at any particular point in time, it seemed easier to "roll my own" scripts than to figure out autotools. In the short term, I will probably not change too much, but I agree that this libtool issue really needs to be fixed. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] NTL v10
On Monday, October 10, 2016 at 2:58:38 PM UTC+2, Victor Shoup wrote: > > Ok, I will start working on these issues. The one I understand the least > is libtool. > It looks like you are saying I should generate a libtool script on the > machine X on which > I create the NTL tarball. But this seems very strange. How could that > script be any better > than one generated/installed on the machine Y where the build is taking > place? > Wouldn't it be better to generate libtool on Y? > > And why isn't there a libtool command on Y in the first place? > I mean, if you assume the whole autoconf toolchain, why not assume libtool? > That's the point: you should not assume any part of the autotools chain present, that's not needed nor the way it is supposed to be used. Autotools is a great way to autogenerate boring stuff as conifgure scripts and Makefiles. So it is meant to be run on the developer machine and what it generates (typically: configure script from configure.ac, Makefile.in form Makefile.am, some m4 macro stuff, and a ltmain.sh script which will be used to generate the libtool script!) is supposed to be portable enough, shipped with the distributed tarball, and should run with no issues on the machine where NTL actually gets compiled. For example, have a look at the gmp "devel" source tree: https://gmplib.org/repo/gmp/file/tip There is only (among related stuff) a configure.ac file at the top level and Makefile.am files in subdirectories. But in the "distributed" source tarball where "autoreconf -fiv" or equivalent stuff has been run also includes configure, ltmain.sh and so on. To come back to NTL, you only used the libtool script, you don't need all the autotools machinery, but you currently assume that this script is available system wide, which is not that common. So what we do in Sage is the following at distribution time: * create a fake autotools project (mostly a quite empty configure.ac file) * run autoreconf on it which produces mainly a configure script, an ltmain.sh script and a few other things. * include its output along with your source in a separate libtool directory At compilation time: * we go into this libtool directory and run the configure script which uses ltmain.sh and makes a libtool script * we go back to ntl directory and run make passing the generated libtool script to it (through LIBTOOL envvar). It looks a little bit overkill but that's the way autotools stuff works... Note that the configure script generated here does almost nothing, mostly only creating the libtool script on the compilation machine! And that's the only thing we need to build ntl. Or, is it that maybe there are parts of the toolchain that are X but not Y? > > Sorry...I'm not much of an expert on libtool or autoconf. > > Another issue. I'm not sure if $(MAKE) is specific to gnu make or if it is > universal. > In general, I don't want to assume gnu. But I can certainly make this the > default, > and provide a config variable to override. > I cannot answer on the top of my head, so it might be broken with some strange make versions :) -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] NTL v10
Ok, I will start working on these issues. The one I understand the least is libtool. It looks like you are saying I should generate a libtool script on the machine X on which I create the NTL tarball. But this seems very strange. How could that script be any better than one generated/installed on the machine Y where the build is taking place? Wouldn't it be better to generate libtool on Y? And why isn't there a libtool command on Y in the first place? I mean, if you assume the whole autoconf toolchain, why not assume libtool? Or, is it that maybe there are parts of the toolchain that are X but not Y? Sorry...I'm not much of an expert on libtool or autoconf. Another issue. I'm not sure if $(MAKE) is specific to gnu make or if it is universal. In general, I don't want to assume gnu. But I can certainly make this the default, and provide a config variable to override. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Is Brown's construction available in the graph component of sagemath?
On Sunday, October 9, 2016 at 9:10:50 PM UTC, ni732...@gmail.com wrote: > > Brown's construction is the function which takes a finite field to a graph > with diameter 2. > http://www.emis.ams.org/journals/EJC/Surveys/ds14.pdf > > Is it available in the graph component of sagemath? > I won't be surprised if it could be constructed as a subgraph of one of many strongly regular graphs known to Sage, but there is no direct way to build such a graph in Sage, IMHO. The description of the adjacency in the link you provide is a bit too brief to see what exactly it does, but I think these graphs are also known as Erdős–Rényi graphs, from P. Erdós, A. Rényi, V.T. Sós On a problem of graph theory Studia Sci. Math. Hungar., 1 (1966), pp. 215–235 Brown's paper was published in the same year: W.G. Brown On graphs that do not contain a Thomsen graph Canad. Math. Bull., 9 (1966), pp. 281–285 We published a paper where these graphs were considered, and I implemented a construction of them in GAP, but not in Sage :-) https://www.cs.ox.ac.uk/publications/publication7266-abstract.html Please feel free to cc me on the Sage ticket with an implementation, I'd be glad to review it. Dima > If not, I plan to implement it for sagemath. > > yawara > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Is Brown's construction available in the graph component of sagemath?
On Sun, Oct 9, 2016 at 4:59 PM, wrote: > Brown's construction is the function which takes a finite field to a graph > with diameter 2. > http://www.emis.ams.org/journals/EJC/Surveys/ds14.pdf > > Is it available in the graph component of sagemath? I don't know but the Paley graph construction is in Sage. Is that related to what you are talking about? You might look in the graphs/generators/families.py module. > If not, I plan to implement it for sagemath. > > yawara > > -- > You received this message because you are subscribed to the Google Groups > "sage-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-devel@googlegroups.com. > Visit this group at https://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: a 7(!) year old (Singular) overflow issue still holds
On Sunday, October 9, 2016 at 4:48:31 PM UTC, Bill Hart wrote: > > > > On Sunday, 9 October 2016 18:08:29 UTC+2, Dima Pasechnik wrote: >> >> >> >> On Sunday, October 9, 2016 at 3:35:57 PM UTC, Bill Hart wrote: >>> >>> By default, Singular uses 16 bit exponents. But it is perfectly capable >>> of working with exponents up to 64 bits. That will be slower of course. >>> >>> why? I presume arithmetic on 16-bit integers is not faster than on >> 32-bit, or even 64-bit. >> > > It's the exponent arithmetic, not the coefficients we are talking about. > sure - I was thinking about univariate case; in the multivariate case, if you want fast arithmetic on exponents of monomials given as integer vectors in year 2016, you probably would want to use GPU > The exponents are packed, with four 16 bit field in a 64 bit word. This is > *much* faster. I use the same trick, as does just about every decent > computer algebra system out there. > > Interestingly, Magma only allows exponents up to about 30 bits, but it > takes a few minutes to compute x^(2^30 - 1). > I wonder why this happens - a Flint issue? : sage: R.=QQ[] sage: x^(2^30)-1 Exception (FLINT memory_manager). Unable to allocate memory. sage: x^(2^30-1) Killed (which appears to indicate that the recovery from the exception was not complete) On the other hand: sage: timeit('x^(2^20-1)') 125 loops, best of 3: 1.66 ms per loop sage: 2^20-1 1048575 sage: timeit('x^1048575') 125 loops, best of 3: 1.66 ms per loop sage: timeit('x^10') 625 loops, best of 3: 381 ns per loop sage: 2^30-1 1073741823 sage: timeit('x^1073741823') 5 loops, best of 3: 1.72 s per loop sage: timeit('x^(2^30-1)') 5 loops, best of 3: 1.71 s per loop but then sage: x^(2^30-1) ) failed: MemoryError> looks quite strange... Dima > >> >> >> >>> I guess it isn't easy for Sage to change the relevant ring upon overflow >>> to one using 64 bit exponents. >>> >>> I can't say whether it would be easy or hard for Singular to >>> automatically change the exponent size for you. For basic arithmetic, I >>> have implemented precisely this in the code I've been writing. But Singular >>> is almost infinitely more complex than the very simple cases I've been >>> dealing with in my own code. At this stage I couldn't even hazard a guess. >>> >>> I'll ask Hans if I remember. But either way, I believe this would be an >>> *extremely* time consuming thing to fix. How important is it? >>> >>> Bill. >>> >>> On Wednesday, 5 October 2016 01:10:31 UTC+2, Jakob Kroeker wrote: https://trac.sagemath.org/ticket/6472 even for recent singular upgrade https://trac.sagemath.org/ticket/17254 and it was not(?) reported to upstream... -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Giving Sage AI-based step-by-step equation solving abilities
Hello Ted, Is this solver works only for systems of linear equations ? If it is the case, why do you need an AI ? Is a standard Gauss algorithm not sufficient ? Cheers Matthieu 2016-10-09 20:40 GMT+02:00 David Joyner : > On Sun, Oct 9, 2016 at 2:20 PM, Ted Kosan wrote: > > David wrote: > > > >> I think a graphical version of this would be useful as a sage-based > >> online high school math tutorial program, such as the khan academy > >> algebra modules. > > > > Are either of the following examples close to what you have in mind?: > > > > http://data.ssucet.org/temp/solve_steps_example.png > > > > This doesn't seem to have anything. > > > https://www.youtube.com/watch?v=cy6bwNBkAK0 > > > > Not quite. I'm just talking about an automated system to help a create > student hint (like webassign has). A student goes through a khan > academy assignment, gets stuck, and they click a "help" button (which > would then call your program to create a series of graphics) to see > how a similar problem is solved step-by-step. > > > Ted > > > > > > > > -- > > You received this message because you are subscribed to the Google Groups > > "sage-devel" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to sage-devel+unsubscr...@googlegroups.com. > > To post to this group, send email to sage-devel@googlegroups.com. > > Visit this group at https://groups.google.com/group/sage-devel. > > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "sage-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-devel@googlegroups.com. > Visit this group at https://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] NTL v10
Thanks for the hint, we are already a few versions behind. I've opened #21676 for us to update, if anyone wants to review it: * https://trac.sagemath.org/ticket/21676#ticket By the way we are still shipping a few patches, have a look at: * https://github.com/sagemath/sage/blob/master/build/pkgs/ntl/patches/ I'd say the most annoying one is: * https://github.com/sagemath/sage/blob/master/build/pkgs/ntl/patches/configure.ac We're just making an empty autotool project, running autoreconf, and repackaging your tarball so that it provides its own version of libtool. (All of this is done by this script: * https://github.com/sagemath/sage/blob/master/build/pkgs/ntl/spkg-src ) Indeed some systems do not provide any "default" libtool script. And surely the following one is about using $MAKE rather than make in your makefile: * https://github.com/sagemath/sage/blob/master/build/pkgs/ntl/patches/make.patch Its purpose is quite obvious :) And finally, giving the ability to pass flags to libtool: * https://github.com/sagemath/sage/blob/master/build/pkgs/ntl/patches/libtool_flag.patch This is useful when building on cygwin/mingw where libtool wants an -no-undefined flag to even try to build a shared lib (without it it does not even try). Best, JPF -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.