Andreas,
From below:
> I think we may in fact be agreeing: the draft as currently written
> allows virtually arbitrary return values if the constraints are not
> satisfied. It seems that neither you nor I think that that is a good
> idea.
+1! Yes!
Sorry, language can be really clumsy.
I fear the same result obtains for other functions as well.
Hope you are having a great day!
Patrick
Andreas J Guelzow wrote:
> Hi Patrick,
>
> On Tue, 2009-01-13 at 13:40 -0500, Patrick Durusau wrote:
>
>> Andreas J Guelzow wrote:
>>
>> <snip>
>>
>>>> According to your reading, we have prohibited 0^0 and then in a
>>>> following paragraph mandated it but don't define the result.
>>>>
>>>> If it is prohibited, there is no valid result. (full stop)
>>>>
>>>>
>>> There has to be a result.
>>>
>>> If a user uses 0^0 some value _must_ be returned.
>>>
>>>
>>>
>> Note that I said "no valid result." What result it should return is up
>> to the formula standard to define.
>>
>
> I guess we are just disagreeing on language. To me, an "error" is a
> valid result.
>
>
>>> Since it violates the constraint imho it should be an Error. I guess the
>>> draft wants to allow other values (namely 0 or 1 as continuous
>>> continuations of related functions) but prohibit anything else.
>>>
>>> Personally I think it should always return an error.
>>>
>>>
>>>
>> OK, but the draft also says (6.1, under constraints):
>>
>>
>>> *
>>>
>>> If a constraint is not met, the function/operator *should*
>>> return an Error unless otherwise noted.
>>>
>>>
>> That makes it appear (whether intended or not) that
>> applications/implementations when executing a function/operator defined
>> by OpenFormula can violate any constraint and not return an error.
>> Unless the definition of a function/operator gives a specific
>> instruction on what to do in the case of a constraint violation.
>>
>> That seems like an odd result. As I say, that is probably a mis-reading
>> but it is one allowed by the text as written.
>>
>
> I think we may in fact be agreeing: the draft as currently written
> allows virtually arbitrary return values if the constraints are not
> satisfied. It seems that neither you nor I think that that is a good
> idea.
>
> Note that for this little expression 0^0 we currently have the following
> return values in:
>
> Gnumeric 1.9.4 and earlier #NUM! (so it returns an error)
> Openoffice3 1 (well...)
> Kspread 1.6.3 1 (well...)
>
> Andreas
>
--
Patrick Durusau
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)
