Hey guys, just wanted to touch base.
I'm at the point where I have a good feel for exactly where and how the Swing core can be improved. I'm on a buisness trip this weekend but when I get back I'm going to work on pulling together/finalizing and posting the proposed upgrade.
I plan to explain the issues currently occurring in the code with example debug logs, along with the difference the upgrade would make. That way everyone can easily understand the issues and see what it is were talking about changing.
Thanks guys. More info to come later.
Looking forward to hearing more about that. Incidentally I have had not wallet or staking issues that I'm aware of, running two wallets, one on WIN 10 and one on WIN 8.1 both 64 bit systems.
I dont have any issues here either, i had in the beginning but not the past 3 months or so. WIN10 64 here
Just for clarity sake I haven't had any issues myself either. I went out of sync once weeks ago when i was offline for a while but aside from that no problems.
I'm just going off what people have reported as opportunities to strengthen the core code.
Let me give some insight.
I've recently been digging into what happens with the rewards when they are calculated, and exactly what's going on when getting calculated.
With the current setup, that process looks something like this:
Block Count: 975 Last Three: 975 Decimal: 9.75 Final:975000000
Count: 976 Three: 976 Decimal: 9.76 Final:976000000
Count: 977 Three: 977 Decimal: 9.77 Final:977000000
Count: 978 Three: 978 Decimal: 9.78 Final:977999999.99999988079071044921875
Count: 979 Three: 979 Decimal: 9.790000000000001 Final:979000000.00000011920928955078125
Count: 980 Three: 980 Decimal: 9.8 Final:980000000.00000011920928955078125
Count: 981 Three: 981 Decimal: 9.81 Final:981000000
Count: 982 Three: 982 Decimal: 9.82 Final:982000000
Count: 983 Three: 983 Decimal: 9.83 Final:983000000
Count: 984 Three: 984 Decimal: 9.84 Final:984000000
Count: 985 Three: 985 Decimal: 9.85 Final:985000000
Count: 986 Three: 986 Decimal: 9.86 Final:986000000
Count: 987 Three: 987 Decimal: 9.870000000000001 Final:987000000.00000011920928955078125
Count: 988 Three: 988 Decimal: 9.88 Final:988000000.00000011920928955078125
HERE is the section of code that spits this out. I just used block 1 - 999 as sample output. For the sake of clarity i re-coded the process in java for faster debugging. (im just better at java is all, but java may produce slightly different results is the point)
So what I discovered is that somewhere else in the code the decimal is inserted into a full number with 9+ digits.
The end result in this section of code that gets passed out looks something like '9.87 * COIN' (=987000000).
Me attempting to put in the decimal during the reward calculation instead of letting it do it after results in some unnecessary math. Math that doesn't always turn out clean, and leaves room to lose accuracy when clipping/rounding the final result to a full number.
I'm working on re-coding this section so a result like this:
Count: 987 Three: 987 Decimal: 9.870000000000001 Final:987000000.00000011920928955078125
Acts like this:
Count: 987 Last Three: 987 Final:987000000
Now, this is an example of POS. POW gets a little more challenging since rewards need to be multiplied by 10%.. 20%.. 30%.. etc.. But I'm working on doing that cleanly too.
But that's essentially where we have room for core upgrades and cleaning up the internal math for increased accuracy.
So that should give you guys a little better idea at what I've been looking at.
Will post more later as I make progress.