Re: [office-formula] Style for Function Descriptions

["Andreas J. Guelzow" <aguelzow@pyrshep.ca>]

On Sat, 2009-12-26 at 12:12 -0800, Dennis E. Hamilton wrote:

> 4. Move the summary of what the parameter values are used to represent up
> with the syntax, result type (and summary description) so that those aspects
> are presented together.

As far as I am concerned, "what the parameter values are used to
represent" is unnecessary fluff. The standard needs to describe the
output expected given a certain input. It is up to the user to verufy
whether the formula is appropriate for their use. Otherwise the standard
has to become a reference work for Mathematics, Statistics, Accounting,
Actuarial Math, Engineering, etc.   
> 
> 5. With regard to hard constraints, indicate the kind of error a violation
> is.

This is already described elsewhere, and, imho, should not be duplicated
for every function.

> 
> 6. Say something explicit about errors that arise, errors that are
> propagated (not always a wonderful idea), and errors that are absorbed.

This is already done elsewhere. We only need to mention it for
exceptions. Again I don't think that duplication is a good idea.

> There are probably simple cases to be identified in a general place (as is
> done somewhat already) with reference to the applicable case, with any
> qualifications, from the individual function descriptions.

I don't know what this means.
> 

> 10. It is peculiar to have a mathematical formula that has
> spreadsheet-function names being used as if it is a mathematical function
> and we should avoid that.  It is one thing to observe that floor(-x) = -
> ceil(x), which is always true for non-complex x, but it might not be true to
> say that FLOOR(-x) = - CEIL(x) because of Number representation edge cases
> (and I made that mistake on this list somewhere).  Similarly, while we can
> say with confidence that -1 < tanh(x) < 1, that might not apply for
> TANH(Number x) unless we are prepared to require that the computation be
> that tight, with computational rounding to 1 or -1 not permitted.  (If
> rounding to magnitude 1 is permitted for the delivered computational result,
> there are consequences for ATANH(Number x) edge cases too.  It is rather
> unexpected for ATANH(TANH(x)) to ever fail for Number x not an error
> result.)

I think there are situations where we want to have spreadsheet functions
defined in terms of other spreadsheet functions.

Andreas


-- 
Andreas J. Guelzow <aguelzow@pyrshep.ca>