Re: [office-comment] DISTINCT Values

[Patrick Durusau <patrick@durusau.net>]

Leonard,

Leonard Mada wrote:

> Hi,
>
> Patrick Durusau wrote:
>
>> Leonard,
>>
>> Another interesting comment!
>>
>> Hmmm, but isn't it true that what OpenDocument should define are the 
>> operators that work with DISTINCT (and other functions) such that you 
>> can write your own functions?
>>
>> What concerns me is that no matter how large the eventual list, we 
>> are going to miss that special function that someone has to have. If 
>> we give them the ability to use standard operators with which to 
>> write their specialized functions, that lessens the load on us and 
>> gives users greater freedom.
>
>
> Unfortunately, I have a very different and justified opinion. Maybe I 
> have some better understanding of spreadsheet use than many people on 
> this list as I have both
>    extensively used  spreadsheets myself for working
>    overlooked 100+ employees working extensively with spreadsheets
>    extensively used  spreadsheets in research settings
>
I don't doubt that you have extensive experience in using spreadsheets.

However, from my experience with standards it isn't possible to write a 
standard based on the instruction: "Whatever functions are possible I 
want them."

Mostly because that is an unbounded space and so even if I start with 
where David and others are now, I have no way to know where to stop. 
(The latter being something important to know when writing a standard.)

What we need are details. Use case scenarios are useful but only up to a 
point.

For example, you mention the R as factor () below.

Recalling that OpenDocument is an *interchange* format, how do we deal 
with the following issue?

> Factors are currently implemented using an integer array to specify 
> the actual levels and a second array of names that are mapped to the 
> integers. Rather unfortunately users often make use of the 
> implementation in order to make some calculations easier. This, 
> however, is an implementation issue and is not guaranteed to hold in 
> all implementations of R. (Section 2.3.1 Factors, R Definition Language)

We do not specify implementation details so it is possible for an "as 
factor()" function to work differently depending upon implementation 
details.

Having a function defined by a standard work differently is a bad thing.

I don't know whether that would actually change the result of a function 
or not but it is an example of the level of detail that is necessary to 
consider when defining a function in a standard.

I suspect it would be possible to define "as factor()" such that it had 
a standardized result and if someone allowed used based on 
implementation details they would be non-conformant. I say that not 
having looked at the details. And by details I do not mean use or test 
cases but a formal definition of the function.

I know the formula SC has a number of functions that still need some 
work so maybe we need a rule that welcomes new function proposals but 
grants priority to requests accompanied by work on functions already 
accepted for standardization.

David, what say you?

Hope you are having a great weekend!

Patrick


-- 
Patrick Durusau
Patrick@Durusau.net
Chair, V1 - Text Processing: Office and Publishing Systems Interface
Co-Editor, ISO 13250, Topic Maps -- Reference Model
Member, Text Encoding Initiative Board of Directors, 2003-2005

Topic Maps: Human, not artificial, intelligence at work!