Using the number "e" for mining hashrate calculation: how popular is it

I'm working on a mining pool that implements Stratum 2 in Rust (SRI), and I ran into a question about how to calculate a miner's hashrate based on the difficulty of the shares they submit. I did some quick experiments and found this algorithm to be the most precise: 1. I gather the shares from the miner over a timeframe, like 10 minutes. 2. I determine the difficulty for each share (share_diff = max_target / hash). 3. I identify the share that corresponds to the (1 1/e) percentile, which is around the 63rd percentile in terms of difficulty. 4. I take the difficulty from step 3 and multiply it by the total number of shares. 5. I then multiply that result by 1/e (about 0.37). 6. Next, I multiply by 2^32 to get the total number of hashes that had to be iterated through to find those shares. 7. Finally, I divide by the number of seconds (so for 10 minutes, that’s 600 seconds) to arrive at the hashes per second. If anyone is better at coding (I can't guarantee the accuracy, it was generated by AI from my description). I’ve got a couple of questions: 1) Is this method something that a lot of people know about? What other options are out there? 2) Why does this even work? I’ve got too much on my plate with this project and can’t get into theoretical math right now, but I’m really curious about why the number "e" is significant here. Is there another way to write this algorithm?

I was unable to figure out how the math worked in the short time I had to look at your description, but computing the "difficulty" of a hash is never useful, especially as a way to determine hash rate. My quick guess is that since you are using the total number of hashes over ten minutes in the computation and then later dividing by 600 seconds, that is where the hash rate is coming from. The two computations involving e are probably cancelling each other.