It's perhaps worth noting that we can have this kind of error mechanism right now:
safe=:[ assert@(~: >:) mod=: |&safe 13 mod */19 29 59 79 89 109 119 139 149 179 199 |assertion failure: assert | 13 mod*/19 29 59 79 89 109 119 139 149 179 199 13 mod */x:19 29 59 79 89 109 119 139 149 179 199 4 FYI, -- Raul On Mon, Oct 16, 2017 at 12:50 AM, 'Skip Cave' via Beta <[email protected]> wrote: > I still don't quite understand why the issue I mentioned could not be fixed > in the modulo primitive, by simply checking if the right argument has > gotten too big for the modulo primitive to function correctly. It looks > like when modulo tries to handle floating numbers larger than 10^15 or so, > it gets an error. So why not check the size and report the error if the > number is too big, rather than giving the erroneous answer of zero? > > 13|10^15 > > 12 > > datatype 13|10^15 > > integer > > > 13|10^16 > > 0 > > datatype 13|10^16 > > floating > > > What should happen: > > > 13|10^16 > >>> Domain error, argument too large, you need to use extended integers, or > something equivalent. > > Skip Cave > Cave Consulting LLC > > On Sun, Oct 15, 2017 at 10:39 AM, Raul Miller <[email protected]> wrote: > >> You are free to move on. >> >> You do not have to change J (and, thus, making it harder to learn) >> when you do so. >> >> That said, no one has silenced *you* - you are currently posting more >> here than everyone else combined. If anyone is being silenced, it's >> others here on the forums. >> >> Thanks, >> >> -- >> Raul >> >> >> >> >> On Sun, Oct 15, 2017 at 10:37 AM, Erling Hellenäs >> <[email protected]> wrote: >> > Hi all ! >> > >> > I don't think we should turn down change requests because the requester >> does >> > not have the same qualifications as Ken Iverson. I think we should have a >> > factual discussion about the requests in which the qualified people we >> have >> > available today participate. I think we have to accept that Ken Iverson >> is >> > no more alive and that we have to move on without him. We have a lot of >> > qualified people in our maillists. If we don't silence them by attacking >> > them as soon as they say something, we are well qualified to take >> decisions >> > and move on. >> > >> > Cheers, >> > >> > Erling Hellenäs >> > >> > >> > On 2017-10-14 21:19, Don Guinn wrote: >> >> >> >> I think we have had a factual discussion on the molulo problem. We just >> >> haven't found a good solution to the problem. Larger precision only >> moves >> >> the problem. It does not fix it. None of the possible solutions >> presented >> >> so far seem satisfactory because there are so many ways for them to fail >> >> anyway, if it is assumed that coming up with a residue of zero is really >> >> wrong when the numbers presented to residue exceed known precision >> limits. >> >> >> >> We learned several good things in this exercise. One, the square root of >> >> an >> >> integer perfect square stays integer. Two, we can't count on conversion >> of >> >> integer to float to be exact. Three, solutions to problems must be >> >> realistic. There will almost always be compromises and tradeoffs. We >> must >> >> watch answers we get as was done by whoever asked the question in the >> >> first >> >> place. That he asked the question is most important. It now makes us all >> >> aware of some possible problems we can get into when pushing the limits >> of >> >> the hardware and software. >> >> >> >> As to spinoffs. It is great for people to explore alternative solutions >> to >> >> programming language problems, whether J, C or any other language. But >> >> they >> >> are explorations. That doesn't mean that they will stand for the test of >> >> time. Ken and many others spent a lot of careful designing J. It is >> >> important to fully understand their work before trying to "improve" on >> >> what >> >> they did. >> >> >> >> On Sat, Oct 14, 2017 at 12:32 PM, Erling Hellenäs >> >> <[email protected]> >> >> wrote: >> >> >> >>> Hi all ! >> >>> >> >>> I think all problems should be put into the bugtracker and that there >> >>> should be factual discussions about how to solve them, so that, should >> >>> anyone want to finance or merge a solution, they can do so. >> >>> If we deny that any problems exist there will be no development. >> >>> If we turn all requests for change down there will be no development. >> >>> People are cloning J and are willing to supply their patches for free. >> If >> >>> we don't cooperate with them there will be no development. >> >>> >> >>> Cheers, >> >>> >> >>> Erling Hellenäs >> >>> >> >>> >> >>> >> >>> >> >>> On 2017-10-14 19:14, Don Guinn wrote: >> >>> >> >>>> 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 >> >>>> >> >>> >> >>> ---------------------------------------------------------------------- >> >>> 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 >> > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
