Timeline for Write the most optimized assembly program to detect a prime number (from a bigger range!)
Current License: CC BY-SA 4.0
26 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 6, 2022 at 9:54 | comment | added | xiver77 | @graffe I'm actually devising a task, this time in a real machine with real programming languages. I'm currently testing for adequate ranges. I'll put on sandbox as soon as things are arranged. | |
| Jan 6, 2022 at 9:05 | comment | added | user108721 | Doing this with 64 bit integers would be more interesting imho. | |
| Jan 5, 2022 at 5:21 | comment | added | xiver77 | @harold It seems actually hard-coding all possible prime divisors performs well up to a quite large range. Have a look at my posted answer, and I also found an interesting paper. | |
| Jan 5, 2022 at 5:16 | answer | added | xiver77 | timeline score: 2 | |
| Jan 3, 2022 at 12:00 | history | tweeted | twitter.com/StackCodeGolf/status/1477973040457728008 | ||
| Jan 2, 2022 at 18:10 | history | edited | xiver77 | CC BY-SA 4.0 | deleted 24 characters in body |
| Jan 2, 2022 at 8:05 | comment | added | xiver77 | @harold Maybe its just the nature of this task. Trial division won't scale well for arbitrarily large numbers, but maybe that is the most efficient solution when the numbers are small. | |
| Jan 2, 2022 at 7:45 | comment | added | user555045 | Bad news: I was halfway into implementing something way crazier than anything before (doing Miller-Rabin with Montgomery multiplications, and reducing code-duplication by hacking together a call/return mechanism based on a return-stack-in-a-register and a dispatcher that jumps to various labels based on the value in a register) and then I ran out of registers. But, I cannot promise that that approach is any good anyway, given its large code size and its low options for "bailing out early" compared to trial division. | |
| Jan 2, 2022 at 1:48 | history | edited | xiver77 | CC BY-SA 4.0 | added 21 characters in body |
| Jan 1, 2022 at 10:25 | history | edited | xiver77 | CC BY-SA 4.0 | added 269 characters in body |
| Jan 1, 2022 at 9:55 | comment | added | xiver77 | @RedwolfPrograms Now, the program should output the correct result for all possible input. | |
| Jan 1, 2022 at 9:53 | history | edited | xiver77 | CC BY-SA 4.0 | added 1532 characters in body; edited title |
| Jan 1, 2022 at 6:04 | comment | added | Bubbler | One possible approach could be spamming if-else constructs in the binary search manner, giving ~15 branches per input. | |
| Jan 1, 2022 at 4:17 | answer | added | user555045 | timeline score: 5 | |
| Jan 1, 2022 at 3:27 | comment | added | rydwolf♦ | Are we allowed to assume the input is between 2 and 10000, and return the wrong answer for anything else? | |
| Jan 1, 2022 at 3:05 | history | edited | xiver77 | CC BY-SA 4.0 | added 4 characters in body |
| Jan 1, 2022 at 2:59 | history | edited | xiver77 | CC BY-SA 4.0 | edited body |
| Jan 1, 2022 at 2:47 | history | edited | xiver77 | CC BY-SA 4.0 | edited body |
| Jan 1, 2022 at 1:29 | history | edited | xiver77 | CC BY-SA 4.0 | edited body |
| Jan 1, 2022 at 1:25 | comment | added | Luis Mendo | Related | |
| Jan 1, 2022 at 1:16 | comment | added | user555045 | Maybe, but nothing particularly interesting. Reverse-subtract would be more useful in its place, but I'm not actually planning to use it for this task.. | |
| Jan 1, 2022 at 1:13 | comment | added | xiver77 | @harold Do you think keeping neg will make some useful optimizations available? | |
| Jan 1, 2022 at 1:05 | history | edited | xiver77 | CC BY-SA 4.0 | added 375 characters in body |
| Dec 31, 2021 at 16:58 | history | edited | xiver77 | CC BY-SA 4.0 | added 60 characters in body |
| Dec 31, 2021 at 16:30 | history | edited | xiver77 | CC BY-SA 4.0 | added 4 characters in body |
| Dec 31, 2021 at 16:02 | history | asked | xiver77 | CC BY-SA 4.0 |