Desmos, 124 50 bytes
f(a,b)=∑_{n=a}^bnsgn((n-1)∏_{k=3}^nmod(n,k-1))
Try it on Desmos!
I had to waste 23 bytes just for the edge case of 0 and 1(-\left\{n<2:1,0\right\}
). I feel like this could definitely be golfed further, but I'm not that skilled at Desmos. I especially think that the edge cases 0 and 1 could be handled a lot better than what I'm doing currently.
To think I've come so far... just a mere 2.5 years ago I was still a complete noob at Desmos golfing. Now, coming back to this answer 2.5 years later, there are so many golfs that I can spot. Shifting the bounds to remove the curly brackets, better ways to deal with the n=1
edge case, and some other tiny golfs, resulted in an over 50% reduction in my original code. Truly amazing stuff.
Explanation
I will explain each sub-expression a little out of order from the actual code, but I feel that this is the best way to understand what the code is doing.
∑_{n=a}^b
: Summation from n=a
to b
. This will iterate through all integers between a
and b
inclusive.
∏_{k=3}^nmod(n,k-1)
: This takes the product of k=3
to n
of mod(n,k-1)
which essentially tests all the possible divisors between k=2
and n-1
, and checks if n
is divisible by k
with mod(n,k)
(it is mod(n,k-1)
in the actual product, which will be explained further below). If n
is composite then at least one value of k
will make the mod
expression equal to 0
, making the entire product equal to 0
. Otherwise, if n
is a prime, then the product would be a positive integer. The reason why the product goes from k=3
to n
instead of the more intuitive k=2
to n-1
is because if the upper bound is represented by more than one character, then curly brackets are required to group the characters together. In other words, a product from k=2
to n-1
would be ∏_{k=2}^{n-1}
, which is four more bytes than ∏_{k=3}^n
. But because we have shifted the bounds of the product up by one, we will need to subtract one from all instances of k
in order to compensate for the shift. Hence, we have k-1
instead of k
in the mod
expression. This adds two bytes to our total code length, resulting in a net -2 bytes from doing this bound shifting. Now, because the bounds start from k=3
, what happens if n=1
or 2
? When the upper bound is lower than the lower bound, then the product will default to a value of 1
. This is an issue for the n=1
case, which will result in the product being a positive integer (specifically 1
), but that is undesirable because a positive integer implies that n=1
is a prime when in reality it isn't a prime. But there is a way to easily fix this...
(n-1)
: This expression is solely to deal with the n=1
case. When n=1
, n-1
is 0
which causes the entire product to equal 0
. For any other positive value, n-1
would simply be a positive integer and not affect the overall sign of the product. Note that this fix only works for testing primality for positive integers, but this is okay for our code because the problem specifies that a
and b
can be assumed to be at least 1
. To deal with the n=0
case as well, something like 0^{0^{n-1}}
would probably work.
nsgn( ... )
: This takes n
and multiplies it by the sign (sgn
in the code) of the entire product expression. Remember that if the inside expression is a positive integer, then it is a prime; otherwise, it is composite. By taking the sign of the resulting integer, we will get 1
if n
is prime and 0
if n
is composite. Multiplying that by n
will give n
and 0
for the respective possibilities.
Now considering that we are taking a summation from n=a
to b
, this will essentially add n
to the total sum if n
is a prime, but it won't contribute to the sum if n
is a composite. In other words, it takes the sum of all integers between n=a
and b
which are prime. With that, we are done.