Roger Hui <[EMAIL PROTECTED]> wrote: > If _. is removed altogether and you get a NaN in > your data (from external sources), that makes the > data very nasty to deal with, and imposes an overhead > on other data that has nothing to do with NaN. e.g. > > wd 'blah blah blah0' > |NaN error > | wd'blah blah blah' > wd 'blah blah blah1' > NB. works, but J has to check data for NaN
> The indeterminate _. is a numeric atom. It is provided > to aid in dealing with NaN (not a number) in data from > external sources, and should be removed from such data > as soon as possible. ... I wasn't suggesting that _. be removed from the language; it seems that in 6.02 this is already being done in part. I was merely suggesting that the spelling '_.' be removed from the number parser. so there was no 'easy' way for a J prgram to create NaNs. This is currently already the case for -NaN, and all the other flavors of NaN. In this way, NaN values from external sources can still occur, but the only way NaNs could be explicitly created by J software would be using 3!:2 (for rare cases where NaN is REALLY necessary) As I undertand it, J primitives in 6.02 can no longer generate NaN results (other than by copying). -- Mark D. Niemiec <[EMAIL PROTECTED]> ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
