GNOME Bugzilla – Bug 117655
handle listing the set of daycount conventions better
Last modified: 2009-06-24 09:35:24 UTC
These are the remaining problems from 115812: ------------------------------ the arguments and the corresponding description of the arguments don't match in AMORDEGRC: @FUNCTION=AMORDEGRC\n" "@SYNTAX=AMORDEGRC(cost,purchase_date,first_period,salvage,period,rate[," "basis])\n" "@DESCRIPTION=AMORDEGRC returns the depreciation for each accounting period.\n" "\n" "@settlement is the settlement date of the security. @maturity is the " "maturity date of the security. @basis is the type of day counting system you " "want to use:\n" ------------------------------- Idem for AMORLINC "@FUNCTION=AMORLINC\n" "@SYNTAX=AMORLINC(cost,purchase_date,first_period,salvage,period,rate[," "basis])\n" "@DESCRIPTION=AMORLINC returns the depreciation for each accounting period.\n" "\n" "@settlement is the settlement date of the security. @maturity is the " "maturity date of the security. @basis is the type of day counting system you " "want to use:\n" ------------------------------- Idem for DURATION @FUNCTION=DURATION\n" "@SYNTAX=DURATION(settlement,maturity,coup,yield,freq[,basis])\n" "@DESCRIPTION=DURATION calculates the duration of a security.\n" "\n" "@settlement is the settlement date of the security. @maturity is the " "maturity date of the security. @issue is the issue date of the security. " "@rate is the interest rate set to the security. @pr is the price per $100 " "face value of the security. @basis is the type of day counting system you " "want to use:\n" ------------------------------- #: plugins/fn-financial/functions.c:3294 (and also #: plugins/fn-financial/functions.c:3435) msgid "" "@FUNCTION=COUPNUM\n" "@SYNTAX=COUPNUM(settlement,maturity,frequency[,basis,eom])\n" "@DESCRIPTION=COUPNUM returns the numbers of coupons to be paid between the " "settlement and maturity dates, rounded up.\n" "\n" "@settlement is the settlement date of the security.\n" "@maturity is the maturity date of the security.\n" "@frequency is the number of coupon payments per year.\n" "@eom = TRUE handles end of month maturity dates special.\n" "Allowed frequencies are: 1 = annual, 2 = semi, 4 = quarterly. 6 = bimonthly, " "12 = monthly.\n" "@basis is the type of day counting system you want to use:\n" "\n" " 0 MSRB 30/360 (MSRB Rule G33 (e))\n" " 1 actual days/actual days\n" " 2 actual days/360\n" " 3 actual days/365\n" " 4 European 30/360\n" " 5 European+ 30/360\n" "\n" "* If @frequency is other than 1, 2, or 4, COUPNUM returns #NUM! error.\n" "* If @basis is omitted, MSRB 30/360 is applied.\n" "* If @basis is not in between 0 and 4, #NUM! error is returned.\n" "\n" -- The number of types of day counting systems listed goes from 0 to 5, but the allowed range for @basis is stated to be 0 to 4. -- Same problem for @frequency - there are more choices listed than are stated to be allowable. and similar other ones. I believe all of these functions allow more bases (0 through 6)
*** Bug 115812 has been marked as a duplicate of this bug. ***
Ah 2 people working on this bug at the same time...midair collision, see 115812
I had created this reprot to replace 115812 when I went through that one. I think Jody in fact fixed some of these issues already.
As far as I can tell the only remaining issue was the daycount specs. Lets handle this in 2 phases. For 1.2 I've fixed mduration to use the more prosaic * If @basis is invalid, #NUM! error is returned. For 1.3 we should sync all of them up, and in an ideal world provide some mechanism for handling links in the documentation.
By now this really has become a duplicate of 134089. If we ever get around to change our function descriptions we can just use a define to make sure all these day count conventions match. *** This bug has been marked as a duplicate of 134089 ***