Hi Regina, I'll try to give some long outstanding answers to questions you asked shortly before I went to OOoCon and then into vacation and then..
On Thursday, 2010-08-26 22:33:20 +0200, Regina Henschel wrote:
> next problem with matrices :(
>
> (All with German local with comma as decimal delimiter)
>
> Fill A1:C3 with
> 1 2 3
> 3 6 9
> 9,1 18 27
> Calculate =MINVERSE(A1:C3)
>
> I get
> 0,00000000-1.#NANE+000 #VALUE! #VALUE!
> #NUM! #NUM! #VALUE!
> #NUM! #NUM! #VALUE!
I got different results in OOO330m10 and DEV300m85, no error at all, and
even different in one value of the last column, being
OOO330m10 Solaris/x86:
28.1318681319 -3.5164835165 10
-819855292164869000 273285097388290000 7.79926253788309E-015
546570194776579000 -182190064925526000 -3.3333333333
DEV300m85 Linux/x86:
28.1318681319 -3.5164835165 10
-819855292164869000 273285097388290000 0
546570194776579000 -182190064925526000 -3.3333333333
Of course both obviously look wrong. Difference of 0 vs.
7.79926253788309E-015 might be because of different compilers'
optimizations, though it looks suspicious. I assume you're working on
Windows. Would be good to know what exactly happens.
> I guess, that the wrong notation in upper, left cell is already
> tracked in issue 114125.
That looks related, though I don't know at the moment how that should
occur in Calc. We usually convert all INF and NAN to errors. Which
milestone did you use?
> But I think, Calc should not return #NUM!
> or #VALUE! at all, but Err:502 (illegal argument), because the
> matrix is singular.
> The LU decomposition has a zero in the diagonal, so it is possible
> to detect this case. Excel and Gnumeric return #NUM! in the whole
> range.
I ran that in a non-product debug build where the LU decomposition is
written to stderr, there was no 0, which explains why singularity was
not detected. The code is in interpr5.cxx at line 767
fprintf( stderr, "\n%s\n", "lcl_LUP_decompose(): LU");
and displayed
9.1 18 27
0.33 0.066 0.099
0.11 0.33 1.8e-18
Can you compare that with your values?
In ScInterpreter::ScMatInv() line 924 some possible checks are
documented, of which one is implemented but disabled because
a "reasonably sufficient error margin" would have to be found for
fInvEpsilon. That would then set errIllegalArgument. Maybe going into
detail there could solve the problem for MINVERSE.
> If the user sees this result, he will be cautious. But it might be
> hidden as intermediate part of a larger formula. So the user does
> not notice that the result is totally wrong. LINEST needs
> calculating an inverse matrix for the statistics, but does of cause
> do not show the matrix but the statistics, so that the user might
> not detect, that the values are wrong.
> Gnumeric returns #ZAHL! errors and Excel returns the same wrong
> values as Calc.
>
> Should I test the intermediate results in LINEST to catch this cases
> and return an error?
Do you have a recipe to detect such cases? An error would be way better
than wrong results..
If the problem can be solved it would be worth to factor the code of
MINVERSE out to a general matrix inversion routine that can be used in
LINEST and maybe others.
Eike
--
OOo Calc core developer. Number formatter stricken i18n transpositionizer.
Signature key 0x87F8D412 : 2F58 5236 DB02 F335 8304 7D6C 65C9 F9B5 87F8 D412
OpenOffice.org Engineering at Oracle: http://blogs.sun.com/GullFOSS
--
Please don't send mail to the old e...@sun.com account that I used for mailing
lists, it phased out. Use eike.rat...@oracle.com instead. Thanks.
pgpgH2dfnPn2K.pgp
Description: PGP signature
