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


Help: OASIS Mailing Lists Help | MarkMail Help

office-comment message

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

Subject: Re: OASIS: Infix Operator "^"

Andreas J. Guelzow wrote:
>> NO, there is NO such unary operator: -x^2 = -x * -x = + x^2, THIS is 
>> NONSENSE. Such a unary operator does NOT exist. 
> What is the - in -x if not a unary operator?

Well, the true unary operator has the fantastic property that -x^2 != 
+x^2, while that described in the OASIS document has the strange 
property that -x^2 = +x^2.

This is basic math I learned back in school while I was in the 5th 
grade. It did NOT change over time.

Though, there is even more to this. I try to be constructive:
> In any case, OpenFormula describes the syntax used in a file.

That is a poor format then, and surely NON-portable IF I would like to 
import the file in a serious statistical program. And what will the 
future being, maybe someday even spreadsheets will be required to abide 
to mathematical rules breaking everything.

1. CASE 2^3^4

This is simple. The average Joe won't use 2^3^4. It is more the 
mathematically advanced, who will know what the precedence is. 
Therefore, I believe this won't be a pain to interpret correctly. FOR 
older files (ODF 1.x? & Excel) interpret like it was used to be. For 
newer one, there should be NO problem to interpret it differently.

*Now, why saving 2^3^4 this way in the spreadsheet?*

I remember that some years back, the decision was taken to store only 2 
digit years. And then came y2k. Is it that difficult to automatically 
store 2^3^4 either as 2^(3^4) (the correct version), or as (2^3)^4 
(incorrect version), so that EVERY software will ALWAYS interpret it 

I strongly recommend, that the OASIS document clearly specifies, that 
*Cases that could be mathematically ambiguous should be automatically 
RESOLVED using appropriately placed brackets* (whatever this resolution 
would be), so NO program, user, or changes over time will affect the 

2. CASE -4^2

This is more difficult to change, because average Joe might believe the 
current handling of this is correct. BUT see the first case: 
transforming this into (-4)^2 would remove confusion and allow for 
consistency of the formula in different programs and in the future.

If you wish to develop a solid format, strongly consider implementing a 
mathematically NON-ambiguous storing and displaying method. Otherwise, 
other programs (like the advanced statistical and mathematical programs) 
will yield ERRORS, making the use of these spreadsheets inappropriate in 
fields where serious data analysis is undertaken.


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