The modulus operation is very widely used, and that's precisely why your proposal would not be good for J. What I mean is that while there are a few people using modulus on large integers for various experiments in number theory, there are also a huge number of people using modulus on small floating-point numbers who will never notice the fact that it uses imprecise floating-point arithmetic.
My remark that the alternative was to "severely degrade J's performance" was directed at the suggestion to use exact arithmetic for these types of computations. The issue with warnings is that they would show up in too many cases, annoying all of the users who (to use an example from my own code) just want to find the name of the closest note to a given frequency. It might be possible to design tests so that the warning is given only when results are misleading, but tests like that are both very difficult to design and prone to slowing down typical uses of modulus. I consider the 64-bit IEEE float to be a huge success in software engineering in its ability to balance performance, accuracy, and simplicity. But handling numbers in computers is not a problem that can simply be solved: there are a lot of cases where 64-bit floats are not a good choice, or where they have to be handled carefully because of numerical issues. Running into one of these cases is something of a rite of passage for programmers, and there are so many diverse ways that it can happen that it's impossible for a programming language to try and anticipate it and warn the user. We can only hope that introductory materials will have alerted them to the possibility and that the internet will provide a quick answer as to why the results aren't coming out right. Anything else just gets in the way of all the programmers who have already learned about the dangers of floats. Marshall On Thu, Sep 07, 2017 at 06:56:25PM +0100, Rob B wrote: > Marshall, thanks for replying. > > You're right my main use of J is recreational mathematics although I'm only > vaguely aware of Project Euler. > > I do not entirely understand how this thread came to be about performance. > I presume this is to do with my mention of automatic conversion to extended > precision. A warning message would not impact performance. > > I find it hard ro believe that 'mod' is only used in recreational > mathematics. In any case are you saying that if code is rarely used then it > is acceptable for it to deliver the wrong answer? I reiterate my previous > point that a wrong answer is still wrong even when delivered efficiently. > > Regards, Rob > > > > On 7 Sep 2017, at 17:35, Marshall Lochbaum <[email protected]> wrote: > > > > Primality testing is a much less common use case than you think, and in > > fact I'm not aware of any use for extended-precision integers outside of > > recreational mathematics (I guess you can count cryptography, but anyone > > using extended-precision integers instead of large fixed-width integers > > for that falls squarely on the recreational side as well). It would be a > > poor choice to severely degrade J's performance to help out people doing > > Project Euler problems. > > > > Marshall > > > >> On Thu, Sep 07, 2017 at 12:54:58PM +0100, Rob B wrote: > >> Thanks Raul, I am familiar with these ideas, and using x: is almost a > >> reflex now. > >> > >> I feel that to protect the new J user, mod should convert to extended > >> precision automatically or issue an warning message. Giving tha answer > >> zero is very misleading. > >> > >> PS I am not so concerned with small numbers and measurability as with > >> large numbers and primality. Heisenberg's Uncertainty Principle is not > >> usually an issue for me :) > >> > >> Ragards, Rob. > >> > >>> On 7 Sep 2017, at 11:32, Raul Miller <[email protected]> wrote: > >>> > >>> The answer, oddly enough, is: yes. > >>> > >>> The philosophical arguments are buried here: > >>> > >>> https://en.wikipedia.org/wiki/Accuracy_and_precision > >>> > >>> The technical issues are buried here: > >>> > >>> https://en.wikipedia.org/wiki/IEEE_754 > >>> > >>> That said, if you have reason to be using numbers which are precise > >>> beyond anyone's ability to measure (and keep in mind Heisenberg > >>> Uncertainty as one of the practical limits on measurability), you > >>> should probably be using extended precision numbers (123x instead of > >>> 123). This will give you exact results in exchange for a performance > >>> penalty. > >>> > >>> Thanks, > >>> > >>> -- > >>> Raul > >>> > >>> > >>>> On Thu, Sep 7, 2017 at 4:42 AM, Rob B <[email protected]> wrote: > >>>> On reflection my real question is; should mod suddenly and without > >>>> warning give the wrong answer when a number gets suffiently large? I > >>>> have been caught by this many times. The incorrect answer zero is > >>>> problematic as it suggests divisibility. > >>>> > >>>> Apologies if this has all been discussed before. > >>>> > >>>> Regards, Rob Burns. > >>>> > >>>> > >>>> > >>>>> On 6 Sep 2017, at 09:11, Rob B <[email protected]> wrote: > >>>>> > >>>>> Thanks, > >>>>> > >>>>> I now see it's reasonable for ^ to convert to flost and *: to remain > >>>>> exact. > >>>>> > >>>>> The other discrepancy is probably due to my old version, iPad 701. > >>>>> > >>>>> Regards, Rob Burns. > >>>>> > >>>>>> On 5 Sep 2017, at 17:48, HenryRich <[email protected]> wrote: > >>>>>> > >>>>>> datatype 47^2 > >>>>>> > >>>>>> floating > >>>>>> > >>>>>> > >>>>>> So > >>>>>> > >>>>>> (n^2) | 5729082486784839 > >>>>>> > >>>>>> is promoted to float, and loses precision. Same when the big number > >>>>>> is extended - it's converted to float. > >>>>>> > >>>>>> For > >>>>>> > >>>>>> (x: n^2) | 5729082486784839 > >>>>>> > >>>>>> I get 147 as the result. > >>>>>> > >>>>>> Henry Rich > >>>>>> > >>>>>>> On 9/5/2017 12:41 PM, Rob B wrote: > >>>>>>> Could someone explain this please? > >>>>>>> > >>>>>>> n=.14 > >>>>>>> n > >>>>>>> 14 > >>>>>>> (*: n) | 5729082486784839 > >>>>>>> 147 > >>>>>>> 196 | 5729082486784839 > >>>>>>> 147 > >>>>>>> (n^2) | 5729082486784839 > >>>>>>> 0 > >>>>>>> (n^2) | 5729082486784839x > >>>>>>> 0 > >>>>>>> (x: n^2) | 5729082486784839 > >>>>>>> 0 > >>>>>>> (x: n^2) | 5729082486784839x > >>>>>>> 147 > >>>>>>> > >>>>>>> > >>>>>>> Regards, Rob Burns > >>>>>>> ---------------------------------------------------------------------- > >>>>>>> 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
