> Example: 5 % m. 7 (9) gives 5 *(mod 7) (inverse of 9(mod 7))
example is not clear to me:
is 5 % m. 7 (9)
7 | 5 % 9 NB.?
I don't understand % as a typical application of modular arithmetic.
On Monday, April 17, 2023 at 02:56:28 p.m. EDT, Henry Rich
<henryhr...@gmail.com> wrote:
In the next beta u m. n means 'u(mod n)' and will work for + - * % ^ .
%. coming soon.
The only specials I see with m&| are m&|@^ and m&|@(n&^) which can be
replaced by [n] (^ m. m) y.
Example: 5 % m. 7 (9) gives 5 *(mod 7) (inverse of 9(mod 7))
Henry Rich
On 4/17/2023 2:07 PM, 'Michael Day' via Programming wrote:
> 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 <
>> 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
>
> ----------------------------------------------------------------------
> 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
