[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lmi] _M_range_check fails when running "new" PDF
From: |
Greg Chicares |
Subject: |
Re: [lmi] _M_range_check fails when running "new" PDF |
Date: |
Sat, 17 Feb 2018 19:32:22 +0000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 |
On 2018-02-17 18:22, Vadim Zeitlin wrote:
> On Fri, 16 Feb 2018 03:22:56 +0000 Greg Chicares <address@hidden> wrote:
>
> GC> On 2018-02-15 10:51, Greg Chicares wrote:
> GC> [...]
> GC> > I have an idea to try next, but I'll try it before writing about it.
> GC>
> GC> Use the same technique that works in 'ledger_text_formats.cpp':
> GC> commit fcd7e6a04. This calls for a refactoring, to consolidate
> GC> the dispersed instances of this technique into a single function,
> GC> but I don't have time for that yet.
>
> I think you referred to the refactoring done by the recent commits here,
Yes.
> and, using the latest sources, I can't reproduce the original problem any
> more and I do see -100% in the IRR current/guaranteed columns if I add them
> to the illustration in the preferences window,
Yes, this being an inforce case, all IRRs should be set to -100%, and
that's what I observe on both the calculation summary and the PDF.
> so I just wanted to ask if
> this means that the problem is fully fixed now by your changes or if there
> is anything that still remains to be done by me?
I can't think of anything else for either of us to do about this
_M_range_check anomaly.
[lmi] IRRs really are costly [Was: _M_range_check fails when running "new" PDF], Greg Chicares, 2018/02/14