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
