Re: [boost] [XInt] Some after thoughts

Subject: Re: [boost] [XInt] Some after thoughts
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2011-03-10 14:14:32

falcou wrote:
> Ok, as the ET based rambling went nowhere and some people (especially
> Steven)
> had some valid point on the simplicity of the underlying
> representation, i 
> am about
> to propose the following plan. The premises still are that I believe
> that 
> at some point
> an ET layers is worthwhile. So here it is:
> 
> 1/ restructure XInt so a generic way to access to the needed
> internals of 
> the big integer representation
> through a terse Concept providing way to specify how to store and
> retirvee bits o.
> 
> 2/ Build the xinteger_t type on top of this generic layer.
> 
> Let's stop here. At this point, we fulfill needs expressed by Chad and
> Steven: a simple and
> generic large integer library ready to be used. Now this I can see as
> a 
> very valid candiate to
> be accepted right now. So now, what's going afterward ?
> 
> By using the concept and interface, we ( and by we, maybe I mean only
> me 
> for the moment) can
> do the following:
> 
> 3/ implement a EDSL on top of the interface defined in 1/ By reusing
> the 
> low level memory and computation interface
> we can build a ET-enabled large integer that behave the same way than
> the original large integer type in 2/ but allow us to
> add "fancy" optimisations
> 
> 4/ Have a way to say large integer use SIMD register of 128 bits and
> implement a SIMD aware large integer
> 
> Or any combination of 3+4 or any other similar extension.
> 
> So, can the effort required by 1/ (definition of a minimal concept 
> for handling representation of large integer) and 2/
> seems valid ? I think this actually gives everything to everyone : the
> simplicity concerned public and the "fancy" public.
> Of course, the only thing Chad may have to do is 1+2, leaving 3+ to
> people interested to provide such extension later.
> 
> How does it sound ?

I support this idea.  Having an expert do the ET is a good plan, and since you know proto you can feel free to use it to the full extent you see fit.  Big integer expression templates is exactly the sort of thing proto was intended to address.  My only objection was forcing Chad to use proto, and it wasn't as strong of an objection as came across yesterday, I just got a little over enthusiastic since I find this subject matter very engaging.  My rehtorical devices could have as easly been turned in the other direction, and my argument was strongly worded, but weak.  Taking an idea to its extreme and burning a strawman doesn't prove anything.

Throughout this review I never saw anyone make the case for COW that seems most relevant to me.  Most usage of built in integer types in a generic context uses pass by value explicitly rather than using the type traits.  This means that libraries like ratio and random or whatever else will probably pass multi-precision integer types by value in all of their functions.  COW is the only way to mitigate all that copying around.  Perhaps this was so obvious or covered so early in the review that it went unstated recently, but I think ET on COW enabled (or COW+move enabled) objects is a perfectly valid design choice.  We need ET code to have access to the low level algorithms so that it can make optimizations such as stack allocation of temporaries, of course.  It is cleaner if the library providees a good interface for that access.

Regards,
Luke