Consider solving for y in
9y = 5 mod 7, ie
2y = 5 mod 7
Brute force is one way:
2 * 1 2 3 4 5 6 mod 7
2 4 6 1 3 5
So 6 is the answer, and, incidentally, 4 is the mod 7 inverse of 2, 9, 16, etc
The (Extended) Chinese Remainder method is a better approach, and Fermat’s
Little
Theore
> 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
wrote:
In the next beta u m. n me
So m. is (or rather, will be) new, not old... Brilliant!
Thanks,
Mike
Sent from my iPad
> On 17 Apr 2023, at 19:56, Henry Rich 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&^
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 Da
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 a
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, A
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
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, th
You don't have 64 bits - you have 53 because you have gone into
floating-point.
(-:<.@*<:)m gives 9009570568285316 because the operation is promoted to
floating-point when you divide, and it looks like you get roundoff in
the multiply.
Multiplying first is better, but you are still liable to
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 dive
10 matches
Mail list logo
