RE: [office-formula] frequency

[Andreas J Guelzow <aguelzow@math.concordia.ab.ca>]

On Wed, 2009-12-23 at 10:41 -0800, Dennis E. Hamilton wrote:
> Hi Andreas,
> 
> 1. RATIONALIZATION OF SPECIFICATION OF FREQUENCY PARAMETER VALUES.
> 
> I agree there are only a couple of cases for what the frequency values are,
> but having the tabular definition is useful, and it would satisfy Patrick's
> sensibilities around redundancy if the specific table could be linked from
> the description of a parameter value.  

I think we should delete those descriptions of parameters values. They
do _not_ define them. This limitation on frequency should then become a
constraint: frequency \in {1,2,4,12\}

> It looks like there are only 1,2,4
> and 1,2,4,12 defined anywhere.  
> 
> (By plausible, I meant that they are all exact divisors of 12 so the
> intervals are exact numbers of months that roll up to 12 in the specified
> number of annual payments.  I did mean to suggest that we allowed all such
> frequency values on all of the functions that have such a parameter.)

While you have observed a common property of these numbers (divisors of
12), this property does not define that set, since 3 is also a divisor
of 12 but happens not to be included. 

This limitation on frequency is a constraint and should be listed as
such!


> 
> 2. COUPDAYBS CONTRADICTION
> 
> Here is where I see contradiction in COUPDAYBS:
> 
>   2.1 "Summary: ... the number of days between the beginning of the coupon
> period that contains a settlement date and the settlement date."  (I
> corrected the use of articles here.)
> 
>   2.2 "Semantics: [returns] the number of days from the beginning of the
> coupon period to the settlement date."

Note that is says "the coupon period", obviously it should specify which
one. It does that in the summary.
> 
>   2.3 The Summary is more precise than the semantics (?!).  
> 
>   2.4 Also, there are an immense number of unstated assumptions, such as how
> the maturity and settlement parameters are different and how one determines
> the start date of the coupon period containing the settlement date
> (presumably the date given as the value of the settlement parameter).

Of course we should have a formula describing the calculation.
Everything else is subject to interpretation.


>    3.2 I am not quarreling about how one understands %, rather about how one
> expects rate values to be supplied and delivered.  I am concerted about
> confusion between how a field is formatted (and what happens on data entry)
> and what the calculation is and what the numbers are in the calculation.  I
> don't think % symbols should be used in the test cases (but I also expect
> the test cases to disappear).

quoting from the OpenFormula draft:
A percentage is a subtype of number which is typically displayed by
multiplying the number by 100 and adding the sign "%". Thus, the value
0.50 if considered a percentage would typically be displayed as 50%.

SO this is one display form of a number, there are others. We obviously
are not always using the same.

With respect to the use of % in the test cases, this is in no way
different than using DATE(...) to specify dates since % is in fact a
postfix operator.

Andreas


-- 
Andreas J. Guelzow
Concordia University College of Alberta