You may detect the range before feeding into |, e.g. 1 e.(=<:) @:<. 10^i.10 0
1 e.(=<:) @:<. 10^i.20 1 On Oct 9, 2017 12:07 AM, "'Skip Cave' via Beta" <[email protected]> wrote: > It seems to me that my particular problem with residue could be fixed in > the residue primitive. > > 13 | 10^i.20 > > 1 10 9 12 3 4 1 10 9 12 3 4 1 10 0 0 0 0 0 0 > > 13 | 10^i.20x > > 1 10 9 12 3 4 1 10 9 12 3 4 1 10 9 12 3 4 1 10 > > > What should happen: > > 13 | 10^i.20 > > >>Out of bounds error > > > It seems like residue just needs to check if the floating point number is > too big to process correctly, and throw an error. > > > Taking a longer view, in the future, IEEE 754 floating point may be > replaced with something that handles these issues more benignly. > > > www.posithub.org > > Inaugural Conference of Next Generation Arithmetic (CoNGA) - 28 March 2018 > > Focusing on unums and posits > > Next Generation Arithmetic Congress Meeting > > Call for Papers (Submission deadline: 17 Nov 2017) > > Co-located with Supercomputing Asia (SCA) 2018 Conference, at Resort World > Convention Centre, Singapore > > > https://groups.google.com/forum/#!forum/unum-computing > > > John Gustafson's talk on Unums 3.0: Posits and Valids > > http://web.stanford.edu/class/ee380/Abstracts/170201.html > > > > > Skip Cave > Cave Consulting LLC > > On Sun, Oct 8, 2017 at 10:36 AM, Don Guinn <[email protected]> wrote: > > > 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 > > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
