[sage-devel] Re: multi_polynomial_element add/sub slower than mul?!?
That is good news. CoCoALib will hopefully get generic field extensions over the summer. We already do Weyl Algebras and there is code for non-commutative monoids, even though that code isn't in the trunk yet and it is uncertain when it will be finished. Another interesting thing we are actively working on are differential algebras. Interesting, I might start looking into noncommutative algebra soon, so it is interesting to know that there is a variety of code out there. Btw: Am I right to assume that CoCoALib only supports basic polynomial arithmetic over Z_n? Could you define basic in this context? Does it compute a Gröbner basis (AFAIK: no)? Does it allow to do a reduction modulo an ideal basis (e.g. if I know I have a Gröbner basis)? LCM, GCD? As opposed to adding and multiplying. Sorry for replying so late, I am going through my mail just now. Martin -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x8EF0DC99 _www: http://www.informatik.uni-bremen.de/~malb _jab: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: multi_polynomial_element add/sub slower than mul?!?
On 5/5/07, mabshoff [EMAIL PROTECTED] wrote: Ok, I did discuss that with Max Coboara a couple month back and GBasis computation over rings is a medium size project for him. He stated that he needed a diophantic solver for CoCoALib. Linbox provides one and I have been working on fixing bugs in Linbox, so we are very close to integrate Linbox with CoCoALib shortly. I will remind Max soon that those pesky geometry people really would like to compute GBases over rings ;) Excellent. I'm all for more cooperation between CoCoaLib and Linbox, since both will be standard components in SAGE. Regarding Linbox: The svn snapshot in 2.5.0alpha2 is about 6 weeks old and juding from the svn log it seems to be a good idea to update. The last two times I tried the svn version was broken. The version included in SAGE was the result of Clement Pernet being at SAGE Days 3 and spending several days fixing bugs and build issues. As soon as linbox development moved forward past then, it became broken in various way fairly quickly. I reported all the issues I had, so maybe they are fixed now. Another taks I would suggest is also adding make check to the build script because that would obviously greatly expand the testing base for the Linbox code. This would increase the build time of that spkg very much, but at least we can catch build issues and/or bugs much ^^ Running make check will not be the *default* for builds, but I have been planning to introduce some form of this for a while. However, I intend to have optional scripts spkg-check in each sage package, that would be run after spkg-install succeeds and before the temp build directory is deleted. Then if one builds using make buildcheck SAGE would build each package and run spkg-check. If one builds with just plan make then none of the spkg-check's get run. earlier. There is also now two google groups for Linbox: linbox-use and linbox-devel, so if you are interested please check them out. Excellent! Another package which should also do a make check is gmp because it is famous for being miscompiled, especially on MacOSX. I can package those two spkgs with the suggested changes if William would like me to. I am not sure if there are dedicated maintainers to individual spkgs in SAGE at the moment. Best would be for you to send me an spkg-check script for each. William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: multi_polynomial_element add/sub slower than mul?!?
Excellent. I'm all for more cooperation between CoCoaLib and Linbox, since both will be standard components in SAGE. Ok, when Martin and I initially compared the mvpolynomial performance of singular vs. CoCoALib singular was 3 times faster for something like xyz*xyz, when squaring a polynomial with two monomials that dropped down to a factor of 1.5. Now I have figured out how to avoid a copy constructor and a couple other optimizations so that we can give singular a run for its money ;). I will get back to the code after 2.5. The more interesting things in CoCoALib are the approximate Buchberger Möller and Module/Ideal operations. Regarding Linbox: The svn snapshot in 2.5.0alpha2 is about 6 weeks old and juding from the svn log it seems to be a good idea to update. The last two times I tried the svn version was broken. The version included in SAGE was the result of Clement Pernet being at SAGE Days 3 and spending several days fixing bugs and build issues. As soon as linbox development moved forward past then, it became broken in various way fairly quickly. I reported all the issues I had, so maybe they are fixed now. Ok, I tried 1.1.3r2701 on three different platforms and all tests passed, Clement fixed a bug in 1.1.3r2699 that caused problems in test- rank. Do you use your own testcases or how do you determine that there were issues? If you have your own code you can send them to me and I can take a look. I have been getting more and more familiar with the code and I am currently testing 1.1.3r2701 with valgrind. My goal is to fix all know issues that valgrind points out over the next months or so that I can do the port of Linbox to MSVC 2005. I am reluctant to port code to Windows when there are known issues because I prefer debugging on Linux :) Another taks I would suggest is also adding make check to the build script because that would obviously greatly expand the testing base for the Linbox code. This would increase the build time of that spkg very much, but at least we can catch build issues and/or bugs much ^^ Running make check will not be the *default* for builds, but I have been planning to introduce some form of this for a while. However, I intend to have optional scripts spkg-check in each sage package, that would be run after spkg-install succeeds and before the temp build directory is deleted. Then if one builds using make buildcheck SAGE would build each package and run spkg-check. If one builds with just plan make then none of the spkg-check's get run. Great. Can we also add something that builds the packages without optimizations and with debug info so that debugging would get easier? Is there also a way to finish the compilation and installation of a spkg that had a build failure? I am currently stuck on cygwin with libsingular and I can build it manually and run spkg-install, but when I restart the build process with make it starts rebuild singular from scratch :(. If I get it installed manually I can move forward while waiting on somebody else to fix the build. earlier. There is also now two google groups for Linbox: linbox-use and linbox-devel, so if you are interested please check them out. Excellent! Another package which should also do a make check is gmp because it is famous for being miscompiled, especially on MacOSX. I can package those two spkgs with the suggested changes if William would like me to. I am not sure if there are dedicated maintainers to individual spkgs in SAGE at the moment. Best would be for you to send me an spkg-check script for each. Will do. I am still working on an updated gdmodule that no longer uses different Setup.py[.cygwin] William Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: multi_polynomial_element add/sub slower than mul?!?
On 5/5/07, mabshoff [EMAIL PROTECTED] wrote: Regarding Linbox: The svn snapshot in 2.5.0alpha2 is about 6 weeks old and juding from the svn log it seems to be a good idea to update. The last two times I tried the svn version was broken. The version included in SAGE was the result of Clement Pernet being at SAGE Days 3 and spending several days fixing bugs and build issues. As soon as linbox development moved forward past then, it became broken in various way fairly quickly. I reported all the issues I had, so maybe they are fixed now. Ok, I tried 1.1.3r2701 on three different platforms and all tests passed, Clement fixed a bug in 1.1.3r2699 that caused problems in test- rank. Do you use your own testcases or how do you determine that there were issues? My test case is to build the SAGE linbox package, then run the SAGE test suite. I also have a lot of randomized testing of linear algebra via my modular symbols package. If you have your own code you can send them to me and I can take a look. I'll try the latest svn and take a look myself. It's very easy to build the new linbox package, and it has some great things I really want to include in SAGE, e.g., Clement's new super-fast charpoly routine. If anything doesn't work I'll email both you and Clement. I have been getting more and more familiar with the code and I am currently testing 1.1.3r2701 with valgrind. My goal is Excellent! Another taks I would suggest is also adding make check to the build script because that would obviously greatly expand the testing base for the Linbox code. This would increase the build time of that spkg very much, but at least we can catch build issues and/or bugs much ^^ Running make check will not be the *default* for builds, but I have been planning to introduce some form of this for a while. However, I intend to have optional scripts spkg-check in each sage package, that would be run after spkg-install succeeds and before the temp build directory is deleted. Then if one builds using make buildcheck SAGE would build each package and run spkg-check. If one builds with just plan make then none of the spkg-check's get run. Great. Can we also add something that builds the packages without optimizations and with debug info so that debugging would get easier? How about a script spkg-debug which is run instead of spkg-install if present and if one builds SAGE using make sagedebug. This could be very complicated to maintain in general. E.g., when new versions of packages come out, instead of just updating spkg-install (which can already be incredibly complicated -- the spkg-install for singular), one also would have to do the same with spkg-debug. It also means that I have to run make sagedebug and make sure everything works on a whole bunch of different architectures after every package update before any new release of SAGE.Adding spkg-debug's and properly maintaining them would significantly increase the workload for making new SAGE releases, so it won't happen unless someone volunteers to help with it. Is there also a way to finish the compilation and installation of a spkg that had a build failure? I am currently stuck on cygwin with libsingular and I can build it manually and run spkg-install, but when I restart the build process with make it starts rebuild singular from scratch :(. If I get it installed manually I can move forward while waiting on somebody else to fix the build. The simplest answer is that if the package is called, e.g., foo-2.4.5, then if you just do (from SAGE_ROOT) touch spkg/installed/foo-2.4.5 SAGE will henceforth assume that package was successfully installed. So, after doing . local/bin/sage-env and getting your package installed, just do touch as above, and you're good to go. Best would be for you to send me an spkg-check script for each. Will do. I am still working on an updated gdmodule that no longer uses different Setup.py[.cygwin] Thanks. -- William Stein Associate Professor of Mathematics University of Washington http://www.williamstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: multi_polynomial_element add/sub slower than mul?!?
Oliver Wienand (TU Kaiserslautern, Singular Team) [EMAIL PROTECTED] writes: Okay, I looked into the issue. In the top version from Singular of the repository now has a not yet fully tested polynomial arithmetic for Z/ n with the following functions: Hi Oliver, Where is the Singular repo? I can't find a CVS head anywhere on the site. Is it private? (gasp!) Nick --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: multi_polynomial_element add/sub slower than mul?!?
I am a member of the Singular group and working on standard bases over rings. Therefore as a test case we have implemented standard bases for Z/2^n[x_1,...x_k] and the corresponding polynomial arithmetic. As we plan to allow this computations for Z/n[x_1,...,x_k], we will implement corresponding polynomial arithmetic. If this is of interest for you, I can bring forward this implementation in the schedule. It is not really difficult, as Z/2^n is present. The minor points are handling division, gcd and lcm. At the moment, we allow division by zero divisors, if possible, even if it may not be unique. ... Oliver Wienand --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: multi_polynomial_element add/sub slower than mul?!?
Okay, I looked into the issue. In the top version from Singular of the repository now has a not yet fully tested polynomial arithmetic for Z/ n with the following functions: 1) +, -, * of polynomials and numbers 2) where possible / and inverses of numbers (polynomials by monomials just a matter of a few adaptions) (div by zero divisors is allowed, as long as possible) 3) gcd, lcm of numbers (in Z/n) Uses the same API as arithmetic for polynomials over fields. If somebody has access to the repository version, you need to compile Singular with #define HAVE_RING2TOM #define HAVE_RINGMODN in mod2.h. You can use the new coefficients with: ring r = (modnat, 200), x, dp; == Z/200[x] or ring r = (modpow, 2, 13), x, dp; == Z/2^13[x] ... Oliver --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: multi_polynomial_element add/sub slower than mul?!?
Oliver Wienand (TU Kaiserslautern, Singular Team) [EMAIL PROTECTED] writes: Okay, I looked into the issue. In the top version from Singular of the repository now has a not yet fully tested polynomial arithmetic for Z/ n with the following functions: Thank you, Singular Team! I will use this in the somewhat-near future. Nick --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: multi_polynomial_element add/sub slower than mul?!?
(3) SAGE-2.5 will have the first version of an optimized wrapper for arithmetic using the Singular C++ library directly, which Martin Albrecht wrote. It only supports QQ and GF(p) though. This is only temporary, I/it will support CC, RR, and GF(q) soon. If other base rings - Singular is capable of - are requested, I will implement those too. Same goes for the term orderings as well: Right now my wrapper only speaks the four term orderings also the native MPolynomials understand, but I will add block orderings soon. If more sophisticated term orderings are requested by anyone, I will add those. 4) Maybe Martin could add support for polynomials over Z/nZ to his libsingular interface, or at least discuss what might be involved. I think this would mean to implement Z/nZ in libCF and exposing that to SINGULAR. Also, I don't know how much it - SINGULAR - assumes the base ring is a field, so adding a ring might introduce a bunch of safety checks (something the SINGULAR people will never accept upstream for performance reasons, I guess) Martin -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x8EF0DC99 _www: http://www.informatik.uni-bremen.de/~malb _jab: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: multi_polynomial_element add/sub slower than mul?!?
On May 2, 3:17 pm, Martin Albrecht [EMAIL PROTECTED] wrote: This gives you F_241 - as fas as I know singular returns the ring F_p with p the next smallest prime if n is composite. Here instead of F_243 you get F_241. I do not know if you can actually get F_n with n composite in singular, but Martin probably knows. AFAIK you are right, I will ask the SINGULAR team, though. Great, I thought that Michael Brickenstein does follow sage-devel - at least he is a member of this group. shameless plugCoCoALib can do multivariate polynomial arithmetic in Z_n, the bindings Martin and I wrote (well mostly Martin) only do QQ at the moment, but Z_n is just a copy and paste job once the bindings have been fleshed out./shameless plug This is not a shameless plug, it is a pretty good point! Given the number of number theorists involved with SAGE being able to compute over base rings (not fields) is something quite useful. That is good news. CoCoALib will hopefully get generic field extensions over the summer. We already do Weyl Algebras and there is code for non-commutative monoids, even though that code isn't in the trunk yet and it is uncertain when it will be finished. Another interesting thing we are actively working on are differential algebras. Btw: Am I right to assume that CoCoALib only supports basic polynomial arithmetic over Z_n? Could you define basic in this context? Anyway, I suggest to focus on Z_n for the CoCoALib wrapper. This makes the project much more appealing than writing another wrapper for QQ where SINGULAR seems faster right now. For the moment that is true. I haven't talked to the people in Genoa about this yet, but if we can get rid of the copy constructor in the return I am quite confident that the distance to singular will become quite small. Once 2.5 is out I want to revisit the whole multivariate polynomial arithmetic benchmark because at that point we can compare native python vs. the other two implementations. Thoughts? Martin -- name: Martin Albrecht _pgp:http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x8EF0DC99 _www:http://www.informatik.uni-bremen.de/~malb _jab: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
