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

*Subject*: **Re: [office-formula] Style for Function Descriptions**

*From*:**"Andreas J. Guelzow" <aguelzow@pyrshep.ca>***To*: office-formula@lists.oasis-open.org*Date*: Sat, 26 Dec 2009 13:41:28 -0700

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>

**Follow-Ups**:**RE: [office-formula] Style for Function Descriptions***From:*"Dennis E. Hamilton" <dennis.hamilton@acm.org>

**References**:**MIRR***From:*Patrick Durusau <patrick@durusau.net>

**Re: [office-formula] MIRR***From:*"Andreas J. Guelzow" <aguelzow@pyrshep.ca>

**Re: [office-formula] MIRR***From:*Patrick Durusau <patrick@durusau.net>

**Re: [office-formula] MIRR***From:*"Andreas J. Guelzow" <aguelzow@pyrshep.ca>

**Style for Function Descriptions***From:*"Dennis E. Hamilton" <dennis.hamilton@acm.org>

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