I forgot the exact words, to paraphrase KEI, it is more important to do the right thing and ignore customer's request.
J'ers here are explaining to you why your request won't be integrated. This is the mindset of us. If you have also converted, you will share the same mindset with us. On Oct 15, 2017 11:10 PM, "Erling Hellenäs" <[email protected]> wrote: > The requesters are potentially willing to merge changes or finance > development? We can discuss their requests and try to find solutions to > their problems which we can merge? /Erling > > On 2017-10-15 16:55, Erling Hellenäs wrote: > >> Hi all! >> >> Maybe we can first determine what the problem is, then use our >> imagination to find possible solutions, then discuss the pros and cons of >> each possible solution, and then take decisions? >> People have different goals? Some wants to work together with others >> against common goals? Some wants to magnify themselves and derogate others? >> Some play their own favorite psychological game? >> Those who want to derogate others always destroy all creative processes >> by attacking all requesters? To be able to have creative discussions we >> have to stop this? We have to hinder them from attacking the person instead >> of discussing the facts? When it comes to the facts, their critical input >> is most welcome, just a little later in the creative process? >> >> Cheers, >> >> Erling Hellenäs >> >> On 2017-10-15 14:18, bill lam wrote: >> >>> Even results from current J is not mathematically incorrect, I don't >>> think >>> patch or proposal will ever be accepted because efficiency is very >>> important of J. The same holds true for GPU which does even trap NAN. >>> >>> Nothing personal, please don't feel offended. >>> >>> On Oct 15, 2017 8:08 PM, "Erling Hellenäs" <[email protected]> >>> wrote: >>> >>> I think you should probably move to a bugtracking system. Handle bugs >>>> there instead of on the wiki. /Erling >>>> >>>> On 2017-10-15 13:56, Erling Hellenäs wrote: >>>> >>>> We have a similar problem with IEEE floats and underflow. All old >>>>> programs are written under the assumption that precision is not lost in >>>>> division and multiplication operations. All old error estimations are >>>>> based >>>>> on this assumption. All these programs now give random results and >>>>> have to >>>>> be retested and rewritten, or we have to find a way to get an exception >>>>> when we have an underflow. /Erling >>>>> >>>>> On 2017-10-15 13:42, Erling Hellenäs wrote: >>>>> >>>>> Is there a result of this factual discussion we could study? >>>>>> As I see it the programmer is responsible for creating a program that >>>>>> gives correct results in the domains in which it is specified to give >>>>>> correct results. >>>>>> If modulo gives correct results only in a certain domain, this domain >>>>>> should be clear from the specification. >>>>>> The programmer who uses it is then responsible for controlling inputs >>>>>> and outputs, that they are in the correct domains. >>>>>> However, since this makes the programs much more complicated, we >>>>>> mostly >>>>>> create programs which verify their inputs and outputs, and if not in >>>>>> the >>>>>> domains in which the results are correct, we issue an error or >>>>>> exception. >>>>>> Then there is a question of compatibility. Programs were created >>>>>> before >>>>>> the change to 64 bit integers. The programmer verified their >>>>>> function, but >>>>>> the verification is no longer valid, so these programs have to be >>>>>> retested >>>>>> and rewritten, or we are stuck with tools and systems which give the >>>>>> users >>>>>> random results, and which are therefore not useful any more. /Erling >>>>>> >>>>>> 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/forum >>>>>>>>>>>> s.htm >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> For information about J forums see >>>>>>>>>>> http://www.jsoftware.com/forum >>>>>>>>>>> s.htm >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> For information about J forums see http://www.jsoftware.com/forum >>>>>>>>>> s.htm >>>>>>>>>> >>>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> For information about J forums see http://www.jsoftware.com/forum >>>>>>>>> s.htm >>>>>>>>> >>>>>>>>> >>>>>>>>> ---------------------------------------------------------------------- >>>>>>>> >>>>>>>> For information about J forums see http://www.jsoftware.com/forum >>>>>>>> s.htm >>>>>>>> >>>>>>>> ---------------------------------------------------------------------- >>>>>>>> >>>>>>>> >>>>>>> For information about J forums see http://www.jsoftware.com/forum >>>>>>> s.htm >>>>>>> >>>>>>> >>>>>> ---------------------------------------------------------------------- >>>>>> >>>>>> For information about J forums see http://www.jsoftware.com/forum >>>>>> s.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
