Hi, I hope this is the right forum for my mail. If not, please point me to the proper one.
The following topic is non-trivial, so please bear with me. CALC supports the function DAYS360(...;...;type) where type is 0 or 1. The following is all about this function. The online help says, for type = 0 the US method (NASD, National Association of Securities Dealers, Inc.) is used, whereas for type = 1 (or <> 0) the European method is used. (1) To begin with: The results calculated with this function are the same (for the examples I checked), as those evaluated with Microsoft Excel 2000. Question: What is the importance of this fact? (2) The documentation is way to short. There are a couple of interest calculation methods used in practise , that are of the type "30/360". These interest calculation methods all need a corresponding type of this function. Types are, e.g. 30/360, 30U/360, 30E/360, 30S/360, .... (these four types should describe only three methods, though). For a detailed description see, for example: [1] http://en.wikipedia.org/wiki/Day_count_convention A detailed definition of the interest calculation methods can be found in [2] http://www.swx.com/download/trading/products/bonds/accrued_interest_en.pdf (3) For all examples I tried, DAYS360 for type = 1 yields the same results, as "Special German", also denoted as 30S/360 or 30E/360. Another name is Eurobond basis. So, I >guess<, DAYS360 for type = 1 is meant to be this method, although it is called "European method" in the documentation. Question: Is that so? If not, what method is it? (4) I guess DAYS360 for type = 0 is wrong! (This is the reason I stated (1) before and asked about its importance.) Let me begin with the US-method (NASD, National Association of Securities Dealers, Inc.), that the documentation refers to. The only reference I found is: [3] http://finra.complinet.com/finra/display/display.html?rbid=1189&element_id=1159000635 which is not nearly as precise as the definitions found in reference [2] given above. I >guess<, that the US-method according to NASD is the same as 30U/360, as described in references [1,2]. For all examples, that are given in reference [3], one gets the same results. Nevertheless, DAYS360 for type = 0 differs from 30U/360. Examples are D1 = 28 Feb. 2007, D2 = 29. Feb 2008 with 359 versus 360 D1 = 29 Feb. 2004, D2 = 29. Feb 2008 with 1439 versus 1440 D1 = 28 Feb. 2005, D2 = 28. Feb 2009 with 1438 versus 1440 The first value is evaluated with DAYS360(... type = 0), the second value corresponds to 30U/360. So, the definition given in reference [3] is ambiguous. There are at least two different functions, that yield the same values for all cases given in reference [3]. From a practical point of view, all three examples given above, should yield a day count that is a multiple of 30. This is the reason I think, that the CALC function (and Microsoft Excel, for that matter) is wrong. Question: Is this right, or is there a more precise definition of the NASD US method given in some normative source, that proves me wrong? Question: Is there a way to improve CALC (code and documentation), so that all "30/360" interest calculation methods are supported? (One could do it in a way that does not break compatibility to the "bug" in Microsoft Excel). Thanks for your patience -- and your response... -Andreas. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
