Arne,
Thanks! I'll forward this to the TC.
I'm not always fast on the trigger so you might want to start sending
your comments via the ODF-TC comment list, details of which can be found
here:
https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=officeWe deeply appreciate you comments and they have sparked a number of
ongoing discussions. With more to come.
We're off next Monday for Easter Monday but we will add your latest
comments to our spreadsheet of your comments in the near future.
Hope you are having a great week!
Patrick
PS: In other news, I think I know why LLMs hallucinate case citations.
It's not really their fault; they have been misled.
On 2026-03-31 16:23,
arne@arne-thomassen.de wrote:
> Hi,
>
> the OpenFormula specification OpenDocument-v1.4-os-part4-formula.pdf
> appears to have some flaws. I'd like to suggest the following changes
> to individual functions in addition to the first three batches from my
> e-mails on 19 January, 15 February and 9 March 2026:
>
> - 2.3.4 "OpenDocument Formula Large Group Evaluator" mentions the
> notion "array formulas", but this notion is not defined anywhere in
> the OpenFormula specification. Please define "array formula", "dynamic
> array formula" and "spilling". It may be useful to state connections
> or differences between array formulas and 3.3 "Non-Scalar Evaluation
> (aka 'Array expressions')" and the mention of "non-scalar array mode"
> in 6.3.4 "Force to array context (ForceArray)". Grammatically, a
> formula is an expression with a prepended equals sign "=" or two. -
> These topics seem to be related to 6.18.40 LARGE and 6.18.70 SMALL,
> whose paragraph "Semantics" says e.g.: "If N is an array of numbers,
> an array of smallest values is returned." The size of the returned
> array isn't specified. The semantics might make sense if the returned
> array has the same size as the input array (reference) N and the
> resulting values are "spilled" into the referenced cells. Please
> replace the parameter type "Array" with "Reference" or "ReferenceList"
> and clarify the semantics if so. - These topics are somewhat related
> to this comment from 2024: 'Improvements to "Non-Scalar Evaluation
> (aka 'Array expressions')", section 3.3 part 4',
> <https: issues.oasis-open.org browse office-4168>.
>
> - 6.12.2 ACCRINT: the paragraph "Constraints" requires "First <
> Settlement". The "Semantics" text says: "CalcMethod: A logical value
> that specifies how to treat the case where Settlement > First", which
> is the same as "First < Settlement", which is already required by the
> paragraph "Constraints" anyway. The parameter "CalcMethod" seems to be
> superfluous, which probably means that one of the texts is wrong.
>
> - 6.12.2 ACCRINT, 6.12.3 ACCRINTM, 6.12.18 DURATION, 6.12.23 IPMT,
> 6.12.25 ISPMT, 6.12.29 NPER, 6.12.31 ODDFPRICE, 6.12.32 ODDFYIELD,
> 6.12.33 ODDLPRICE, 6.12.34 ODDLYIELD, 6.12.36 PMT, 6.12.37 PPMT,
> 6.12.39 PRICEDISC, 6.12.40 PRICEMAT, 6.12.42 RATE and others: please
> provide specific mathematical formulas for calculating the results.
> The given prose texts are not sufficient. A specification shouldn't
> require implementors to read other implementations. One basic problem
> is that other implementations contain extensions or variations of
> OpenFormula. Figuring out the exact (limited) behavior required by
> OpenFormula from these implementations is difficult or nearly
> impossible. - Some descriptions, e.g. for 6.12.29 NPER and 6.12.36 PMT
> and 6.12.42 RATE, state that the solution "solves this equation", but
> at least the equation in 6.12.29 NPER and 6.12.36 PMT is so wild that
> algebraic transformation attempts by implementors likely introduce
> errors; please provide the explicit, transformed formulas. (For
> comparison, the equation in 6.12.41 PV can be transformed more easily
> because the term PV is in a nice position in the equation.)
>
> - 6.12.5 COUPDAYBS: the paragraph "Summary" contains the notion
> "settlement date" twice; the second occurrence should probably be
> "maturity date".
>
> - 6.12.21 FVSCHEDULE: in the formula, "Principle" should be
> "Principal" like in the "Syntax" line.
>
> - 6.12.22 INTRATE: the paragraph "Constraints" should provide
> "Investment <> 0" or even "Investment > 0". Otherwise, a division by 0
> can occur.
>
> - 6.12.24 IRR: "There is no closed form for IRR. Evaluators may return
> an approximate solution using an iterative method"; please provide an
> explicit method (algorithm) as a recommendation or as an example. When
> implementations use different approximation methods, the results might
> be so different that the function IRR is unreliable or useless. (Cf.
> lack of mathematical formulas for 6.12.2 ACCRINT and many other
> functions mentioned above.)
>
> - 6.12.27 MIRR: the first parameter is given as "Array Values".
> Shouldn't the type be NumberSequence or even NumberSequenceList? (The
> semantics show a formula in which NPV() is called, where the type is
> even NumberSequenceList and not merely NumberSequence. The semantics
> also mention that "Text and Empty cells are ignored", which is typical
> for NumberSequence[List].)
>
> - 6.12.30 NPV: the paragraph "Constraints" should mention that the
> parameter Rate must not equal -1; otherwise, the denominator in the
> summation formula is 0, resulting in a division by 0. Maybe the actual
> constraint should be even stronger, e.g. Rate > 0. (For comparison,
> the constraint in 6.12.52 XNPV is "should be greater than -1".)
>
> - 6.13.9 COUNTIF, 6.16.62 SUMIF, 6.18.5 AVERAGEIF: at the end of the
> paragraph "Summary", the word "criteria" should be "criterion" to
> match the formal parameter type.
>
> - 6.13.31 SHEET: "If a reference does not contain a sheet reference,
> the result is the sheet number of the sheet containing the formula."
> The notion "sheet reference" is not defined. It seems that _every_
> reference refers to a worksheet anyway (as opposed to an Array), so
> the quoted sentence seems to be wrong. Would the rule consider whether
> a reference was generated with an _explicitly_ named worksheet, e.g.
> "SheetBaz.A1" as opposed to "A1"?
>
> - 6.15.2 AND, 6.15.8 OR: please specify whether evaluators may or
> should short-circuit the evaluation of these functions. When
> short-circuiting, the result of AND is known to be FALSE as soon as
> one input value is FALSE; the result of OR is known to be TRUE as soon
> as one input value is TRUE. But functions which handle
> NumberSequenceList parameters usually have to return an error value E
> when one of the involved values is E. When short-circuiting, a
> function might "overlook" an E which occurs later in the sequence of
> values, returning a Logical value instead of E.
>
> Please consider these additional suggestions.
>
> Thank you,
> Arne Thomaßen</https:>