> (even though we know the determinant of such a matrix must be > _, __, 0, or _.).
This is wrong. The determinant of a matrix that contains _ or __ can have any value. e.g. ] M=: _3]\ 1 _ 0 0 1 0 0 0, v=: ?1e5 1 _ 0 0 1 0 0 0 75158 -/ .* M 75158 ----- Original Message ----- From: Roger Hui <[EMAIL PROTECTED]> Date: Tuesday, February 26, 2008 0:31 Subject: Re: [Jbeta] Use of the name 'NaN' deprecated To: Beta forum <[email protected]> > > The NaN error will prevent operations to proceed > > uninterrupted. Suppose you have a large matrix and complex > > geometrical calculations. At some point it will yield > > _%_ for some positions in the matrix. Knowing your domains > > you would substitute the NaN's with some values like 0 or so > > *after the calculation*. > > > > Now let's see what happens with the new NaN error. You apply > > your complex expressions to your matrix, and one of the values > > triggers the NaN error. The whole matrix evaluation is invalidated > > and interrupted with the NaN error. It would be very hard or > inconcievable> to predict which initial values and at what step > would trigger > > NaN. The seeming alternative of Adverse :: won't be feasible > > either, as it has infinite rank and will slow down the calculation. > > NaN is an error indicator, a bit pattern that the hardware returns > instead of signaling error. When you say that "It would be > very > hard or inconcievable to predict which initial values and at > what > step would trigger NaN", you can substitute "cause an error" for > "trigger NaN". Hard to predict when an error would happen? > No kidding. > > As for slowing things down. I don't know about "complex > geometric calculations", but here is a common matrix > calculation, the determinant. If a matrix contains > _ or __, then its determinant can not be computed by > Gaussian elimination (do the math, you'll see), and > the only way I know of is expansion by minors. > The former is order n^3; the latter order !n (even though > we know the determinant of such a matrix must be > _, __, 0, or _.). So if you want to be fast, already you > have to do something when _ or __ is present, never > mind when _. is present. > > More slowing down: In J6.02 qbeta > x=: 1e6 [EMAIL PROTECTED] 0 > y=: 1e6 [EMAIL PROTECTED] 0 > a=: _. (1e5 [EMAIL PROTECTED] 1e6)}1e6 [EMAIL PROTECTED] 0 > b=: _. (1e5 [EMAIL PROTECTED] 1e6)}1e6 [EMAIL PROTECTED] 0 > 10 (6!:2) 'x*y' > 0.0345632 > 10 (6!:2) 'a*b' > 0.16342 > > The benchmark was done on an Intel Celeron (AMD Athlon > does much better). ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
