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: 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. 


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.



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