OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office-formula message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [office-formula] frequency

On Tue, 2009-12-22 at 18:11 -0800, Dennis E. Hamilton wrote:

>    2.1 What I would do for this is move the parameter identifications up to
> where I suggested and in the summary statement for frequency, refer to the
> table.  That is, 
>        frequency    the number of coupon payments per year (Table 11)
> and leave it at that.

I am not sure that the table is very useful. It should probably be
emphasized that the only valid values for 'frequency" are 1,2 and 4.
>    2.2 I would not say anything about interest because interest is not
> involved in this calculation and we have no idea how coupon value is
> determined and what the amount associated with a coupon is.  We are
> concerned only with a calendar question.


>    2.3 I do note, however, that the summary and the semantics are
> contradictory, and I am not sure that settlement date is the correct term
> here.  

I don't see the contradiction (unless you believe that the two
statements say different things about whether the settlement and
maturity dates are included or not.)

> In particular, the role of the maturity parameter's value is
> completely unspecified, and we need more details on what the function is
> about.

It surely should say somewhere that the maturity date is always at the
end of a coupon period (and so frequency plus maturity date fix the
coupon periods.)
>    2.4 In any case, I refuse to look at the test cases to find out what this
> function really is.  
>    2.5 Since a table of values consisting of some subset of the plausible
> numbers 1, 2, 3, 4, 6, and 12 is used fairly regularly,

plausible numbers? I consider the table to be intended to limit the
possible frequencies to 1,2, and 4. (OOo for example does not allow a
frequency of 3.)

Note that different functions historically have allowed differnet
frequencies (some permit 12 others apparently do not.)

>  it might be useful
> to consolidate the few flavors actually used into named tables at the
> beginning of the Financial Functions.  (There are at most 3 I think.)  Then
> we can refer to the specific one from the description of each
> frequency-named parameter that requires such a selection of values.  This
> does not lesson the need to add something about "frequency of what" however.
>    2.6 I don't believe one definition of frequency can be used everywhere.
> I do believe that the values for the frequency parameter need only be
> specified once for any function having such a parameter.  I believe it would
> be sufficient to do so in the enumeration of the parameters.  Several
> functions will have the same descriptive text.  Not all of them.
>    3.1 We could definitely use some consistency here.
>    3.2 Change the parameter names to be in lower case.
>    3.3 Move the identification of parameters as I have already proposed.
>    3.4 Use the same layout for the list of parameter names with their
> summary descriptions as elsewhere, including italic names.
>    3.5 I think we will find all sorts of difficulties in the weeds for this
> function.  For example, the test-case results are given as %-ages, but the
> result type is Number.  So is the actual result of the first test case
> (independent of how it might be formatted for presentation) .049977.. or
> 4.9977.. ?  I can ask similar questions about the rate parameter.

I never understand the confusion about "percentages". They are just
numbers:  4.9977% == 0.049977 == 4.9977 x 10^-2 ==...
>    3.6 I have a feeling that settlement and maturity here correspond to
> issue and settlement of ACCRINT, and ACCRINT uses coupon where rate is used
> in ODDLYIELD.  There is other slop to figure out in order to achieve
> consistency.

Do you want consistency within OpenFormula or consistency with the terms
used in accounting that uses these functions? In the latter case some
functions are intended to calculate the accrued interest prior to the
settlement date others relate to interest between settlement and
maturity. If it is the former, perhaps we should really just use
fromdate, todate, etc.


Andreas J. Guelzow
Concordia University College of Alberta

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]