So m. is (or rather, will be) new, not old... Brilliant! Thanks, Mike Sent from my iPad
> On 17 Apr 2023, at 19:56, Henry Rich <[email protected]> wrote: > > In the next beta u m. n means 'u(mod n)' and will work for + - * % ^ . %. > coming soon. > > The only specials I see with m&| are m&|@^ and m&|@(n&^) which can be > replaced by [n] (^ m. m) y. > > Example: 5 % m. 7 (9) gives 5 *(mod 7) (inverse of 9(mod 7)) > > Henry Rich > >> On 4/17/2023 2:07 PM, 'Michael Day' via Programming wrote: >> u m. n ? I thought m. disappeared many versions ago, along with x. y. etc ! >> Could you provide an example? And is m&|@u deprecated for other verbs u ? >> >> Float results would be helpful. Presumably an array would be returned as >> float >> if at least one element needed to float, as usual. >> >> Thanks again, >> >> Mike >> >>> On 16/04/2023 17:15, Henry Rich wrote: >>> I think I have figured out a way to return float when the result has been >>> made inaccurate. >>> >>> We had no choice about m&|@^ for negative y: the behavior of that is >>> defined by the language, and it isn't modular. >>> >>> u m. n is a much cleaner solution, and faster. m&|@^ is deprecated. >>> >>> Henry Rich >>> >>> On Sun, Apr 16, 2023, 11:51 AM 'Michael Day' via Programming < >>> [email protected]> wrote: >>> >>>> Thanks for this and your previous comment re (-:<.@*<:) >>>> I'm afraid I've only just noticed this later reply in my J mail folder. >>>> >>>> I was going to grumble about x!y remaining integer even when the value >>>> might be wrong. >>>> Perhaps you or others might think of a suitable warning comment in NuVoc >>>> about dyadic ! . >>>> 2!y could perhaps be treated as special case, being a triangular >>>> number, y(y+1)/2 where >>>> one could right shift whichever of y, y+1 is even, but presumably that >>>> would involve too >>>> much overhead. Caveat Calculator, I suppose. >>>> >>>> BTW, I see you've decided against implementing x m&|@^ y for negative >>>> integer y, integer x, >>>> and extended m. (Though I don't remember m needing to be extended in >>>> earlier discussions!) >>>> A pity, but it's been useful to learn that the idiom is well supported >>>> for positive y. >>>> >>>> Cheers, >>>> >>>> Mike >>>> >>>> On 14/04/2023 14:22, Henry Rich wrote: >>>>> As (x!y) is coded, the calculation is done in floating-point and then >>>>> converted to integer if the result will fit. Loss of significance >>>>> during the calculation will make the result inaccurate. >>>>> >>>>> I think it's a JE error to return an integer value when that value >>>>> might be wrong. Unfortunately, the way the internal interfaces are, >>>>> it's difficult to leave the value as floating-point, so you cannot use >>>>> the fact that an integer was returned as a guarantee of accuracy. >>>>> >>>>> Henry Rich >>>>> >>>>> On 4/13/2023 11:34 AM, 'Michael Day' via Programming wrote: >>>>>> Yet again I found myself resorting to Pari GP for a calculation; my >>>>>> J function had been giving >>>>>> correct answers to a problem for lowish inputs, but apparently gave >>>>>> up at some stage for >>>>>> higher values; I then coded the calculation in Pari GP which gave >>>>>> the same results for low >>>>>> inputs, but diverged from J at the business end. >>>>>> >>>>>> Looking for inconsistencies between the two functions, the >>>>>> divergence seems to appear >>>>>> around this case: >>>>>> >>>>>> m =. 134235395 >>>>>> 2^.m NB. plenty of room for multiplication in 64-bits??? >>>>>> 27.0002 >>>>>> >>>>>> 2!m >>>>>> 9009570568285316 >>>>>> datatype 2!m >>>>>> integer >>>>>> >>>>>> (-:<.@*<:)m >>>>>> 9009570568285316 >>>>>> ((*<:)m)<.@%2 >>>>>> 9009570568285315 >>>>>> _1 (33 b.) (*<:)m >>>>>> 9009570568285315 >>>>>> >>>>>> datatype (*<:)m >>>>>> integer >>>>>> >>>>>> So - why am I getting 2!m returned as integer but wrong? If there's >>>>>> overflow, >>>>>> why isn't it a float? Why does (-:<.@*<:)m return the wrong >>>>>> integer when >>>>>> ((*<:)m)<.@%2 yields the correct integer? >>>>>> >>>>>> This was in J.04, >>>>>> Engine: j9.4.2/j64avx2/windows >>>>>> Build: commercial/2023-04-10T01:19:53/clang-15-0-7/SLEEF=1 >>>>>> >>>>>> I haven't checked behaviour in earlier releases. I didn't try >>>>>> extended integers >>>>>> for this problem. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Mike >>>>>> >>>>>> >>>>>> >>>>>> ---------------------------------------------------------------------- >>>>>> 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
