Frink may be easier to install and run than you think on most operating systems:
* Have Java installed ( https://t.co/xdhZUv2ofY ) On Fedora Linux “dnf install java”
* Download the Frink .jar file https://t.co/lfKLQ2LAHb
* Double-click that file!
@TheCinesthetic The Doctor Who episode "Blink" has an IMDB rating of 9.8 out of 10 (I've never seen any rating that high) and is probably better than any sci-fi movie extant.
Getting the Jacobi symbol function is important. It's actually REALLY important for cryptography. So I hope the author of the article above gets it right and makes it correct for cryptography. 19/19
To contrast, I received the bug report one morning, and I was ashamed that I didn't have time to fix it before I left for work. I fixed it when I got home that day. Compare that to Java taking *3 years* to release a fix. 18/
Here's a link to a Frink implementation of the Jacobi Symbol. It gets things right if "a" is a negative number, unlike the top-linked article, and is usable for cryptography or Lucas-Lehmer tests.
https://t.co/HVRlRUdGQ1
16/
I'm going to go off on a thread about this post and why getting it right is important and how getting this calculation wrong had huge implications on breaking encryption and security in Java! Misunderstanding an operator (mod, also written %) might break all your security! 1/x
For a long time, the behavior of the C-language implementation of the modulus operator "%" was undefined! They just let it do whatever you wanted to do for negative arguments! That was really bad and made lots of programs into time bombs! 15/
It is because of this difference that EVERY SINGLE USE OF THE MODULUS OPERATOR "%" IN BOOKS AND IN PAPERS SHOULD BE METICULOUSLY DEFINED AS TO THE SIGN CONVENTIONS. Most book or cryptography authors or compiler writers don't even know there's an issue. 14/
So, what is the source of this bug? It's partially that many different programming languages define the modulus operator (often written "%") differently. They behave differently if some of the arguments are negative! 13/
This was *drastically wrong*! It let Java's implementation of BigInteger.isProbablePrime return wrong values for years! This had huge impact on cryptography and security. 12/
Here's a link to the Java bug:
https://t.co/BcZVWe9EL7
Note that they use the Jacobi symbol function in the Lucas-Lehmer test, but their implementation is wrong for negative numbers. And negative numbers were used! 11/
The assertions in the top-mentioned code may prevent "a" from being negative but it also prevents its version of the Jacobi symbol code from being usable in primality tests. 10/
The latter fixes the algorithm to work with negative values of "a". The short answer and fix is:
a = a mod n
if (a < 0)
a = a + n
This makes the algorithm (and primality testing) work correctly. 9/
The reference in the article to Algorithmic Number Theory, by Eric Bach and Jeffrey Shallit is insufficient. The input values should be corrected as outlined in Algorithm 2.3.5 in Prime Numbers: A Computational Perspective by Richard Crandall and Carl Pomerance. 8/
This leads to drastic errors! In primality-testing code, like Lucas-Lehmer tests, the first argument "a" is often negative. But if your Jacobi symbol function doesn't handle that negative value correctly, you return unsafe and wrong values! 7/