I suppose the second addendum to the numbers was glossed over slightly. It says this:
[2] Fractional parts may be problematic, since many decimal fractions cannot be represented exactly as binary fractions.
That would seem to indicate that it is better to use Integers then decimals or other real numbers. At least since they may not get the same value that the server sends.
I agree that using real numbers here is not the best idea. Unfortunately, stratum's protocol defines this as a Number represending a multiple of bdiff 1 (difficulty 1 subject to bitcoin rounding rules), which cannot reasonably represent traditional pdiff targets (which are easier to check). Additionally, EclipseMC has been using fully variable targets anyway.
I expect during stratum's BIP discussions, consensus will probably determine using a target as getwork and GBT do (without these problems) is the proper solution.
Actually I have an idea on how to suggest handling it I may see what Con thinks.
BFGMiner handles it by truncating the difficulty (with a special case of pdiff 1 for difficulties under bdiff 1) and letting the server reject shares that it doesn't think meet its target. This results in some degree of rejected "high-hash" shares, but it guarantees no valid ones are lost.
If you fail at math, it's a problem, if you don't, then the risk of losing (or gaining) one share in maybe every few billion-trillion is pretty much irrelevant.
That one share lost in a few billion-trillion can never be a block, so it doesn't matter.
...
Anyone who tries to force the old pool difficulty used onto Stratum, simply needs to complete school level maths first, and then think again.
The lost shares related to checking the difficulty will be if the pool implementation of the same is faulty and allowing in shares that are below what the pool specifies, or rejecting shares that are above what the pool specifies.
