OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office-formula message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [office-formula] Implementation-defined, Unspecified, andUndefined behaviors in OpenFormula

Hi Andreas,

On Friday, 2009-06-12 16:42:04 -0600, Andreas J. Guelzow wrote:

> I think it is a really good idea to mandate in the file what
> "implementation defined" behaviour was used in the creation of this
> file.

What specific settings come to mind?

Boolean is a distinct type and not included in NumberSequence and
behaves different in some other operations, such as sorting and
[HV]LOOKUP range-lookup.
Boolean is a number.
=> <table:calculation-settings table:distinct-boolean="false"> respectively "true"

Cell string is automatically converted to number, if not in
NumberSequence and applicable. That's not an easy one, because in
existing implementations, if done, it depends on the locale. We had lot
of discussion about that in the past. There are at least quite a few

- No automatic conversion (current Calc approach).
- Conversion of integer and unambiguous values only, error for other
  values (future Calc approach).
- Attempt to convert everything, without a deterministic result (Excel
  and Gnumeric approach).
- User specified setting of decimal separator (possible in Excel but not
  saved with the document, when reloaded in a different environment
  calculations differ).
  - Such a setting would also not help if one document was cross-edited
    in different locales with different separators and users entered
    non-integer strings instead of numbers.
- Are other separators than whatever decimal separator ignored, or
  treated specially?
  - Are grouping separators checked against grouping rules?
    - If so, for which rules?
- Conversion of date strings to numbers (Excel and Gnumeric approach,
  locale dependent in separators and YMD order).
- ... to be continued ...

This looks like Pandora's box; if at all, we should defer a solution for
the next version of OpenFormula.

> This is in fact closely related to an important fact Doug made in an
> earlier message:  changing mplementation behaviour is not just an issue
> of whether it takes 5 or 1000 lines of code but it causes problems with
> existing files.

I agree.


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

PGP signature

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]