Don't you have a calculator?
I have a calculator, of course - and performing the rpm calculation with a value of dpm of 0 will of course, be equal to 0. My point is, that the value of rpm displayed with button presses is non zero, whilst dpm displays as 0. So it seems that the Arduino knows there are more decimal places there, but won't display them. Maybe I misunderstood the meaning of your question "don't you have a calculator?"
Larger values do not translate into more accurate results. The time between pulses will be shorter, so you'll theoretically calculate rpm more often, but no more accurately.
I do not quite agree, as shaft speed increases - dpm will get larger, as more degrees will be passed per micro. Thus, rounding errors will be much less as the value of dpm is larger, correct?
Times are NOT floats.
Of course, they are reported as integer values.
One last thing. You are copying variables that are larger than byte sized. What happens if, during that copy, an interrupt occurs that changes timer_pulsecount or p_lastpulse?
Umm, I simply don't know, actually.
This, in loop(), is absolutely NOT the last time a pulse occurred. A better name is definitely required.
I am not implying here that c_lastpulse = micros() is the last time a pulse occurred. The last time it occurred, is c_lastpulse - p_lastpulse. The p_lastpulse term is saved during the ISR.
You only need two times - the last time you reported rpm and now. The value of rpm is then a function of the number of pulses received in that interval and the internal.
If it's been a long time since a pulse occurred, so what? The pulse count in that interval will be 0, so the rpm will be 0.
With all due respect, of course - I disagree with this. For most applications, I see no problem with the method you have proposed. However, due to the rapid accelerations, be they positive or negative, that the shaft here being sampled will undergo - simply waiting for a set time, and counting the number of pulses in that time will not be anywhere near accurate enough. Sampling at 50ms intervals for example, will produce a different level of accuracy at 1000rpm than it would at 7000rpm.
Also, look at the order of operations in your code. You compute rpm and then possibly update the time variables. That doesn't make sense. The last thing to do is use the pulse count over some period of time to determine rpm.
To solve this, and save on processor usage. I will put this piece of a code in a statement that will only execute the calculation if threetimepulsecopy is different from last time the calculation was performed.