Hi all, The following should be of interest to many SAGE developers.
ANNOUNCEMENT Quietly for the past couple of months, a group of developers has been working towards a new version of GMP which can be used in SAGE and related projects. Q. Why wasn't I told about this? A. We've been gradually adding interested individuals to the development list: http://groups.google.com/group/mpir-devel Now that we have a core of interested people and the project looks viable, we are ready to have everyone on board. Q. What is it called? A. It's called mpir (multi precision integers and rationals), see http://www.mpir.org/ Q. What do you mean by "better" than GMP. A. There is no hard and fast answer to that question. Read the list for some suggestions. One of the answers is that it will be better for SAGE, but there are many concrete suggestions for how mpir can be better, such as better support for arrays of multiprecision integers, multithreaded support, better vendor support. Some more ways that it will be better are discussed below. Q. What license will it have? A. GPL v2 or above. This means that we are forking the last LGPL v2+ version of GMP, i.e. GMP 4.2.1. This licensing strategy is better for SAGE and other projects under GPL v2. As of version 4.2.2 of GMP the license became LGPL v3 which was a big problem for those projects. Q. What does Torbjorn Granlund (the GMP maintainer) think about this? A. Not sure. Torbjorn has worked really, really hard on GMP, and the code is terrifically tightly coded. GMP only exists because of him. It is his project. But we find it hard to use GMP because of license issues with the LGPL v3, because certain patches we want are incompatible with GMP, and because we have directions in mind for mpir which aren't really compatible with the current directions of that project (towards GMP 5). But I do know that Torbjorn said to me personally that he has no problem with people ripping code out of GMP and using it elsewhere. He fully supports principles of open source like this, and creating derivative works is one of those principles. We have hopes of excellent scientific relations with Torbjorn and his group. Q. What does the new version do already? A. We haven't actually done a whole lot of work yet, just a lot of planning! Actually all we did so far is copy in Core 2 patches and AMD 64 patches, which currently don't build, fix some c99 issues and write some documentation (in the doc/devel directory) in an attempt to better understand how GMP currently works, e.g. what all the undocumented macros do. Q. Who is in charge of this project? A. Development is completely open, so there is no one person in charge of this project. Currently Bill Hart and Jason Martin seem to be working together on some stuff. Michael Abshoff is in charge of release management and public relations. William Stein is putting his considerable weight behind the project and is in charge of getting us access to some really fantastic hardware to do build testing on. Q. What are the plans for mpir? A. Read the list. Most of what is there is later contradicted, but here is a vague summary of the outcome of various discussions: 1) Get Jason Martin's Core 2 patches building as part of the build procedure (no hacks allowed). 2) Get Pierrick Gaudry's AMD 64 patches building as part of the build procedure (no hacks allowed). 3) Remove some of the Cray and x86 hacks from header files like gmp.h where they don't belong. 4) Write a new simplified build system (no autoconf allowed). Bill Hart is currently working on this. The old build system will be retained, but will only build the legacy code. Eventually more architectures will be migrated to the new build system. 5) Rewrite the x86 assembly to use NASM (possibly FASM, but there is a bootstrapping issue with the source code for that, NASM is written in C, so no bootstrapping problems there). 6) Get rid of M4 as the macro language on all migrated architectures, use assemblers native to those machines. 7) Rewrite assembly support for other machines and add assembly support for new architectures. 8) Write a new mpir_n module to replace the old mpn module. The old mpn module will be retained for legacy architectures and the new mpir_n module will promise to supply macros which provide all the old mpn interface. Basically mpir must be interface compatible with the old GMP to as great an extent as possible. Jason Martin has expressed and interest in working on this. 9) Rewrite the generic C mpn functions to use the new mpir_n functions where necessary. The old generic mpn functions will be retained. 10) Start adding code for parallel functionality. Modules will be called blah-mt. There can be parallel functions at the mpir_n and the mpz level. Jason Martin and Bill Hart are keen to work on this at some point. 11) There will be a new fmpz module in GMP. It will be for arrays of multiprecision integers. Please see the extensive list conversations about this. It is also much more efficient for integers of at most 62 bits (or 30 bits on a 32 bit machine). The functions in the mpz module will be split into core functions and wrappers. The core functions will be used by both the mpz wrappers (which will provide the original mpz functionality) and the new fmpz wrappers to provide the fmpz functions. Bill Hart has written proof of principle code for fmpz as a concept and will soon begin working on putting it into mpir. Talk to him if you are interested in this. Q. How do I contribute? A. Please sign up to the development list. Make a proposal to the list, ask for people to help, then be prepared to take charge of implementing your idea. If you would like to contributed to one of the existing objectives, contact the people working on those ideas. All code should be released under the "GPL v2 or at your option any later version". You do not need to sign your copyright over to the Free Software Foundation or any other organisation. You retain the copyright to your code. Q. What principles guide mpir development? A. Here are some: 1) Coding should be very tight. GMP is incredibly carefully coded, most functions not wasting a single cycle. We should follow suit. 2) Speed regressions are not allowed. We have not got a decent profiling mechanism yet, so for the time being we are just testing our code tirelessly to make sure it is not slower than vanilla GMP. This is very important when it comes to the many architectures GMP uses (and frankly a very hard thing to do). 3) Test code must do randomised testing of many, many random inputs, using the sparse integer random functions where possible and must test every *branch* of your function multiple times in a standard test run. 4) Documentation should always be up-to-date. This consists of three components: a) in-code commenting of any algorithms used and where appropriate, papers referred to. Any special performance hacks should be commented in place. b) User documentation. If your function is visible to a user, the mpir user manual needs a section describing exactly what your function does. c) Developer documentation. If your function should be used by mpir developers, documentation should be written for them and placed in the doc/devel directory. Text format should be fine, so long as the file is labelled in an appropriate way. The developer documentation should give hints as to your general strategy, and what you'd put in user documentation if the function were visible to the user. No function will make it into a release of mpir unless it has been documented, performance tested, test code is written for it and passes and it has been build tested on all relevant supported platforms. The reason for this is that we want mpir to be used by lots of other projects and they want to know it is as reliable and fast as GMP. Q. Where can I get it? A. Currently if you type: svn co http://flint.svn.sourceforge.net/svnroot/flint/mpir-1.0.0 you will get a copy from the repository. The repository may be moved later. Although the fmpz module was an outgrowth of the FLINT project, there is no other connection with FLINT. It's just a convenient place to put the repo for now. This version should compile, but it is not a release version. As soon as we move to a release, it'll be available on the webpage. At that time we'll move the code to mpir-trunk in the repository and that will be the default place to get the development code. We hope to make a conservative first release quite soon. Writing a simplified build system is the main obstacle. Any volunteers? We think a python build system may be better, where available. Q. What about Apple and Microsoft support? A. We want to support Apple's XCode and Microsoft's MSVC as first class citizens and are willing to work around linker/compiler issues to a reasonable extent. Watch the list for further discussion of this. Q. What is the relationship with SAGE? A. Some of the same people. It'll be used by SAGE. Some companies interested in funding SAGE ports see it as part of SAGE. It developed as a spinoff of the SAGE project. Q. But what if I'm not a SAGE developer? A. Great! Welcome. Q. What if I am a SAGE developer? A. Great! Welcome. Q. What is the voting policy. A. Currently, post your suggestion to the list. If anyone is concerned enough about what you propose, they'll let you know. If not, after a couple of days, you can assume everyone who cares has had their say. Provided there weren't serious objections, you can assume it is safe to proceed. Later when there are more developers, the procedure will be formalised. --~--~---------~--~----~------------~-------~--~----~ 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://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
