There are technical difficulties associated with this approach that would require a significant rework to the rewards code. Not to mention the difficulty in calculating fractional exponents using integer math. We cannot use floating point numbers because they are notoriously nondeterministic and have no place in a blockchain. (I am assuming the exponent would be in the range [1,2]).
Does this mean that it would be tough to do any fractional exponent or just that it would be difficult to repeatedly change the exponent according to witness votes?
Any fractional exponent. Keeping the numbers from overflowing is difficult as well. n^5/8 would be n^5 * n^1/8. Raising to the 5th power would require a 512 bit integer and then we would have to implement 1/4 as three square roots. (For the devs out there, we have created a deterministic square root algorithm that is quite fast). We would need dynamic big ints to prevent overflow from strange powers.
I like that
BitShares allows parameters like fees to be controlled by witnesses, yes? I wonder if we could do something similar here.
There are technical difficulties associated with this approach that would require a significant rework to the rewards code. Not to mention the difficulty in calculating fractional exponents using integer math. We cannot use floating point numbers because they are notoriously nondeterministic and have no place in a blockchain. (I am assuming the exponent would be in the range [1,2]).
Hahah. I want this on a T-Shirt. :)
Haha, me too :)
LOL, me three!
Did you ever get this t-shirt?!
I'm enjoying reading back though the comments here today - behind my hands at times!
Sounds like if we went that route, it would take a really long time to implement.
Does this mean that it would be tough to do any fractional exponent or just that it would be difficult to repeatedly change the exponent according to witness votes?
Any fractional exponent. Keeping the numbers from overflowing is difficult as well. n^5/8 would be n^5 * n^1/8. Raising to the 5th power would require a 512 bit integer and then we would have to implement 1/4 as three square roots. (For the devs out there, we have created a deterministic square root algorithm that is quite fast). We would need dynamic big ints to prevent overflow from strange powers.
Thank you very much. I hate when my numbers overflow!
(Kidding! I really do appreciate you taking the time to help me understand this stuff.)
I really like this approach.
Awesome idea