Implementing alternate compatibility functions (such as 0^0 = ERROR)
Hello, I've seen this was implemented in Apache Openoffice recently. Probably we can just merge it into Libreoffice. Commit: http://cgit.freedesktop.org/libreoffice/core/commit/?h=aoo/trunkid=908088f614cda46d9c996e40579611df27276394 Regards, Xisco ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Implementing alternate compatibility functions (such as 0^0 = ERROR)
I've seen this was implemented in Apache Openoffice recently. Probably we can just merge it into Libreoffice. And you did not notice the flood of useless discussion that ensued on the AOO list, with one contributor (partially) leaving AOO? PLEASE STOP THIS DISCUSSION NOW! ;) --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Implementing alternate compatibility functions (such as 0^0 = ERROR)
On Thu, 2013-02-21 at 21:50 -0600, Norbert Thiebaud wrote: The issue is purely academic, but if it _has_ to be resolved then yes a compatibility mode has a much better value that creating an 'alternate' function. True - though clearly there is some residual benefit in importing ODF files with this sort of function in them - luckily there is a ~zero deployed-base of that so far. As a general yard-stick, we take function compatibility with Excel extremely seriously - it is clearly imperative to our users to have confidence that their spreadsheets continue to work as they move to the world of ODF implementations. Having said that - when it comes to corner-cases we have much bigger problems in this area than this issue. One example would be the absence of a true 'boolean' type in our core; such that when you run the gnumeric test sheet here: http://git.gnome.org/browse/gnumeric/plain/samples/excel/operator.xls you can ponder at length whether: '=TRUE() Liz' should be true or false for example ;-) So - IMHO there is little value at all in further discussion on this topic, and backwards-compatibility with ODF + numeric sanity trumps the corner-case at least until we have a much more consistent set of corner-case solutions. But of course, I would defer to the calc team; and as Tor and Norbert says - -strongly- discourage an endless bike-shed on this from those outside the set of people who have already contributed code to calc. All the best :-) Michael. -- michael.me...@suse.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Implementing alternate compatibility functions (such as 0^0 = ERROR)
I'm sorry, I didn't know about that discussion. You're right, it's pointless to do the same here, so it's better just to stop the discussion. Please accept my apologies Xisco 2013/2/22 Tor Lillqvist t...@iki.fi I've seen this was implemented in Apache Openoffice recently. Probably we can just merge it into Libreoffice. And you did not notice the flood of useless discussion that ensued on the AOO list, with one contributor (partially) leaving AOO? PLEASE STOP THIS DISCUSSION NOW! ;) --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Implementing alternate compatibility functions (such as 0^0 = ERROR)
On 02/22/2013 04:51 AM, Michael Meeks wrote: On Thu, 2013-02-21 at 21:50 -0600, Norbert Thiebaud wrote: The issue is purely academic, but if it _has_ to be resolved then yes a compatibility mode has a much better value that creating an 'alternate' function. True - though clearly there is some residual benefit in importing ODF files with this sort of function in them - luckily there is a ~zero deployed-base of that so far. As a general yard-stick, we take function compatibility with Excel extremely seriously - it is clearly imperative to our users to have confidence that their spreadsheets continue to work as they move to the world of ODF implementations. Having said that - when it comes to corner-cases we have much bigger problems in this area than this issue. One example would be the absence of a true 'boolean' type in our core; such that when you run the gnumeric test sheet here: http://git.gnome.org/browse/gnumeric/plain/samples/excel/operator.xls you can ponder at length whether: '=TRUE() Liz' should be true or false for example ;-) So - IMHO there is little value at all in further discussion on this topic, and backwards-compatibility with ODF + numeric sanity trumps the corner-case at least until we have a much more consistent set of corner-case solutions. But of course, I would defer to the calc team; and as Tor and Norbert says - -strongly- discourage an endless bike-shed on this from those outside the set of people who have already contributed code to calc. All the best :-) Michael. My opinion is that it is probably useful to document any known issues, especially issues that may be considered for implementation. If we are able to identify issues, especially issues with easy solutions, then those can be added to the list of easy things to do in LO for new contributors. Norbert, along this same line, you stated: I think there are many more interop problems with much more visible and real-life effect that would be a better use of one's time. Do you consider any of these visible issues as something that can be posed as easy things for a developer new to LO to attempt? -- Andrew Pitonyak My Macro Document: http://www.pitonyak.org/AndrewMacro.odt Info: http://www.pitonyak.org/oo.php ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Implementing alternate compatibility functions (such as 0^0 = ERROR)
I was recently involved in a conversation related Calc and Excel compatibility. At issue is the fact that LO returns POWER(0,0) = 1 and Excel returns an error. I have seen two primary means of dealing with this suggested. The first is to create a compatibility function for POWER(x,y) to match the behavior in Excel. My understanding of how this would work is as follows. 1. Create another function such as POWER.ALTERNATE(x,y) that behaves as desired. 2. When an Excel file is read, every instance of POWER is replaced with POWER.ALTERNATE. 3. When an Excel file is written, every instance of POWER.ALTERNATE is converted back to POWER. I vaguely remember someone on list mentioning that they had implemented alternate Calc functions, but I do not remember the context. This leaves a few questions in my mind. (Q) Is a user able to use POWER.ALTERNATE inside of Calc? (Q) When saved as an ODS file, certainly we don't want to write POWER.ALTERNATE because then it is using a nonstandard function that will not be used anywhere else and can only be read by AOO. In other words, I assume that we would always write POWER rather than POWER.ALTERNATE and the only way to retain the behavior is to save the file as an excel file or to mess with user defined attributes while writing the file. The alternate suggestion was to add a compatibility mode. This has the advantage that it can be turned on and off at will so that Calc will simply behave that way. It also allows other functions to be changed to check the flag and behave accordingly. This also feels like a larger initial change and would require far more buy-in from the community to implement. -- Andrew Pitonyak My Macro Document: http://www.pitonyak.org/AndrewMacro.odt Info: http://www.pitonyak.org/oo.php ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Implementing alternate compatibility functions (such as 0^0 = ERROR)
On Thu, Feb 21, 2013 at 8:56 PM, Andrew Douglas Pitonyak and...@pitonyak.org wrote: The alternate suggestion was to add a compatibility mode. The issue is purely academic, but if it _has_ to be resolved then yes a compatibility mode has a much better value that creating an 'alternate' function. 1/ a compatibility mode can be use to deal with other discrepancies between the standards than just that power() corner case. 2/ if an implementation does not know about 'alternate' form they would not be able to represent the value _at all_ vs a compatibility mode that still use the underlying standardized function. iow a compat mode only impact the execution in one's environment and does not create random problem by polluting the document with 'extensions' that have no chances what-so-ever to be accepted in the standard. This has the advantage that it can be turned on and off at will so that Calc will simply behave that way. It also allows other functions to be changed to check the flag and behave accordingly. This also feels like a larger initial change and would require far more buy-in from the community to implement. Yep that is a problem for purely academic problems that do not have any actual use-case. I think there are many more interop problems with much more visible and real-life effect that would be a better use of one's time. Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
