Jose Mario Quintana wrote: >> On Behalf Of John Randall >> J can already represent _ and __ . I assume that NaN results in >> domain error. There is some argument for representing +/-0, but I am >> not sure this is completely helpful. It would change 0%0 in >> incompatible ways. I am happy with tolerant comparison. Most of the > > I do not understand why this has to be necessarily the case. The result > of > 0%0 from the chip should be NaN; but, what would be the disadvantages of > overwriting it as 0 with the sign taken according the customary division > rules? (I am probably missing something here.) > My concern here are the automatic type conversions J reserves the right to make. Maybe I just don't understand when or how they are done. Choices made in other languages are sometimes surprising. For example, in double to int conversions, Java converts NaN to 0 and Double.POSITIVE_INFINITY to Integer.MAX_VALUE.
> I tried to see where J stands on some issues raised in 'Floating points: > IEEE Standard unifies arithmetic model' by Cleve Moler, > > NB. "Singular" System > ............ Matrix manipulations are a huge source of problems. In principle, no matrix coming from observed values is singular, since almost all arbitrary small perturbations of the entries make it nonsingular. Using %. with an ill-conditioned matrix is not going to give sensible results: you need some algorithm. For dense matrices, the LAPACK routines (which are all direct methods) go to great lengths to precondition the matrix. For sparse matrices, you may be better off using iterative techniques. I do not quite see how floating-point representation applies to all this: you cannot get around it with slick notation. > > Nevertheless, there are apparent advantages in the Floating Point model > that > MATLAB follows, aside from +/- 0, for some applications (and it would be > nice to squeeze also extra representation bits when possible). > Incidentally, I assume that nowadays all the Pocket PC chips follow the > IEEE > standard. Is that correct? > As far as I know, all recent computers (except maybe some Crays) follow at least part of the IEEE 754 standard. This even includes some GPUs. > According to Murphy, any J change would make programs crash (e.g., the x., > y. change, etc.). Alternatively, instead of changing the J FP model, an > interface a la R to an open source MATLAB clone (e.g., SCILAB or SciPy) > could become handy when it does matter; provided that one of them is FP > suitable. Is there any? > I favor this approach. There is a huge amount of free numerical software. While "pure J" approaches may be satisfying, there are difficult practical issues that need to be addressed by specialists in the problem domain. This is even true with non-numerical software: I use wget rather rolling my own with sockets because I do not understand enough of the issues, while the wget people do. While J does not actively discourage using foreign libraries, it is not so easy to interface with them. I would applaud any moves in this direction. Best wishes, John ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
