[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Formula Terminology
I'm noticing a lot of terminological issues in the financial functions, especially the same concepts being referred to by multiple terms. We should strive to use different terms only when we want to refer to different things. A standard is not an exercise in creative writing. Synonyms are not our friend. I've started a Wiki page to track the issues as I find them. Not much there yet, but it will grow. http://wiki.oasis-open.org/office/Formula_Terminology I'm also wonder about the redundancy in the function summary and the semantics. In many cases the semantics section starts with a sentence that is a verbatim repetition of the function summary, often verbatim. But sometimes it isn't. I think we want to avoid redundancy here. Maybe we don't need the summary at all? Constraints -- there also vary in the way they are used. What is the intent here? For example, for PRICE(): Constraints: Rate, AnnualYield, and Redemption should be greater than 0; Frequency = 1, 2 or 4. 1) Why is this a "should"? 2) What happens if the constraints are violated? Compare to RATE(): If Nper is 0 or less than 0, the result is an error. Do we really mean to say that constraint violations are errors in some functions, but not in others? Also, could we eliminate 80% of the constraints by simply defining PositiveNumber and NonNegativeNumber pseudo-types? It will be far easier to express these kinds of constraints as datatype constraints than trying to repeat these trivial constraints in the body of the text. Regards, -Rob
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]