Hi Yue, On Tuesday, 2008-03-18 15:07:56 +0800, Lvyue wrote:
> I began to work on issue78781 yesterday. Fine, thanks. > Compared with Excel, I found there are two things I should modify. > > 1. while input: =INDEX($D$27:$P$27;2) > the result should be value of E27. Correct. For a row vector the row number acts as a column number. > 2. while input: =INDEX(($D$27:$P$27;$D$29:$P$29);2) > the result also should be value of E27. Also correct, because if the area number is omitted area 1 is taken. > so I made some change, and attach the patch on issue78781. > please check it, and if I miss anything, please tell me. I think that's all what i78781 is about and your approach looks like it would work. Similar behavior should of course still be observed for a column vector, see ODFF spec. Note that the current version available for download has an error and mixed up terminology of row vector with column vector and vice versa, I already corrected that in my editorial copy, sorry if that caused any confusion. Corrected version should read: | If DataSource is a one-dimensional column vector, Column is optional or | can be omitted as an empty parameter (two consecutive ;; semicolons). If | DataSource is a one-dimensional row vector, Row is optional, which looks | as if Row is taken as the column offset into the vector, or can be | omitted as an empty parameter (two consecutive ;; semicolons). I didn't check implementation yet, the patch looks good, I'll create a new CWS odff03 to apply and test all pending patches. Unfortunately there's more to the INDEX() function, as there are combinations of omitted parameters possible, as described in the ODFF spec. Could you please check what the function's implementation is missing? I implemented much of it in CWS odff but noted down that we're not fully compatible yet for the array cases. For example, related is http://qa.openoffice.org/issues/show_bug.cgi?id=66930 Don't get confused by the original submitter's description, the issue is not about LOGEST() not working correctly but INDEX() not returning a vector for the array case. > BTW, did you see the 4th patch of i86643? > I'm not sure if the handle of errNoName is right, > but it is indeed a disturb of counting correctly. I don't quite understand the reasoning there. Why do you restrict the precondition to errNoName and only then set nGlobalError=0? Also, why ignore an error only if nGlobalError!=NOTAVAILABLE? IMHO all errors are to be ignored for COUNT() respectively counted for COUNTA(). Btw, the expression nCount += ( eFunc == ifCOUNT2 )? 1:0; should better be written as if (eFunc == ifCOUNT2) ++nCount; > Ok, that's all about the issue, I have a personal question. :) > Sometimes I feel confused about the ODFF, > I have seen the document about ODFF, it introduced many formulas. > But I'm still not sure what I should do on ODFF. > Make the formula act as the document says and keep it compatible with Excel? > Is that all I should do? In general yes. If there is a discrepancy between ODFF specification and Excel behavior that is not explained in ODFF please drop me a note so I can investigate. Please also give me a heads up if the ODFF spec isn't clear enough or lacks details one must know to implement the desired behavior, also if observing Excel behavior clarifies something that wasn't clear in the ODFF spec. > Wish you a nice day! :) Thanks, same to you :) Eike -- OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer. SunSign 0x87F8D412 : 2F58 5236 DB02 F335 8304 7D6C 65C9 F9B5 87F8 D412 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't send personal mail to the [EMAIL PROTECTED] account, which I use for mailing lists only and don't read from outside Sun. Use [EMAIL PROTECTED] Thanks.
pgpalQGVlgymd.pgp
Description: PGP signature
