PrefBlog

In the comments to the June 22 report, Assiduous Reader drap1 asked:

Hi…quick question about last prefletter. I’ve seen this other times, but here is a clear example:

With respect to TRP.PR.B and TRP.PR.C, TRP.PR.C has a higher dividend, higher reset price and higher market price (both are above $25); however, your model evaluates TRP.PR.C to perpetuity, but TRP.PR.B, to its reset date. What am I missing? Why doesn’t TRP.PR.C get evaluated to its reset date?

TRP.PR.C does resets a year later which could create a small difference depending on the yld curve, but I don’t think that’s the answer.

Good question! For a quick answer, here are the summaries of the two optionCalculationLists on the pseudoPortfolioReportBox:

Report Box
Instrument•:•TRP.PR.B (Security A51015)
PseudoPortfolioElement: Pricing Modification – Base Option ID: Undefined
Reporting: YTM (Port Method) at Bid
*****
Evaluated at bid price : 25.4000
Call 2015-07-30 YTM: 3.51 % [Restricted: 3.51 %] (Prob: 45.09 %)
Call 2020-07-30 YTM: 3.46 % [Restricted: 3.46 %] (Prob: 0.30 %)
Limit Maturity 2041-06-10 YTM: 3.47 % [Restricted: 3.47 %] (Prob: 54.61 %)
YTM (Port Method) : 3.4865 %

and

Report Box
Instrument•:•TRP.PR.C (Security A51016)
PseudoPortfolioElement: Pricing Modification – Base Option ID: Undefined
Reporting: YTM (Port Method) at Bid
*****
Evaluated at bid price : 25.9000
Call 2016-02-29 YTM: 3.65 % [Restricted: 3.65 %] (Prob: 52.02 %)
Limit Maturity 2041-06-10 YTM: 3.56 % [Restricted: 3.56 %] (Prob: 47.98 %)
YTM (Port Method) : 3.6095 %

So part of the problem is a stenographical error: I should have specified that the call on TRP.PR.B was calculated to the second reset date but, frankly, missed that when transcribing the table.

However, the interesting question is the appearance of second reset date in the TRP.PR.B table but not in the TRP.PR.C table, particularly given that the probability of exercise of this option is less than half a percent.

Possible options are added to the calculation list only if the probability of exercise, when initially calculated, is greater than the value OPTION_EXERCISE_CALCULATION_INCREMENT_PROBABILITY, which is currently set to 5%. However, subsequent normalizations did not enforce this constraint.

Additionally, as can be seen from the cashFlowDiscountingAnalysisBox, the cash flows to 2020 for TRP.PR.B extend one month further than the actual call date, as has been previously discussed on PrefBlog in the post What is the Yield of RY.PR.Y? due to the influence of the maturityNoticePeriod.

“Cliff Effects” are a bugaboo in all analysis and have been blamed, at least in part, for the Panic of 2007 (since a credit rating downgrade raised the capital requirements for all regulated holders, who therefore all had a strong prediliction to sell at the same time). By its nature, YTW is subject to cliff effects, at least insofar as it comes to reporting the duration of the YTW scenario (the amount of change in duration for relatively small changes in price is measured by the attribute pseudoConvexityWorst).

Two changes in programming have been made that should make the calculations at least little easier to explain, although cliff effects will still be present:
i) The constraint OPTION_EXERCISE_CALCULATION_INCREMENT_PROBABILITY is enforced during the normalization of option exercise probabilities
ii) maturityNoticePeriod is only accounted for when the exercise date is less than MATURITY_NOTICE_PERIOD days from the calculation date.

I have been toying with the second idea for quite some time and the change will save me a lot of explanations regarding yield calculation. I’ve resisted the idea because (a) as far as I can tell, it won’t make much difference and (b) a complex analytical programme is a chaotic system, meaning that small changes to some parts can cause huge differences in output under certain conditions. But now seems as good a time as any to proceed.

The effect of these changes on the YTW calculation is displayed in the following reports:

• TRPB_Summary_110610_Revised
• TRPC_Summary_110610_Revised

As noted on October 22

I’ll explain in another post, because it’s kind of funny, but basically there’s a little loop used in the process of curve approximation that calculates a yield; in the case of YLD.PR.B, quoted at 1.60 with a stated annual dividend of $1.05 (currently suspended) until maturity 2012-2-1 at $15 [dubious], the little loop ran ’round 5,709,833 times [in the run where the problem was unequivocally isolated] before the WebService timed out and blew up the whole programme.

The function at fault (yieldApproximatorTypeCalc::getSemiAnnualYieldFromTable) calculates the yield to maturity of a set of cash flows defined in a table (the input is set up in much the same way as Excel’s XIRR() function) by successive approximations to the yield using the Newton Method.

Unfortunately, this procedure can be unstable near a horizontal asymptote or a local extremum.

When calculating the curveYield for YLD.PR.B on October 21, the function did not converge; instead, it oscillated between two highly incorrect numbers.

The function has been adjusted such that:

• After 500 iterations, a successively smaller damping factor is applied to the yield change, and
• After 1,000 iterations, status information is written to the errorOutput.txt file after each iteration, and
• After 1,010 iterations the process aborts and returns ANALYTICAL_DOUBLE_NO_SOLUTION

The function now converges for YLD.PR.B on October 21; other tests (prior to application of the damping factor) confirm that the ‘no solution’ result is handled properly by the rest of the programme.

It’s not often I find a crippling bug in HMIPref™ any more! That’s the only lack of convergence in this function in almost 15 years of daily data!

As mentioned previously, differences in spreads for Floating Rate issues require a new build every time there is a new spread defined. Very annoying; if this craze for Fixed-Resets continues, I’ll have to try the hypervariable-code-as-Web-Service solution previously noted.

The Royal Bank new issue, with its heretofore unheard-of +193bp spread, has required a new build. This build is available from the usual place.

In response to a complaint from an extremely annoying person (and you know who you are!), reporting has been enhanced for Error Code #4644.

This error arises when the user attempts to run a trade report for a portfolio that should include some actual value (which is to say, any portfolio that is not using the issueMethod with desiredSwapIssues set to zero; such a portfolio should have zero value, as its purpose in life is to form a grid of all trading possibilities in the HIMIPref™ universe, with no regard for other holdings).

The error message connected with code #4644 was, admittedly, a little obscure. The message has now been upgraded to specify the accountName, accountNumber and other information similar to that provided on the portfolioReportBox. It is anticipated that this detail will make it more clear to the user what is to be done; the new error code for this condition is #5419.

The error most often arises when the portfolio has been set up improperly, or if the holdings file has been inadverdantly wiped. The portfolio settings may be edited via the portfolioListReport, or the holdings file may be mainMenu|File|Holdings File|Synchronize With Transactions, which (alas) is not yet documented in the glossary or the User Manual. *sigh*

This programming change is not considered significant enough to warrant the upload of a new HIMIPref™ version; it will be available when the next version is uploaded.

Users are encouraged to click “Holdings” on the mainMenu|reports|activePortfolio subMenu every now and then, just to double-check that the transactionFile and holdingsFile are properly synchronized.

This routine has been improved by introduction of a more stable “Wait Cursor” while the transaction file is being evaluated and compared – users will then be aware that they are not supposed to be banging buttons and cursing the programme during the process.

As this is such a small and cosmetic improvement, I will not upload the new version of HIMIPref™ to prefshares.com for client download. The enhancement will be included next time I do upload a substantive improvement.

There’s a new release of HIMIPref™ available for download at the usual place.

If you choose to install this upgrade, please, PLEASE remember to back-up your user data prior to re-installation! It is NOT stored on the server, it exists on the client machine only!

There is no absolute necessity for Institutional users to install the new version – any old version that worked yesterday will continue to work today. There is the consideration that, in the unlikely event that (i) You find a bug, and (ii) the effect of this bug is different in the two versions, it will be much easier track down the error if we’re all singing from the same hymnbook.
Improvements in this release are:

• The two problems noted in the announcement of the previous release have been fixed.
• There was a problem with the printing of the reportSummary that would occasionally cause truncation. The reportSummary would occasionally not print, or even announce the existence of, the final partial page of the report. Not only has this truncation error been fixed, but I now have a deeper and more vivid understanding of my horror when programming printing under Microsoft Foundation Classes for Windows and C++.
• Still with the report summary: if curvePrice is being reported and right-clicked to bring up the curveCalculationContextMenu you may choose to get the cashFlowDiscountingAnalysisBox. If you then click the “OptionDetails” button, you will get the optionCashFlowAnalysisBox. If you then click the “Replacement Cash Flows” button, you will then get another cashFlowDiscountingAnalysisBox with (this is the clever bit) all of the replacement cash flows, not just the replacement cash flows for the chronologically first option.

There’s a new release of HIMIPref™ available for download at usual place.

If you choose to install this upgrade, please, PLEASE remember to back-up your user data prior to re-installation!
This release continues the recent tradition of being more for my convenience than for users’! Several changes have been made to the Administrative Users’ Computation of Indices, but very little has changed for Institutional users.

There is no absolute necessity for Institutional users to install the new version – any old version that worked yesterday will continue to work today. There is the consideration that, in the unlikely event that (i) You find a bug, and (ii) the effect of this bug is different in the two versions, it will be much easier track down the error if we’re all singing from the same hymnbook.

I can remember two minor fixes! Clicking on a data point in a graph of the “Core Yield Curve” now has a much more explicable error message; and calculation of after-tax performance for individual issues has been fixed up.

I found two more minor bugs (features!) when testing the system:

• When you do a price-variance analysis graph for a very wide (say, 40%) band of prices, the system insists that the point with “x = -0.0000” is outside the graphed area. Don’t click on the error box! Just hit return, or the cursor will cause the system to attempt to redraw the graph and HIMIPref™ will appear frozen, although it isn’t.
• Error #3706 is produced when right-clicking on Average Trading Volume on the report summary and selecting “Liquidity Calculation”. The report box gets produced, but with one line of missing information and it’s annoying.

I’ll look at these bugs tomorrow. It’s not worth putting out a new release just for them, but fixes will be part of the next release.

There’s a new release of HIMIPref™ available for download at the usual place.

If you choose to install this upgrade, please, PLEASE remember to back-up your user data prior to re-installation!

This isn’t a very exciting upgrade, frankly – it is only made available to ensure that the Institutional and Administrative versions of the programme are kept synchronized – the major part of the upgrade was to the Administrative version and now, thanks to the miracle of modern automation, I will be able to commence a systematic computation of my FINAL preferred share indices!

There is no absolute necessity for Institutional users to install the new version – any old version that worked yesterday will continue to work today. There is the consideration that, in the unlikely event that (i) You find a bug, and (ii) the effect of this bug is different in the two versions, it will be much easier track down the error if we’re all singing from the same hymnbook.

Update, an hour later : Well, you’ll all be thrilled to know, I did remember an upgrade that will be noticable by institutional users: the appearance of the portfolioEvaluationReportContextMenu|Columns has been improved, with the choices organized a little more logically than “the order I did the programming” and separator lines. How’s that for vital?

There’s a new release of HIMIPref™ available for download at the usual place.

If you choose to install this upgrade, please, PLEASE remember to back-up your user data prior to re-installation!

This isn’t a very exciting upgrade, frankly – it is only made available to ensure that the Institutional and Administrative versions of the programme are kept synchronized – the major part of the upgrade was to the Administrative version, through which I will be saving a LOT of time in the future due to automation of index preparation.

I believe the only noticable change (for Institutional users) is that when adding a “Returns” column to the Report Summary, the system will no longer naively ask whether you wish all issues to be included in the report … it will simply assume that this is the case.

There is no absolute necessity for Institutional users to install the new version – the old version will continue to work. However, if the prospect of saving a complete mouse-click when looking at performance on the Report Summary is not alluring enough, there’s also the consideration that, in the unlikely event that (i) You find a bug, and (ii) the effect of this bug is different in the two versions, it will be much easier track down the error if we’re all singing from the same hymnbook.