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 < programm...@jsoftware.com> 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
