I don't see that (%!.c m. n) is better than (% m. n) :: c and it's a lot
more work for me.
Usual rules? What would the shape of (i. 4) (+ m. (5 6 7)) i. 4 5 be?
We would have to establish new rules.
Henry Rich
On 4/28/2023 10:42 AM, 'Mike Day' via Beta wrote:
2 things:
a) how about qualifying the behaviour of u with !. ?
In the absence of !. , return a domain error where called for;
However, (%!.c m. 10 (2)) for some number c would return c wherever appropriate
in the resulting array. Similarly for dyadic % and ^ .
b) It appears that n in {x} (u m. n ) y must always be scalar. Is there a
possibility of
allowing n's shape to conform with y (say) with the usual rules for arguments of
different rank?
Mike
Sent from my iPad
On 28 Apr 2023, at 13:00, Henry Rich <[email protected]> wrote:
I am OK with (0 % m. n 0)'s giving 0, in accordance with J's properties of 0.
(0 ^ m. n 0) should likewise give 1.
(% m. n 0) is a different case. Should it return _? Can it be good design to
have a primitive whose whole purpose is to confine its range, and then have it
give a result that is out of range? Worse than that, a result that loses
precision on integers and requires conversions? I don't see analogy to the
real numbers as a sufficient argument; and the fact that _ is not a number is
particularly important when the range is integers. Domain error seems the
better solution, pending further discussion.
(% m. 10 (2)) seems to me different altogether. Domain error is the best way
for the user to handle these exceptions.
BTW, in earlier J versions u :: v was pretty slow when u failed: the code
prepared for debugging, allocating blocks and formatting error messages. As of
J9.4 u :: v transfers directly to v when u fails, with low overhead.
Henry Rich
On 4/27/2023 3:16 PM, Raul Miller wrote:
Hmm...
Looking at this, the domain errors do seem analogous to divide by zero errors.
So, in the context of %m.n, if we were being purely symmetric, a 0
result when both the numerator and denominator were effectively 0
would be the way to go, with an infinite result for the remaining
cases. (Infinity in modulo arithmetic seems a bit awkward, but I don't
have any better suggestions there.)
And, I suppose similar thinking might hold for monads?
Thanks,
----------------------------------------------------------------------
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
