All you are saying is that errors can happen in programs
and some errors are tough to handle. My own opinion
is that using _. to denote error makes errors harder
to handle, because it allows execution to continue
after encountering an error and thus making
it harder to find the original source of the error.
Consider the following benchmark:
x=: 1e4 100 [EMAIL PROTECTED] 0
a=: 1e4 100 $ _ (500 [EMAIL PROTECTED] 1e6)} __ (500 [EMAIL PROTECTED]
1e6)}1e6 [EMAIL PROTECTED] 0
6!:2 '+/"1 x'
0.00510791
6!:2 '+/"1 a'
|NaN error
| +/"1 a
6!:2 '+/ :: 0:"1 a'
0.0327701
Adverse is used to handle the NaN error. The factor
of 6.5 cost compares favorably with the factor of 5
we saw in multiplying two 1e6 vectors with and
without NaN on the Intel Celeron.
----- Original Message -----
From: Oleg Kobchenko <[EMAIL PROTECTED]>
Date: Tuesday, February 26, 2008 10:00
Subject: Re: [Jbeta] Use of the name 'NaN' deprecated
To: Beta forum <[email protected]>
> That was my point. I was deliberately using a vague
> reference to a "complex geometrical calculation" to
> argue that from computability, decidability or feasibility
> viewpoints it's not always practical to predict emergence
> of NaNs somewhere in the middle of a complex computation,
> even starting off with seemingly reasonable data.
>
> I was referring to matrix meaning more the scalability
> feature of J to spread the same calculation over an array
> of similar objects, rather than matrix as a single object;
> and related performance implications.
>
> Whereas with uninterrupted execution it was possible
> to analyse the result and "fix" individual faulty elements
> after the calculation, while letting the rest of the "good"
> data to be computed to completion.
>
> Now with the NaN error, it wouldn't be possible to
> get any result if there is a chance that some infinite
> or indeterminent values appeared in the middle of
> calculation.
>
> In order to attempt to prevent a NaN error, it would
> be necessary to break the calculation into stages where
> there are likely places for bad data to emerge and
> fix it. Although it would not garantee that all possible
> cases would be covered. So there is still a chance that
> a NaN error will unexpectedly appear at run-time in production.
>
>
> --- Roger Hui <[EMAIL PROTECTED]> wrote:
>
> > > (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
