Re: [office-formula] Editing example

[Eike Rathke <erack@sun.com>]

Hi Patrick,

On Wednesday, 2009-01-21 12:17:45 -0500, Patrick Durusau wrote:

> David Wheeler asked for an example of taking out comments about  
> applications and how it would impact the text.
>
> I have attached such an example to this post.

Unfortunately, replacing the entire section about complex numbers with
a reference to ISO 11404 and some arbitrary conversion to a string
representation doesn't nearly reflect reality of spreadsheets.

The IM*() functions mentioned expect and deliver text in the form
"2+3i", which is the case at least since Excel came up with that. It was
thought of to allow an _additional_ "real" complex data type, which
AFAIK no spreadsheet application implements yet and is not specified by
us. All IM*() functions nevertheless must accept the textual form of
arguments for interoperability.

The general explanations regarding complex numbers indeed should go into
a Note or, if they don't seem to belong into the standard at all, be
removed.

Our draft certainly is too verbose in some places and, as a standard,
needs polishing in wording and phrasing and some details can be left
out, but there are reasons to go into details in cases for
interoperability of applications.


Some comments on your notes:

| Ed. Note: I would delete this paragraph as support of complex datatypes
| is define under conformance and how an application conforms (plugin,
| native ability) is really irrelevant. Moreover, the notion of “portable
| document” should be one that meets the conformance requirements for ODF
| and OpenFormula. 

If the detail that a complex number may be subtype of Number, or
a subtype of Text, or a distinct type, will go into a Conformance
chapter then yes, it could be removed here. Personally I think that
should be mentioned under Complex Numbers. Whether an application
supports complex numbers by means of a plugin or native is of course out
of scope of the standard.

Regarding the "portable documents" I think some general clarification is
needed. We use the term "portable document" in the sense that a creator
(application or user) who wants highest portability should setup the
formulas such that all conformant applications can process them equally,
regardless of implementation details. In the case of complex numbers,
conformant applications may return True for either
ISNUMBER(COMPLEX(2;3)) in case they implement a distinct complex data
type, or True for ISTEXT(COMPLEX(2;3)) in case they implement the
textual complex numbers. The creator of a portable document should not
assume that one or the other is fulfilled.


| Ed. Note: The functions that accept complex values should be define in
| chapter 6. I have no need to speak about them here.

IMHO ok to remove that here.

| BTW, the only thing
| that is accepted by a function is what we define is accepted by
| a function. Can someone say why we should accept Text values as complex
| numbers? It is simply a question the datatype of the input? In other
| words it represents a complex number but some system says that it is
| “Text?”

"2+3i" _is_ a text value, but gets interpreted as a complex number by
those functions.


| We haven't written the conformance clauses, yet, but I assume that
| a conforming application can meet the requirements of processing a valid
| document that includes content as defined by OpenFormula, without
| including support for complex numbers. Yes?

Yes, it would just not conform to the Large group.


| If the question is: What to do when you encounter a complex number?
| I think the answer pretty clearly is that you have to support the
| functions whose inputs include complex numbers, at least for the
| operations in a given document. I am not sure what other answer could be
| given

If an application does not support a function, regardless whether it's
a complex number function, it shall generate an error for the formula
the function occurs in. I think we do state that somewhere.


| Ed. Note: If under this type it is desirable to have cross-references to
| all the functions that accept input of this datatype, that could be
| useful, well, until you get to datatypes that are nearly universally
| accepted by every function, then the cross referencing would be
| tiresome. I think that would be more useful under particular functions. 

I think a cross-reference to "6.2.8 Conversion to Complex Number" and
"6.7 Complex Number Functions" should do here.


| [... about the '=' equal operator ...]
| Ed. Note: Recall that no datatype exist save in so far are we define it.
| If we choose to not allow the representation of complex numbers as text,
| then it simply doesn't exist.

We have to allow it.


| [... office:value-type string and office:string-value ...]
| Ed. Note: The attribute types of OpenDocument files are defined by the
| OpenDocument Format specification and not by OpenFormula. It is true
| that OpenFormula could, for example, define a format for storing complex
| numbers, it would be up to OpenDocument to incorporate that definition
| by its adoption of OpenFormula for the representation of expressions,
| operators, functions and their results. 

That paragraph clarifies that applications should store the result as
string (and how) and not as number, even if they implement a complex
data type that could be regarded being of type number.

I hope that sheds some light.

  Eike

-- 
Automatic string conversions considered dangerous. They are the GOTO statements
of spreadsheets.  --Robert Weir on the OpenDocument formula subcommittee's list.

PGP signature