Feedback from ODF 1.2 some OpenFormula errors. (part1)

[ronnie thebonnie <ronniethebonnie@gmail.com>]

Hello,

thanks for making an open and collaborative effort possible with ODF.

Some feedback:

1)
In openFOrmula section 4.4Complex Number
A complex number (sometimes also called an imaginary number) is a pair
of real numbers including a real part and an imaginary part. In
mathematics, complex numbers are often written as x + iy, where x (the
real part) and y (the imaginary part) are real numbers and i is
. A complex number can also be written as reiθ = rcos(θ) + irsin(θ),
where r is the modulus of the complex number (a real number) and θ is
the argument or phase (a real number representing an angle in
radians).


The representation is: re^(iθ) = rcos(θ) + irsin(θ)
Please correct this.



2)
Making the "=" a should in formula.

Because it would be handy to do the following:
Cell A1 and A2, in A2 there s a formula, the cell shows the result of
that formula.
In cell A1 I want to store how the formula looks.
I would need for this:
something to distinguish formula that are formula and formula that are
just strings that I want to show.

Another handy thing would be a FormulaToString(cell) function that
takes a cell as input and shows a string that is the textual
representation of the formula and not the value calculated by the
formula.

3)

8.3Auto Text to Number

An evaluator may have the “Auto Text to Number” feature, which means
that the “Convert to Number” function, when receiving a Text value or
a Reference to a Text value, converts the Text into a Number,
typically through calling the VALUE() function. This feature can be
convenient if files never change locale, but in today's international
environment, this feature can easily lead to data files that look
correct but give subtly wrong answers, especially when shared with
users who use a different locale. This can be a problem even when the
documents never leave a small geographical area, since users may
choose a locale they are familiar with that is different that the one
expected by the document sender.

This is perfectly solvable.
Let me explain.
The environment needs to be split in two. One internal representation
and one UserInterface representation.
The internal representation holds a standardized locale. And the
UserInterface has also a local.
The programs can compare the two and calculate forth and back between
those, while the internal representation remains stable.
Means documents that can be read with any local because it's not
dependent upon the UI localization.
User can input things that get (in a stable way) converted to the
internal representation and forth to display everything.

Allows for doing a Auto Text to Number.
Works as following:
A preparing function takes the text and converts it to the internal
representation locale according to localization transformation rules.
Now our Function can take that, which is the same everywhere, and
converts it according to the internal representation local.
The program then, for showing, does the regular transformation between
internal representation locale and user interface locale.

There are of course strange edge cases that will always be very
difficult to solve.
But having a simple way to do simple things looks very good possible
in a standards-compliant locale-independent way.

This also allows collaboration wit people from different locale on the
same document.



4) Has also been sent in:

In OpenFormula, it's possible to do formula including a way to
describe non-standard formula.

It would be interesting to be able to add information about formula
engines and values.

What would be interesting is to be able to do is the following:
Letting the formula's be calculated with a formula engine.
Saving the cells values with a calculated value attribute and formula
engine attribute.
Calculate the formulas with another formula engine.
Saving also the new values with a calculated value attribute and
formula engine attribute.



It needs something to preserve the calculated value of that cell and
which formula engine that did it. Preferably in a way so that multiple
values from multiple formula engines and versions can be stored
parallel.

To avoid problems, software should, without extra input, show the most
recent results.

A function to show the name of the formula engine currently used would
be handy.
Also a function to show a list of all formula engines (+version if
applicable) with their values.

This would be very handy to compare things from different formula
engines in the future.

Was inspired by the bottom of this blog post, where formula engines
are mentioned:
http://www.robweir.com/blog/2010/07/odf12-public-review.html