The nbeta is available for all platforms.
This beta include a new J Engine that changes the way NaN is treated. The
next beta will include new Dictionary documentation on NaN. For now, some
overiew comments.
Roger started out to make NaN behave 'properly' and went quite a ways down
this very frustrating road. Eventually it was decided to completely abandon
this fools errand. Overhead that affected all fp ops (whether they included
NaN or not) kept increasing. Code got more and more convoluted as
differences between compilers and hosts continued to surface. The price to
be paid was high and growing and any supposed benefit was less and less
tangible.
The decision was made to favor fast performance and clean, portable
implementation. And to ignore what happens if there are NaNs. I summarize
this as gigo (garbage in garbage out). The garbage out depends on the J
release, the compiler, data sensitive algorithms, the host, and the phase of
the moon.
J signals a NaN error if a J primitive would produce a NaN. For example, _%_
signals an error.
The intent is that the only source for NaNs is _. , 3!:n , and DLL calls and
other mechansims that put external data into J.
128!:5 is the only approved and reliable way to detect NaNs.
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
