Re: [lmi] Calculation summary and costly IRR calculations

[Evgeniy Tarassov]

On 10/18/06, Greg Chicares <address@hidden> wrote:
> The quick answer is that we should suppress the IRR calculations
> when (and only when) generating the calculation summary. They are

Thank you! Understood. It is already implemented locally.

> I would imagine that optimization would make little difference.
> If you already happen to know whether it does or does not, then
> I'd be (academically) interested in knowing that.

No, i haven't tried to optimize that code. But i will be happy to try
to someday if you want me to.

> Suppose you suppress CalculateIrrs(). Then can you tell me about
> how many milliseconds it takes for the calculation summary to
> appear? It's sufficient to know the first decimal digit of the
> mantissa (and the whole exponent, of course).
[..]
> To calibrate that measurement (because our computers aren't
> likely to run at exactly the same speed), please also say what
> you see on the status bar when running an illustration this way:
>
>  - File | New | Illustration
>  - OK [ignore what the status bar says this first time]
>  - Illustration | Edit
>  - OK [say what the status bar says now]

Strangly, times does not change for me (almost) when i regenerate the
summary with Ctrl-E (your instructions above). It is:
| Calculate: 420 milliseconds; XML: 279 milliseconds; Format: 315 milliseconds

where XML and Format is xml generation time and its transformation
into html respectivly.

> I'd also be interested in knowing what platform you're using for
> these measurements: GNU/Linux, msw, or whatever.

I'm using mingw on Windows XP64.

> Perhaps we should expand the status-bar report, e.g.
>   Calculate: XXX milliseconds; Format: YYY milliseconds
> That would make it easy to quantify any perceived difference in
> speed between the old and new calculation summaries.

Done in the form of "Calculate: XXX milliseconds; XML: YYY
milliseconds; Format: ZZZ milliseconds".

> > Of course it brings some complications such as not being able to use
> > variables "IrrCsv" and "IrrDb" in HTML and TSV. We could also check
> > that these columns are present (or absent) in the supplemental_report
> > section and switch to the light or heavy version of xml.
>
> Maybe we should just decide that no IRR will be shown on the
> calculation summary--or, if an IRR is requested, it'll be
> shown as zero there, which I would guess is what your local
> tree does right now anyway.

Yes, it does show 0, but i think it will be more correct to show
something like 'NaN' instead to emphasize that IrrCsv and IrrDb are
not available. I will correct it -- it is a simple modification to
html.xsl file.

> That brings up another question: how should we express which
> columns are to be displayed on the calculation summary? I had
> originally thought of using a separate xml file--today's
> 'configurable_settings.xml':
>   <calculation_summary_columns>
>     some_column_name
>     some_other_column_name
>     ...
>   </calculation_summary_columns>
> That's very flexible, but requires editing the xml, which may be
> more than we want to ask end users to do.
>
> However, it sounds like you've come up with the idea of using the
> supplemental-report column selections for the calculation
> summary. That makes it easy for end users to change the

Oh, i'm a little bit confused -- maybe i have missed that on the mailing list.
Currently in my local tree the supplemental report section is not used
at all in the calculation summary. The column list to show is
specified in the same xslt file that generates it. For example:
html.xsl contains a node:
<xsl:variable name="show_columns_xml">
   <column name="Outlay" />
   <column name="AcctVal"     basis="run_guar_basis" />
  ...
</xsl:variable>

that specifies which columns do we want in the calculation summary html page.

It could easily be changed (it is as hard as to add/modify 2-3 lines
of code in .xsl file) to use the supplemental_columns section from
output.xml file (the ledger xml data).

Another possibility could be to show both columns defined in html.xsl
and those from supplemental report, putting an empty column between
them to visually separate two sets of nodes. IT is as easy as to the
following lines to html.xsl:

======== replace =========
<xsl:variable name="full_columns_set"
select="document('')/xsl:stylesheet/xsl:address@hidden'show_columns_xml']/column"
/>
======== with =========
<!-- base columns set specified in the xslt file -->
<xsl:variable name="base_columns_set"
select="document('')/xsl:stylesheet/xsl:address@hidden'show_columns_xml']/column"
/>
<!-- columns from the supplemental_report -->
<xsl:variable name="supplemental_columns_set"
select="/illustration/supplemental_report/column" />
<!-- merge both sets -->
<xsl:variable name="full_columns_set" select="base_columns_set |
$supplemental_columns_set" />
======== end =========

> selections, but is somewhat less flexible in that the same
> selections would be used for both purposes; yet that might well
> be exactly what's wanted in most cases.

> If that's what you've done already, then let's leave it alone for
> now: it might be good enough. We can play with it and see how
> suitable it seems.

It is the way to go, right? I'll do the modification and test it.

> Confirmed. But I don't think you need to spend time redoing the
> patch right now for this single, small, isolated change. Why not
> wait until I answer your email of 2006-10-16 22:11 UTC? I'm
> trying to understand libxml++ better first.

Ok, thanx! I will modify my local copy of the code then, to be ready
to create a patch when needed.