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