That makes good sense, and could be quite useful. The point I was trying to make about PLI not using terms like half precision etc., but specifying the needed precision is it is more hardware independent. Hardware now is oriented around 8 bits or multiples of that. But earlier hardware used 6 bits. Who knows what the future may hold? It is simply specifying what you need and not how to get it.
On Sun, Oct 8, 2017 at 9:24 AM, bill lam <[email protected]> wrote: > I am thinking of the opposite, if there are available resource, > adding new data type for single precision and half-precision > would have more benefits. My 2 cents. > > Вс, 08 окт 2017, Don Guinn написал(а): > > I realize this is stating the obvious, but the loss of precision is the > > result of 64 bit integer support. Previously "upgrading" a number from > > integer to float was exact. Though the residue problem for very large > > numbers still existed, at least it didn't involve loss of precision. > > > > It's my personal opinion that one should always be careful when working > > around the limits of a system. But what should be done when things go a > > little crazy around those limits? It is unfortunate that IEEE only > > implemented indeterminate (_.) when it could have set other flags in the > > unused bit configuration to indicate things like underflow, but not zero > or > > overflow but not infinity. But they didn't. > > > > A while back J had an option for upgrade to go to rational instead of > > float. It was useful in labs to more easily show interesting properties > of > > numbers. Is that option still around? If so it could be used in mod as an > > option. But it cannot be always known that the number will eventually be > > used in mod. And many transcendental verbs must go to float. > > > > Current hardware now supports quad precision float, at least some do. If > > quad float were used then the loss of precision goes away when converting > > 64 bit integer to float. But that doubles the size of float, and even > > though memory is getting huge it's still a concern for big problems. Not > to > > mention that quad float is probably slower than double float. And it may > > not be supported on all hardware, similar to the AVX problem. > > > > IBM's PLI has an interesting approach to precision. You told it (in > decimal > > digits) the largest numbers you will deal with and the number of digits > > after the decimal. Then it picked the best way to store the numbers given > > available hardware. In J we have 64 bit integers and floats with maybe 16 > > significant decimal digits and a tremendous range for exponents. Most > > problems we deal with don't need such big numbers. An argument many use > > against J in that it uses so much memory for small numbers. Perhaps a > > global setting with Foreign Conjunction could give a similar choice for > J. > > I would argue against it saying things like single/double/quad float or > > 16/32/64 bit integers, but specify what range and significance is need > and > > let J choose how to handle it. Including totally ignoring it for some > > implementations. Supporting this could make the J engine larger, but > nobody > > seems too concerned with the monstrous size Qt. > > > > Whatever happened with the idea bouncing around of defining a floating > > point of arbitrary size and precision like with extended integers and > > rationals? > > > > And now IEEE has a decimal float standard. Right now it seems that only > IBM > > has implemented it in hardware. But think of all the confusion we see > when > > decimal numbers like 1.1 are not represented exactly in J. > > > > Maybe I rambled a bit. But this all involves problems when, for one > reason > > or another, the hardware can't handle needed precision. > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm > > -- > regards, > ==================================================== > GPG key 1024D/4434BAB3 2008-08-24 > gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3 > gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3 > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
