[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. vs. 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 possibilities: - 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. Eike -- Automatic string conversions considered dangerous. They are the GOTO statements of spreadsheets. --Robert Weir on the OpenDocument formula subcommittee's list.