Re: [boost] [Review] XInt Review

Subject: Re: [boost] [Review] XInt Review
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2011-03-09 15:11:13

Joel Falcou wrote:
>> Granted, proto has a number of very nice features.  The question is,
>> would xint benefit from them?  Does this library require transforms
>> and or multiple passes?  I certainly hope not.  The default operator
>> precidence happens to the one we want in this case (as far as I
>> understand) so what is the point of defining a grammar for operator
>> expressions to achieve what would happen by default without one?     
>> 
>> Please correct me if I am wrong.
>> 
>> 
> For me the inetrest if on function composition optimization.
> 
> Let's say you have the ln and gamma function operating on your type
> (silly example but take any too function who ends up with a large gap
> of 
> bits for representing the reuslt).
> 
> Calling ln(gamma(x)) in a regular library will give you a quite large
> value (and reuqire slotsa bits) and you'll shrink it through the log,
> havign allcoated new bits for no real gain.
> 
> Now make it proto based and have a ruel matching tree of (ln -- gamma
> -- 
> x) and transform it into gammaln(x) with a better, less bits intensive
> version.
> Less bits allocated, more pecise result.
> 
> This is some example and I think a substantial amount cna be found.
> Now, 
> make it properly so you can add special case liek that outside and you
> have an extensible optimization point.

I agree that something like that could be done, and there are plenty of other AST transformations we would make to improve even simple arithmetic expressions written by the user, but I'm not convinced we should.  If the user is able to write the optimal expression himself then my view is that a library does not need to optimize the user's suboptimal expressions.  If the user sees a problem with the expression he wrote (uses too much memory, runs too long) he can fix it himself.  As a user I would not expect the library to optimize my expressions for me, nor would I trust it to do so even if it claimed in its documentation that it does unless I understood the details of what it can or cannot do, which isn't something I would want to invest time in.

We need to set a reasonable expectation for what the library should do.  These exact same types of optimizations could be applied to my Polygon library expression templates, but I judged it to be not worthwhile.  The common case for use of the expression template is a single operation and even in complex expressions that don't get broken across multiple statements the opportunity for improving on what was written is the exception, not the rule, and easily done manually by the user.  Implementing a compiler as a template metaprogram is exactly what I want to avoid in this case.  Every user will pay the compilation cost imposed by the abstraction, while few will benefit and those most in need of benefit are the ones who will optimize their expression by hand and benefit least.

Regards,
Luke