b) (u m. n) has a little overhead that you can avoid by assigning the
value to a name. It's worth worrying about only if you have loops that
apply a single modulus to integer atoms. If there are extended integers
about, or arrays, the overhead is negligible. In many applications a
single modulus is repeatedly used.
Henry Rich
On 4/28/2023 11:25 AM, 'Michael Day' via Beta wrote:
Thanks
a) OK - (% m. n) :: c is nice, simpler than I realised it need be!
I did wonder how easy (hard!) it would
be to implement the !. qualifier.
b) Performance worries me in that case. Would (u m. n) need
re-defining as a named verb for each instance of n ?
Cheers,
Mike
On 28/04/2023 15:48, Henry Rich wrote:
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
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
