I got these in AMD Athlon
10 (6!:2) 'x*y'
0.030096498
10 (6!:2) 'a*b'
0.029117603
a*b is faster?
Roger Hui wrote:
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).
----- Original Message -----
From: Oleg Kobchenko <[EMAIL PROTECTED]>
Date: Monday, February 25, 2008 20:09
Subject: RE: [Jbeta] Use of the name 'NaN' deprecated
To: Beta forum <[email protected]>
Thank you for clarifying the rationale for the
NaN error.
In some languages division by zero is bad and
they throw an error. While in other very well-designed
languages like JavaScript, NaN is perfectly acceptable,
without an error, and behaves like it used to in J,
supposing the same machine/compiler differences.
Trapping the NaN error seems like an extra effort,
as opposed to just allowing it to happen with a possibility
of cleaning up the data in an extra step, while allowing
other calculations to proceed.
The clean-up operation would use a conjunction like
the new one, or the same code invoked with a special-cased
_.=y or x=_. expressions for code sugar.
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
inconcievableto 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.
These are just a few examples how it's not very clear to see
practical benefits of the new NaN error. On the contrary,
it only seems to serve some seemingly pedantic goals.
Finally, if someone really wanted an error on NaN,
wouldn't be available with:
[EMAIL PROTECTED]@(1 e. ,)@(_. = ])
--- Henry Rich <[EMAIL PROTECTED]> wrote:
It was bad because _. as a data value is bad. _. does not
conform to any specification. On some machines/compilers
it does one thing, on others it does another. The interpreter
could conceivably enforce some rules, but that's a waste
of computer and developer time that nobody thinks is a
good idea.
Since you can't count on the _. in your nouns behaving
predictably, the interpreter should make sure that it
doesn't generate them. Ergo, the NaN error. If you
ask for an operation that would have produced a _., you
have made a mistake and you were going to come to grief
for it; the NaN error just makes you fail a little earlier,
at the source of the problem, so you can fix it.
The external NaN remains an unavoidable possibility, but just
as with any other possible source of bad data, you need to
remove the NaN before you start working on the data.
I have been making a lot of noise but, to repeat myself,
I think this change is a big improvement. I only quibble
that I think the NaN error is misnamed and incompletely
applied.
Henry Rich
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Oleg Kobchenko
Sent: Monday, February 25, 2008 9:08 PM
To: Beta forum
Subject: Re: [Jbeta] Use of the name 'NaN' deprecated
Can somebody summarise how the old treatment of NaN was bad:
_%_
_.
and why it is better now, with NaN error, when there is
still a chance
of external NaNs.
On Feb 25, 2008, at 18:08, "Eric Iverson"
<[EMAIL PROTECTED]> wrote:
Can more angels dance on _. than a NaN?
I think of domain as about arguments, not results.
The choice to have NaN error has been made. Arguments
against
are interesting but not compelling. The release is in the
pipeline and can't be stopped. I for one am thankful for
this
as it has been a long haul!
----- Original Message ----- From: "Henry Rich"
<[EMAIL PROTECTED]>> > To: "'Beta forum'"
<[email protected]>> > Sent: Monday, February 25, 2008 5:38 PM
Subject: RE: RE: [Jbeta] Use of the name 'NaN' deprecated
1 o. 1e9 is quite different from 1 o. _ , I think.
If you wanted to, you could calculate
1 o. 1000000000x
to any desired precision. You choose not to support
some values, and that's properly a limit error. But
1 o. _
cannot be calculated, even in principle. It should
produce _. for exactly the same reason _-_ does.
My point is, that by introducing 'NaN error' you have
shouldered an implied responsibility to report domain
errors as NaN errors when the error comes from the mathematical
necessities of the user's request rather from implementation
decisions. I just think you should forget the distinction
and call them all domain errors.
Henry Rich
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Roger Hui
Sent: Monday, February 25, 2008 11:48 AM
To: Beta forum
Subject: Re: RE: [Jbeta] Use of the name 'NaN' deprecated
1 o. y and other similar periodic functions signal
limit error when y exceeds a certain theta. Thus:
1 o. 1e9
|limit error
| 1 o.1000000000
1 o. _ is more of the same.
For finite x and y, the dictionary defines x|y
as y-x*<.y%x+0=x . This device is as good
(or as bad) as any other to make sense of the
cases when x or y are infinite. Accordingly:
res=: 4 : 'y-x*<.y%x+0=x'
10 res _
|NaN error: res
| y -x*<.y%x+0=x
_ res __
|NaN error: res
| y-x*<.y %x+0=x
Basically, 10|_ founders on doing _-_ , and
_|__ founders on __%_ . Thank you and
congratulations for being the first successful
hunter in the treasure hunt.
----- Original Message -----
From: Henry Rich <[EMAIL PROTECTED]>
Date: Monday, February 25, 2008 2:34
Subject: RE: [Jbeta] Use of the name 'NaN' deprecated
To: 'Beta forum' <[email protected]>
One can argue that more information is better than less; or
one can argue that implementation detail should be kept
private. I prefer the latter. Maybe it's a
matter of
taste.
I can't see the reason for a distinction between the
following two errors:
_ - _
|NaN error
1 o. _
|limit error
except that the first is a _. that the hardware generates,
while the second _. is detected in software. They're both
domain errors because the proper result is _. . When you
introduce 'NaN error', aren't you giving yourself the
additional burden of having to decide which errors it
most precisely describes?
Just nosing around, what about this:
10 | _
0
shouldn't this be a NaN error?
_ | __
__
shouldn't this be a NaN error? At the least, shouldn't
the result be positive?
Henry Rich
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Roger Hui
Sent: Monday, February 25, 2008 1:04 AM
To: Beta forum
Subject: Re: [Jbeta] Use of the name 'NaN' deprecated
Do change 'NaN error' to either 'domain error' (preferred)
or '_. error' .
It is advantageous to have a message for "NaN error"
distinct from "domain error", so that when you get
one of them you don't have to puzzle over what kind
of domain error it was. In a sense they are all domain
errors, but it is helpful to have "rank error", "index
error", etc.
and now "NaN error".
As for the exact spelling of the message, you can change
it to whatever you like via 9!:9 .
----- Original Message -----
From: Henry Rich <[EMAIL PROTECTED]>
Date: Sunday, February 24, 2008 9:40
Subject: RE: [Jbeta] Use of the name 'NaN' deprecated
To: 'Beta forum' <[email protected]>
I think you are replying to a different argument than the
one I was trying to make.
I wasn't suggesting that _. be 'above that' in the
sense of
following certain J-defined rules independent of the
IEEE spec. That would be OK but if it's too hard,
let it go.
I am happy with all the implementation decisions you
have made.
I am particularly happy with raising error when _. would
be created.
My only objection is to using the name 'NaN'. Maybe
you use
a NaN for _., but I see no reason to pollute the
documentation> > > > > with that term. I AM suggesting
that the language spec be
'above that', because NaN is a new and unnecessary concept
within J numbers.
And _. IS a number. qbeta tells me so:
9!:14''
j602/beta/2008-02-22/22:30
3!:0 (_.)
8
Don't change a line of code. Do change the doc of
128!:5
to say
it checks for the presence of _. rather than of NaN.
Do change
'NaN error' to either 'domain error' (preferred) or '_.
error' .
The only appearance of NaN in the docs should be the
one in _.,
which is
The indeterminate _. is provided to aid in
dealing with
NaN (not a number) in data from external
sources...> > > > >
This makes clear that NaN is IEEE, not J.
Occam's razor.
Henry Rich
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
