Re: [office-formula] AVEDEV

[Patrick Durusau <patrick@durusau.net>]

Andreas,

Andreas J Guelzow wrote:
> On Sat, 2009-12-26 at 16:20 -0500, Patrick Durusau wrote:
>   
>> Greetings!
>>
>> Lest we get too focused on the financial functions, can anyone tell me 
>> what is wrong with the following?
>>
>> AVEDEV - Calculates the average of the absolute deviations of the values 
>> in list.
>>
>> Yes, it should read, "the values in *a* list." but that's just poor 
>> writing and I can fix  that.
>>
>> What else is problematic about this function and its definition in 
>> OpenFormula?
>>
>>     
>
>   
>> Excluding the math formula, our text in full reads:
>>     
>
> To the math formula we obviously need to add what n, x_i and x^bar are.
> BUt then the math formula will define this function. 
>
>   
>>> *Summary:* Calculates the average of the absolute deviations of the 
>>> values in list.
>>>
>>> *Syntax:* AVEDEV( { /NumberSequenceList/ N }^+ )
>>>
>>> *Returns:* Number
>>>
>>> *Constraints:* None.
>>>
>>>       
>> 1) Average - not defined.
>>     
>
> that's only in the non-normative summary. so there is no need to define
> that. (The formula given should explain everything!)
>
>   
Err, non-normative material appears in notes and only to explain or 
amplify what has already been said.
>> 2) Absolute deviation - not defined
>>     
>
> ditto
>
>   
Same here.
>> 3) Values - not defined (what is the standard deviation of string 
>> values, one from the other?)
>>     
>
> the argument is a NumberSequenceList, so there are only numbers.
> (Conversion of strings in teh argument to a NumberSequenceList is
> defined elsewhere.)
>
>   
Then the text should say "NumberSequenceList" (preferably with a 
reference to the definition), not values.
>> 4) Values or NumberSequenceList?
>>     
>
> as for 1)
>
>   
>> 5) Calculates - not defined
>>     
>
> as for  1)
>
>   
>> 6) Calculates as opposed to return, returns, compute, computes, finds?
>>     
>
> should really be none of the above
>
>   
But if it appears, we need to pick one. We might (I haven't asked 
everyone) think of those words as roughly equivalent, in English. I have 
no idea if they are "roughly" equivalent in other languages and really 
shouldn't have to worry about that. Standards are not writing contests 
for the most "interesting" prose. Just precise prose.
>> 7) No constraints? Suspect that values being numbers (see #8 on present 
>> lack of definition) is one but see #4.
>>     
>
> NumberSequenceList
>
> So there are no constraints! There is implicit conversion happening
> which is defined elsewhere.
>
>   
Err, so all input can be implicitly converted to NumberSequenceList? I 
will have to look for that.
>> 8) Returns Number? (Recalling that number is "defined" as "A number is 
>> simply a numeric value such as 0, -4.5, or $1000." That's an 
>> illustration, not a definition.
>>     
>
> You can't be serious. Do you really want to define inside OpenFormula
> what a number is? Since part 1 uses the terms number and numbering a
> large number of times, we could refer to its definition of "number" (of
> course it doesn't define "number" either.
>
>   
OpenFormula defines the "result" of functions. Unless any possible 
result is acceptable, it had better define those results.

Actually we don't define number but we do reference the W3C definitions 
for positiveInteger, etc.
>> So, when I apply AVEDEV to a list of 
>> numbers, an application could return a monetary amount?
>>     
>
> you are confusing formulas and formatting. ANd of course in lots of
> spreadsheets the return value of AVEDEV is (formatted as) a menetary
> amount.
>
>   
Well, perhaps but then the current draft started it by saying that "0, 
-4.5, or $1,000" are all instances of number.

It doesn't help to say "well, that wasn't normative text." Sorry, I 
should not have to be a member of the committee to know what parts of 
the text are normative and which ones are just idle musing about the 
subject matter.

More to the point, yes, I can imagine with a defined set of inputs that 
a monetary amount (why do you say money is formatting?) could be the 
correct result. But there are situation where it would not be the 
intended result. The function AVEDEV should return a defined result in 
both cases.
>> Granting that 
>> might make sense if the input was a series of monetary amounts but I 
>> don't see a limitation here that prevents a string of integers having an 
>> AVEDEV result of $42.
>>     
>
> so what's the problem with that?
>   
If that is obtained by every evaluator following OpenFormula, none. My 
question concerns whether we have sufficient detail for that to be the 
case.
>> Not to exclude the math formula even though I am not including it in 
>> this email:
>>
>> Math Formula
>>
>> 9) In order for this to be useful, simply reproducing it is 
>> insufficient. Formulas are defined to be useful assuming particular 
>> inputs and ranges on those inputs. As well as outputs. We don't have to 
>> keep repeating them but we do need to define those inputs, limits and 
>> outputs.
>>
>> 10) What precision required is not specified (not really the fault of 
>> the equation but seemed appropriate to mention here).
>>     
>
> We address precision elsewhere (2.6). Among some things is that the
> table:precision-as-shown setting affects this.
>
>   
Err, do you mean:

> This specification does not, by itself, specify a numerical 
> implementation model, though it does imply some minimal levels of 
> accuracy for most functions. For example, an application cannot say 
> that it implements the infix operator “/” as specified in this 
> document if it implements integer-only arithmetic.
>
Well, to "...imply some minimal levels of accuracy for most functions." 
isn't going to get us much in terms of interoperability is it?

Thanks for pointing that out.

Hope you are having a great holiday!

Patrick

-- 
Patrick Durusau
patrick@durusau.net
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)