|Re: Overwriting 41C module internals|
Message #11 Posted by spb on 29 Apr 2011, 9:31 p.m.,
in response to message #10 by 聲gel Martin
Is this true on a working Advantage module? I would've expected it, like for example the 15C, to `invert' [[0, 0], [0, 0]] to [[10e99, 0], [0, 10e99]] as an artefact of the numerical algorithm used (and the limits of the machine itself). This is what the Advantage module I have gives if the matrix is inverted immediately after entering. Inverting again gives [[10e-99, 0], [0, 10e-99]], again matching the behaviour of the 15C. Attempting to do the same thing following taking the determinant gives the nonsensical result.
Well, any singular Matrix (with Det=0) will yield the same absurd result since it won't be invertible. That's why I asked before if det#0 as a condition.
In any case it gives a similarly nonsensical result for [[1, 2], [3, 4]]. Specifically, inverting and re-inverting after taking the determinate does not give the original matrix, but rather apparently arbitrary values in the diagonal elements.
I don't know if it's only in one function; I've only seen problems with one function, but I haven't attempted to manually check every function in the module. It's even possible that there are different errors in, for example, the solver used by MATRX as well as MDET. I was just assuming that the solver called MDET internally and so the problem with MDET explained the spurious results given by the solver.
It's highly unlikely (albeit of course possible) that there's such an issue in the module, affecting just one function - that's what made me suspicious in the first place.