I think that you are making this out to be a big problem. I don't think it is. We have much bigger problems with coming up with good solutions to problems. Scaling is one of the biggest. That J deals with numbers as numbers, not as integer or float or whatever and does not predefine limits on array sizes removes many of the problems found in traditional programming languages. At the same time it generates other problems like double float cannot represent all 64 bit integers resulting in loss of precision with automatic conversion of integer to float.
Whether the benefits of J's approach outweigh the disadvantages depends on whom you ask. But possible solutions like those you suggested are only partial solutions. We need to watch for things that don't make sense, whether caused by our design, or the design of the programming language. They all have lots of gotchas. On Sat, Oct 14, 2017 at 9:11 AM, Erling Hellenäs <[email protected]> wrote: > Hi all! > > We now have an additional proposed solution from Raul, using extended > precision and rationals instead of integers. > > Any more proposed solutions? > > Opinions about the proposed solutions? > > Cheers, > > Erling Hellenäs > > > > On 2017-10-13 22:28, Erling Hellenäs wrote: > >> Hi all! >> >> You moved to 64 bit integer. You can't go back. Now there is a serious >> problem? You have to determine how to solve it? >> The simple solution is to move to quad precision floats? Is it possible >> to add support for keeping the integers ? The ability to do all integer >> arithmetic on integers? To stop auto-converting to floats? To internally >> work with quad precision floats in integer arithmetics? >> Maybe you could add support for the new IEEE decimal standard? Move >> integer arithmetic to them? >> Are there other solutions? >> >> Cheers, >> >> Erling Hellenäs >> >> On 2017-10-08 16:54, Don Guinn wrote: >> >>> 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 >>> >> >> >> ---------------------------------------------------------------------- >> 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
