
I had a look upon the BigInt code from the sandbox. It's entirely wrapped around GMP(linked to gmblib). #inlcude<gmp.h> #ifdef BOOST_BIGINT_HAS_GMP_SUPPORT #include <boost/bigint/bigint_gmp.hpp> namespace boost { typedef bigint_base<detail::bigint_gmp_implementation> bigint; } I also read the LGPLicense which the GMP library carries with itself. This is my inference : The bigint code(from the boost sandbox) could be addressed in LGPL terms as "An Application" : which LGPL defines "as any work that makes use of an interface provided by the Library, but which is not otherwise based on the Library.", since it just uses the gmp.h interface and linking to gmplib. So the combined work, application and GMP, should be conveyed with a GNU GPL license. The Boost License allows skipping the copyright notices if only it's executables are used, unlike the LGPL which requires to distribute it's license. And there are even restrictions on "conveying the object code under terms of your(Boost') choice", in addition to other restrictions. That is uncompatible with the Boost license, which hinders the distribution of a Boost_bigInt library which wholly is a wrapper around GMP. Keeping in view the above issues what should be our priority? Improving the wrapping around GMP for time being or Starting Boost's own version of BigInt. I see mixed reactions on this subject. My personal opinion is that suggested by Paul A. Bristow, i.e, of a Boost's own BigInt, which I think is in line with Boost's long term aspirations. I hope my understanding of the issue is correct. I would be grateful to receive suggestions and comments which would help my GSOC proposal for BigInt, which I plan to submit as early as possible. -- Problem is a phenomenon indicating lack of thought. Swagat Konchada

swagat konchada wrote:
I had a look upon the BigInt code from the sandbox. It's entirely wrapped around GMP(linked to gmblib).
[snip]
That is uncompatible with the Boost license, which hinders the distribution of a Boost_bigInt library which wholly is a wrapper around GMP.
Keeping in view the above issues what should be our priority? Improving the wrapping around GMP for time being or Starting Boost's own version of BigInt. I see mixed reactions on this subject. My personal opinion is that suggested by Paul A. Bristow, i.e, of a Boost's own BigInt, which I think is in line with Boost's long term aspirations.
The issue, as you note, is that Boost.BigInt cannot be tightly coupled to GMP because it triggers a licensing problem for Boost. Instead, GMP should be one among multiple back ends supported by Boost.BigInt unless BigInt aims to reimplement what GMP and its ilk have already provided. (That brings rise to comments regarding popularity and vendor attention to such libraries. BigInt could become sufficiently popular to gain the necessary attention to become as efficient as GMP, but that will be a long and uphill climb. OTOH, if BigInt becomes a standard library, then it will be up to vendors to optimize it, so Boost.BigInt only has to be "good enough," in terms of performance, to reach that status.) The usual idea is that BigInt would provide expression templates and other optimizations to avoid calling the back end engine inefficiently. That may require an adapter layer between the user-visible BigInt API and the computation engine, like GMP, at the back end, to insulate the API from differences in the back end engines. (Then again, there may be nothing left to a layer above the adapter layer; I'm not saying there must be three layers.) If GMP is an optional back end supported by BigInt, along with other back ends, controlled by conditional compilation, then a BigInt user can choose to use GMP if they like, but the licensing issue will be theirs and not Boost's. HTH, _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

Hi, On Mon, Mar 29, 2010 at 12:50 PM, Stewart, Robert <Robert.Stewart@sig.com> wrote:
[...] (That brings rise to comments regarding popularity and vendor attention to such libraries. BigInt could become sufficiently popular to gain the necessary attention to become as efficient as GMP, but that will be a long and uphill climb. OTOH, if BigInt becomes a standard library, then it will be up to vendors to optimize it, so Boost.BigInt only has to be "good enough," in terms of performance, to reach that status.) [...]
I just would like to reinforce to GSoC applicants and mentors that creating a BigInt lib from scratch would be a really great project, but by the time limitations from GSoC a great project may end up in a great unfinished project. So, if you are going to apply in the BigInt project idea, please be realistic. It would be a shame to see another unfinished library (and somewhat abandoned or decentralized) like Boost.Process in GSoC. -- Felipe de Oliveira Tanus E-mail: fotanus@gmail.com Blog: http://www.itlife.com.br Site: http://www.inf.ufrgs.br/~fotanus/ ----- "All we have to decide is what to do with the time that is given us." - Gandalf
participants (3)
-
Felipe Tanus
-
Stewart, Robert
-
swagat konchada