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
