[GSOC] summary of .BigInt library details.
hi all, thank you Scott McMurray, Vicente and Bruno for the prompt feedback regarding my proposed BigInt library ideas .(Sorry for the delayed reply as was busy with mid-semester exams.) In general this is what i have gathered from your responses regarding what exactly is being expected by the community from a BigInt library for Boost. 1. frontend based off Boost.Proto 2. backend implemented with the help of Boost libraries like Boost.Math. 3. probably provide two levels of implementations. ( although it would really help if you could weigh the pros and cons of both and eliminate one the the two) 3a. looking at bit-level implementation(less space and probably more execution time) 3b.) digit level manipulation (more space - and probably less execution time). i.e. for an n-digit number is it ok to use up [n/2 to n] bytes of space or necessary to stick to log n amount of space for a BigInt object. my questions are :- 1. Please give your feedback/concerns regarding the above design. 2. Any other libraries like Boost.Math which would help with the backend. -- Ankit Malpani 3rd Year Undergraduate | BE. (Hons) Computer Science BITS Pilani Goa Campus
Hi, I'm still not sure to understand about basing the frontend on Boost.Proto. Could anybody precise how would Proto be used here, and what it would bring exactly? Thanks Bruno
Bruno Lalande wrote:
Hi,
I'm still not sure to understand about basing the frontend on Boost.Proto. Could anybody precise how would Proto be used here, and what it would bring exactly?
Basiaclly, you will be able to build lazy expression made out of big int and delay its evalaution to proper affectation point or pass bigint expression w/o any evaluation to functiuon thus optimizing these. Moreover, with proper trasnform on those expression, you can exarct valuable information on the expected result and take compile-time decision on how to evaluate them.
OK I see, thanks. Ankit, if your goal is to create a brand new BigInt type, then your point 2 "backend implemented with the help Boost.Math" is not exactly valid. Boost.Math provides bindings, that is wrappers around existing arbitrary precision types provided by 3rd party libraries. It provides a way to write functions that can take either such types or fundamental types as parameter. So you wouldn't really *use* Boost.Math binding, it's even the contrary: ideally you would provide the necessary interface to ensure compatibility with Boost.Math bindings. As for the Proto frontend, something like that is not tight to this particular BigInt type but is something that would be useful for any backend actually. So it might rather make sense to implement that as an extra layer upon Boost.Math bindings so that any backend can leverage it. So to summarize, I can see 3 distinct actions: 1) implement your BigInt backend 2) provide a Boost.Math binding compliant interface for this backend 3) implement a frontend for Boost.Math binding based on Boost.Proto So 1)+2) can be one GSoC project, and 3) another one, actually. Makes sense? Bruno
On 1 April 2010 02:40, Bruno Lalande <bruno.lalande@gmail.com> wrote:
I'm still not sure to understand about basing the frontend on Boost.Proto. Could anybody precise how would Proto be used here, and what it would bring exactly?
For example, GMP has a function mpz_addmul(x,y,z) that we would rather write as x += y*z; My idea for the use of Boost.Proto is for its expression template transformation features to rewrite the easy-to-use syntax to take advantage of such optimized backend features. [1] http://gmplib.org/manual/Integer-Arithmetic.html#Integer-Arithmetic
"Ankit Malpani" <ankit.malpani@gmail.com> wrote in message news:g2lb62bde901003311142x72ebd559x56668269ae0107b@mail.gmail.com...
2. Any other libraries like Boost.Math which would help with the backend.
You can find links to LibTomMath and TomsFastMath libraries in this post: http://permalink.gmane.org/gmane.comp.lib.boost.devel/202443 unfortunately they are C libraries but are pretty complete and fast (SIMD code paths 'and all that')...they are sadly also no longer maintained but are left in the public domain so you can probably take just what you need and move on from there... -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman
participants (5)
-
Ankit Malpani -
Bruno Lalande -
Domagoj Saric -
Joel Falcou -
Scott McMurray