Re: [lmi] Numerics

[Greg Chicares]

On 2016-05-02 14:53, Vadim Zeitlin wrote:
> On Mon, 2 May 2016 14:24:03 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> Over the weekend I was thinking about this discussion of a currency class,
> GC> and I'd like to move forward with this idea now.
> 
>  Great, I think it would be a nice improvement.

It's worth doing simply on principle, but I have concrete practical reasons:

- Regression tests sometimes change by one ulp, even if the only change is
rewriting a floating-point expression in a way that wouldn't matter for real
numbers but does matter for floating point. And a one-ulp discrepancy at an
early duration may grow exponentially due to compound interest. We're pretty
good at filtering those discrepancies out, but it would be better to prevent
them from arising in the first place.

- Regression-test results don't match between msw and GNU/Linux.

I think this change might help a lot in the first case, and I hope it may
help in the second as well.

> GC> On 2016-03-31 21:49, Vadim Zeitlin wrote:
> GC> > On Thu, 31 Mar 2016 17:01:36 +0000 Greg Chicares <address@hidden> wrote:
> GC> > 
> GC> > GC> On 2016-03-28 22:08, Vadim Zeitlin wrote:
> GC> [...discerning which variables represent currency in the problem 
> domain...]
> GC> >  This is the problem, from my point of view: it's not clear to me which
> GC> > ones are which (well, I guess the first one is relatively obvious as 
> lives
> GC> > are not supposed to be measured in cents, but all the rest are less so).
> GC> 
> GC> This problem domain is my specialty, so it's trivial for me to do this.
> GC> (I just can't do it right now, because I have to focus on this month's
> GC> release first.)
> 
>  If you could please let me know when will you be ready to work on this,
> I'll ensure that the currency class is available by then. Otherwise I'll
> just try to do it a.s.a.p.

Please write the currency class as soon as you find convenient. Then I'll be 
able
to change the types when enough time becomes available--I can't say whether that
will be this week, or next month.

> GC> > GC> It wouldn't be too hard to go through all the code and replace 
> "double" with
> GC> > GC> "currency" as appropriate.
> GC> > 
> GC> >  If you could do it, with currency just as a typedef for double, I could
> GC> > then reimplement currency as a class and do the tests. But it's this "as
> GC> > appropriate" part which is the most complicated and time-consuming IMHO.
> GC> 
> GC> Would you do that please? I.e.:
> GC>   "reimplement currency as a class and do the tests"
> 
>  Implementing the currency class is simple enough, but I'm not sure which
> tests do you mean. In the original email I was thinking about rerunning the
> existing test suite with the currency class used instead of "double", but
> right now it's not/won't be used anywhere yet,

I'll handle all the regression testing...

> so apart a unit test class
> for this class itself (which I'll write, but it will be pretty trivial), I
> don't see what could I test.

...if you'll write the unit test. I'm hoping that a unit test will prove the
lack of any runtime penalty. Other lmi unit tests use a high-precision timer
that might be useful here.

> Or would you like me to start replacing
> "double" with "currency" at least in the places I'm sure about too?

No, I'll do that.

> GC> >  I'm pretty sure there will be no abstraction penalty for using the
> GC> > currency class, any contemporary compiler is able to "look inside" such
> GC> > class and see that it's just an int and generate exactly the same code 
> for
> GC> > it as if it were just an int in the first place.
> GC> 
> GC> That's a surprise to me: I didn't know compilers had evolved that far.
> 
>  Oh, they have evolved much further than that, this is something that I
> fully expect any non-toy compiler to do since a long time and I'm quite
> sure MSVC, gcc and clang all do it. What I find impressive is that modern
> compilers (at least gcc and clang, I don't think MSVC does this, although I
> could be wrong) can de-virtualize virtual function calls, which is a pretty
> big optimization for tight loops. This really looks like magic, but it's
> real (see https://gcc.gnu.org/ml/gcc-patches/2013-09/msg00007.html and
> http://hubicka.blogspot.com/2014/01/devirtualization-in-c-part-1.html for
> the implementation and some explanations about how it works, respectively,
> if you're interested).

I am very interested, so thanks for those references.