Re: [lmi] Calculation summary and costly IRR calculations

[Greg Chicares]

On 2006-10-18 14:22 UTC, Evgeniy Tarassov wrote:
> On 10/18/06, Greg Chicares <address@hidden> wrote:
> 
>> 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.

Oh, I thought you had compiled without any compiler optimization
switch like '-O2'. I was only speculating that the speed of the
IRR calculations wouldn't be affected much by that.

If you're talking about rewriting that code to make it faster,
though...well, I think the slowness is inherent in the problem.
Abstractly, given a polynomial with coefficients
  {a0, a1, ... aN-1, aN}
from which we construct a set of 1 + N polynomials
  {a0, a1, ... aN-1, aN}
  {a0, a1, ... aN-1}
  ...
  {a0, a1}
  {a0}
, the task is to find a root for each of those 1 + N constructed
polynomials, where N might typically be fifty.

But if you have any brilliant insight into that problem,
then we could talk about it sometime.

> Strangly, times does not change for me (almost) when i regenerate the
> summary with Ctrl-E (your instructions above).

Probably your hardware or OS is better at caching than mine.

> 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.
[...]
>> 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".

Once we get this in cvs, I'll ask people in my office to backport
that small change to HEAD and measure timings with the old
calculation summary, too, for comparison.

>> > 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.

Our end users won't know that NaN means "Not a Number". A blank
would be okay, or some string like '--'. If it's easier to show
zero, then that's okay, too.

>> 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

[My guess was incorrect--you were expressing the selections in
the xslt file--but perhaps it was a felicitous misunderstanding,
because this might be a nice feature.]

>> 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.

Sure, as long as it isn't too much trouble.

>> 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?

My reply of 2006-10-18 13:51 UTC has crossed in the mail.

>> 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.

All the more reason for us to get this into cvs, once we figure
out the best way to do that.