Re: [lmi] Replacing boost with std C++11

[Greg Chicares]

On 2017-01-20 23:10, Vadim Zeitlin wrote:
[...s/boost::bind/std::bind/...]
> if you do run into any
> problems with doing the straightforward replacement, it would, IMHO, be
> worth replacing boost::bind with something else entirely rather than
> leaving it be.

I'll try replacing boost::bind() with std::bind().

If that fails, I'll abort the task.

If it succeeds, then we should still replace std::bind() with something
better.

> On Fri, 20 Jan 2017 22:57:38 +0000 Greg Chicares <address@hidden> wrote:
> GC> And let's include std::transform() etc., too. For example:
> GC> 
> GC> // TODO ?? Replace these long lines with PETE expressions.
> GC>     // ET !! miscellaneous_charges += AmortLoad_ + ExtraSepAcctCharge_;
> GC>     std::transform(miscellaneous_charges.begin(), 
> miscellaneous_charges.end(), AmortLoad_         .begin(), 
> miscellaneous_charges.begin(), std::plus<double>());
> GC>     std::transform(miscellaneous_charges.begin(), 
> miscellaneous_charges.end(), ExtraSepAcctCharge_.begin(), 
> miscellaneous_charges.begin(), std::plus<double>());
> GC> 
> GC> Replacing the names with simpler ones, we have double-precision
> GC> vectors X, A, and B, and we wish to do this:
> GC>     X += A + B; // If we had the expressiveness of, say, FORTRAN.
> GC> which can be expressed tersely and elegantly in C++98 thus:
> GC>     std::transform(X.begin(), X.end(), A.begin(), X.begin(), 
> std::plus<double>());
> GC>     std::transform(X.begin(), X.end(), B.begin(), X.begin(), 
> std::plus<double>());
> GC> The question is whether to use PETE for that. That seemed like the
> GC> obvious thing to do years ago; I just never found the time.
> 
>  I don't think we need PETE for something as simple as this and I'm not
> sure if using it would still allow the compiler to auto-vectorize the loop
> as it would definitely do if we wrote an explicit one here. This is really
> compiler-dependent and, of course, only really matters for big vectors, but
> the benefits of auto-vectorization, i.e. of use of SIMD instructions to do
> the operation on several vector elements at once, are enormous, so if we
> really care about performance we simply must explore this.

Would you like to propose a patch to 'expression_template_0_test.cpp'
so that we can measure what you'd prefer against the other methods
already tested there? It tests array lengths of 10*{0, 1, 2, 3, 4, 5}.
It would be extremely interesting to see whether auto-vectorization
has obviated the need for expression templates.

Consider this change that I just committed:

diff --git a/ledger_base.cpp b/ledger_base.cpp
index 31eeb25..85dde59 100644
--- a/ledger_base.cpp
+++ b/ledger_base.cpp
@@ -447,11 +447,10 @@ void LedgerBase::ApplyScaleFactor(double a_Mult)
         }
     m_scale_unit = look_up_scale_unit(m_scaling_factor);
 
-    // TODO ?? Would be clearer with bind1st.
+    // ET !! *i.second *= M;
     std::vector<double>M(GetLength(), m_scaling_factor);
     for(auto& i : ScalableVectors)
         {
-        // ET !! *i.second *= M;
         std::vector<double>& v = *i.second;
         std::transform
             (v.begin() [... blah blah blah...]

The removed comment was not necessarily untrue. Here, we're multiplying
a vector by a scalar. Constructing a vector with the right number of
copies of that scalar just so we can use transform() for multiplication
is clearly undesirable; binding the scalar would be less awful, except
for the C++98 syntax. But the real question is whether we can write
something that's just as fast as expression templates, without needing
an expression-template library at all.

The other comment removed in a different hunk:

-// TODO ?? std::transform() might be cleaner.
     for(auto const& i : AllVectors)
         {
         crc += *i.second;
         }

had become kind of humorous; I mention it, though, to ask your opinion
of changing code like that, thus:

+     for(auto const& i : AllVectors) crc += *i.second;
-     for(auto const& i : AllVectors)
-         {
-         crc += *i.second;
-         }

when the resulting line is not too wide to punch on a single IBM 5081
card, so I can still use my Port-A-Punch if the power goes off, with
the incidental benefit that it looks nice in vim with a large font.

BTW, although I like vim, I've found that installing it has broken the
'u' and '/' keys in other programs. Now, in notepad-style editors,
pressing '/' inserts a literal slash, and 'u' doesn't undo it, so I
have to use the menus. Oddly enough, it didn't break 'less', and git
still seems to work fine.:wq