EdgeTX
weight in mixers uses rounddown on source and results in wrong results
Is there an existing issue for this problem?
- [X] I have searched the existing issues
What part of EdgeTX is the focus of this bug?
Other (Please specify below)
Current Behavior
On a mixer line, when using a % weight on a source (that is actually stored as an integer between -1024 and 1024), the result will be stored as an integer between -1024 and 1024 (as well).
Since 90% of 1024 is not a whole number, but 921,60, it needs to be rounded for storage.
Currently, the way to round is to simply rounddown to zero (at least, that is what I can confirm with these screenshots.) This will lead to a wrong representation when converting back to %. It will also lead to wrong calculations when using weight in mixers as input for other functions.
Expected Behavior
Since sources are stored in integers between -1024 and 1024, and are shown as % of 1024, rounding issues will occur. Weight or offset calculation needs to be done in such a way that they are 'reversable'. Otherwise, errors will propagate through the calculations.
If using standard rounding for the % values of the 1024 scale, the resulting (rounded xx.x) % representations when converting back are identical. This means that standard rounding would already create reliable behavour for multiplications.
But if you choose to represent values in % with one decimal point, also all additions and substractions need to be reversable if you don't want to make wrong calculations. Theoretically, it would actually be best to convert any 1024 scaled value to a rounded 100.0% scaled value, and do math operations only on those rounded 100.0% scaled values, and then convert back to the 1024 storing scale.
Steps To Reproduce
set 90% on weight for a MAX input, and check the mixers monitor. It will show 89,9%.
See attachements.
Version
2.7.1
Transmitter
FrSky X9D+
Anything else?
No response
You don't need a rounding function if that would slow things down to much. A conversion table for 1024 scaled values to the rounded 100.0% values would work also, and perhaps faster. But 'm no programming expert.
But it is not an easy problem to solve. example of simple rounding, where the values 1003 and 1002 would both be mapped on 97,9%, but the difference would give 0.1%.
using a table would prevent this, and exclude for instance the 1002 or 1003 value. It would literally mean that you would loose accuracy.
If you really would like to stick to a mixed system of representation and storage in different scales, storing the 100.0% values on a 1000 scale value, and loose 2.4% of resolution, would be the best option.
anyway, the current, legacy, and very hard to change storage range of -1024-1024, in combination with a comprehensible -100,0 - 100.0% display range was perhaps not the best choice.
I would understand if it wouldn't change, but I think it is really BAD....
This is not good.
It seems the software is using ROUNDDOWN instead of ROUND calculation. Following I compared
MS XLS, x% can be correctly calculated back from ROUND column.
Be aware, a more solid solution would be to map all values on a -1000 -> 1000 integer instead of the current -1024 -> 1024 range.
But that is perhaps a huge change