From my perspective, we lose fewer bits of precision converting
integer to float than we lose tossing an array and producing a domain
error.

That said, in the context of m. it might make sense to use rational
infinity rather than IEEE-754 infinity when an integer result is
larger than 2^53. This differs from the conversion table at
https://www.jsoftware.com/help/dictionary/dictg.htm but we could
conceptualize this as m. producing an extended result which is
downgraded to a smaller representation when the result would fit and
promoted to rational for error cases.

-- 
Raul

On Fri, Apr 28, 2023 at 8:00 AM 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

Reply via email to