Apache OpenOffice (AOO) Bugzilla – Issue 99140
ODFF: OOo CONVERT_ADD() with new conversion factors
Last modified: 2017-05-20 11:41:49 UTC
CONVERT_ADD() changes. Add new conversion factors, and add prefix support.
Created attachment 60113 [details] Patch 1.
Type PATCH.
Hi, Eike I have tested the problem of string length. On my computer, in OOo, the biggest string length is 65535, and when I continue to type in, the string continue becoming longer, but the length remains 65535, no error message. (PS. the application become very slow.) In Excel, the biggest string length is 32767, and no more character can be typed in, the length remains 32767, no error message too.
Hi Yue, your last comment seems to be meant for issue 97052 instead..
Scheduling for inclusion in CWS odff06.
@dr: could you review this patch please? Thanks Eike
this function is for compatibility with the Excel analysis addin. Do the changes add functionality that Excel already provides? I will attach a test document that you can use to check whether there is something broken. On first sheet, all differences between Excel and Calc are counted. This value must be 312, because in our eyes Excel sometimes simply calculates wrong according to international standards. The next value "errors" must be 0. This is a counter for all results that should be exactly equal in Calc and excel. On third sheet, you are able to combine all units with all prefixes. Place cursor to cell D3 and use the combobox to check all units. Differences/errors should always be 0. On last sheet, performance of the CONVERT_ADD function is tested. Hit F9 key to start the test. You may compare the measured time in your new version with the time in an older Calc.
@dr: > Do the changes add functionality that Excel already provides? No, it adds additional functionality defined by ODFF.
Created attachment 61918 [details] CONVERT_ADD test document
test document published on http://sc.openoffice.org/testdocs/index.html
Hi, Daniel thank you for the test document, I found something wrong. and after I have fixed those things, I will submit another patch.
Created attachment 62184 [details] patch 2.
With this patch, the count of all differences between Excel and Calc is 312, but the value "errors" is 320, because we do not support prefix for all unit names, so, there must be some errors. about the performance, my new version with this patch took 9 or 10 seconds to caculate, while the older one took 5 or 6 seconds. another question is that, the spec said if there is a naming conflict, the unprefixed name shall take precedence. I don't completely understand, take "pc" for example, does that mean, when we meet "pc", should we always regard it as a length unit name?
As far as I know the unit/prefix names of the original (Excel) function have been designed to not result in any conflict. Is this a problem now?
yes, some new unit names are added, so, there are some conflicts, like "pc" and "hh".
In cws odff06: revision 275559 scaddins/source/analysis/analysishelper.cxx scaddins/source/analysis/analysishelper.hxx Slightly changed ConvertData::GetMatchingLevel() to use sal_Int32 instead of xub_StrLen for length and character positions. Also changed the condition to test for SI prefixes such that IsPrefixSupport() is checked first before string comparisons, and length of string is checked to not start comparing a string on an arbitrary pointer position in case the unit string passed was just one character.
Created attachment 64438 [details] added category Information to test cases
Note: at least on unxlngi6 there are some minor differences between the numbers calculated by CONVERT_ADD and the MUST checks for units such as 'u' or 'e' or 'Wh' because the factors of those aren't exactly binary representable in IEEE 754 double when compiled from the constants. To solve one had to work out bit patterns with better approximations or do some intelligent rounding when constructing ConvertData.
Reassigning to QA for verification.
verified in internal build cws_odff06
A minor point for sure, but I wanted a full list of all the units, so I made a table from the source code here, and the ODFF spec, and attached it to a documentation issue: Issue 110342.