To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=5658
------- Additional comments from [EMAIL PROTECTED] Mon Nov 24 21:58:16 +0000 2008 ------- discoleo->cornouws > For all needing 100% Excel compatability: make sure you have all > the same version of Excel as well as the same CPU. Both are known > sources for differences in more complex spreadsheets ... This is the kind of comment that doesn't bring anything useful to this issue. By the way, if you really want absolutely identical spreadsheet results, be also warned that different versions of OOo Calc, and gnumeric and probably any other major spreadsheet beyond MS Excel will yield different results, so you NEED to stick to exactly the same version of the same spreadsheet on the same processor. [Yes, a SPARC will handle floating point very different than most MIPS processors.] The problem however is very different than EXCEL compatibility: it is really the broken philosophy in Calc, that allows to compute WRONG results, without notifying the user. So, in the end, the user might well be unsuspecting that his calculations are utterly wrong, and might be so catastrophically wrong. To paraphrase a different user: > The question, also, is not “does OOo behaviour really cause more > real problems than incompatibility to Excel.” The incompatibility > already exists as Issue 5658 shows. Both spreadsheets do illegal > operations, *they just do them differently*. > > The real question is, “Do we want to have a spreadsheet that we know > is faulty, where the faults may be very serious and potentially > life threatening. So, the real issue is that Calc allows me to do: = 1 + '1,000,000 and get a "1" and have NO feedback that the result is probably utterly nonsense. The unsuspecting user will likely miss this wrong calculations. How often did you look into a 10,000 rows spreadsheet if some numbers are actual text? Be warned that Calc often imports csv as text. You end sometimes even with a number transformed to text. Format e.g. a column as text and enter now numbers. They end up as *strings*, and any mathematical operation is broken. You may well miss this on a foreign spreadsheet, and even inspecting the cells will devoid you of any useful information, because the apostrophe in front of the text is missing (for cells formatted as text - how often did you check that the cell was previously formatted as text?). And have you thought of a 50,000 rows spreadsheet. I already work with >100,000 rows (well, obviously not in Calc). What chance do I have to find the faulty string in this spreadsheet? [see e.g. http://www.openoffice.org/issues/show_bug.cgi?id=85328 - I was well unaware that various cells were text - and this was a happy example that I noticed is wrong. !4! different users beyond me did NOT recognize that the cell was actually text.] I would bet, NONE. And on a different note: THERE IS NO SUCH STRING AS 1!!!!!!!! If you mean the string 'one' than this is different from the number '1'. There is only one number '1' and NO string '1'. This is purely a programmers distinction with NO real backup in linguistics. '1' is a number. Basta. Not to confuse the issue with '1 is not a number'. This is indeed a composite string, but simple numerical symbols are always numbers. I already described more advanced ways to handle string-input in a previous post: http://www.openoffice.org/issues/show_bug.cgi?id=5658#desc123 Hope this clarifies some issues. --------------------------------------------------------------------- Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
