Hi shabda. I've seen your version when I was searching if someone has done this before. And you are right, I did it in Javascript because I wanted to share it with the world more easily.
I used isProbablePrime() before, when I had a 50x50 canvas. But it was still really really really slow. After changing to a 32x32 canvas, the difference between isPrime() and isProbablePrime() seemed negligible.
That makes me think that their probable prime implementation isn't that great or else that they're losing a ton of efficiency to the Javascript interpreter.
$ time python -c 'import gmpy; gmpy.next_prime(2**2500)'
real 0m0.443s
Was it taking a lot longer than that for you?
Edit: I can see that there is an element of luck in terms of how many candidates you have to look at, but I'm still seeing everything in this size range take under 2 seconds. Maybe it's a question of what probability of error you're accepting from the test?
GMP is very well optimized and implemented in assembly. There's no way that a JavaScript implementation can get anywhere close to that performance since JavaScript doesn't even have support for 64 bit integers. WebAssembly might be faster, but is still lacking many instructions commonly used for big integer arithmetic.
That is very a good idea! For now it is stateless & frontend-only. But I was thinking on improving it, like a prettier UI and adding a "print" button, or maybe a "export to png". If I ever add a server side to it, it will feature a share & see option.
Afterthought: actually, I was thinking on using IPFS to store stuff, but I do not know if its model applies to this scenario. Feedback is appreciated.
You could link to a number by just adding a query or hash with the base64 encoding of the number in 171 characters. You'd lose the original image of course.
Edit: I bet a RLE would compress down really nicely except for the bottom row if you want to reduce URL sizes
These are very neat, but all of these I've seen the last few weeks use the same trick of putting some garbage at the end to make it a prime. I wish people would vary their techniques a bit: like, make it base 10 and make an ascii-art image, and introduce imperceptible noise to make it a prime. Or, vary the number of rows and columns, and maybe scale of the image, to make it prime.
We need to disrupt the "images as primes" industry!
Can you use this for encryption? Make the decryption key the prime number generated by this, and you unlock it by pointing the camera at the right thing?
I guess it could change the whole image if the last pixels are "000...000", which happens when the top-left corner has an opposite color to the bottom-right one.
Incrementing… So pixels at the bottom right of the image are the most likely to be flipped from the source image. Interesting. (Edit: Assuming big-endianness and left-to-right, top-to-bottom printing of the pixels/bits)
Nonetheless, yes, using this to create security keys would probably be a good way to lose your bitcoin. :D
Clearly the current implementation is not enough, but I wonder if there is a way to do this properly with actual security, and yet be reproducible for a normal human (we can assume the same camera and lighting).
Maybe some kind of marker in the image that is used for cropping and scaling?
Being able to see a particular image, and at a particular time of day (or indoors I guess), would definitely be an interesting security key.
(Hollywood: feel free to take this idea and do it badly :)
So. In some cases, which I couldn't isolate, it finds the prime but won't stop the program. On average, it should only need from 400 to 600 iterations.
Would it not be preferrable to change as little bits as possible? Instead of counting up from your number you should first try to change single bits (one bit, two, three ...)
Changing a single out of 3232 bits gives you 1024 variations. Changing two already gives you 10241023/2 = 523776 variations.
I put up a show HN, but no one liked it :) https://news.ycombinator.com/item?id=16198861