Error in variable value

[Alex P]

the variable v4 v5 is assigned the temperature value with one digit after the point; in system variables it is displayed; it is sometimes displayed with a much larger number of digits and is displayed in text mode in the same way.
in the sensor settings there is one digit after the dot

[TD-er]

With taskvalues you know where to look for the intended number of decimals as it is defined in the task itself.

However with variables you have no idea where to look for the number of decimals.

You can however format anything that's being referred to via the [...#...] notation. (at least it should work, never tried it for variables)
See: https://espeasy.readthedocs.io/en/lates ... red-values

So I guess [var#1#D.1] will probably format the value using 1 decimal when processing it.

I guess you're running into issues when comparing the value in rules, right?

Code: Select all

if %v1% = 23.8

Must then be replaced by this:

Code: Select all

if [var#1#D.1] = 23.8

I do check for some floating point inaccuracies in the code, but there will always be corner cases where you may run into these kind of issues when comparing floats.
Maybe in the compare function, I could try to figure out the number of decimals when comparing for equality, but this still isn't a perfect solution for each and every other situation as there will always be corner cases where you get unexpected results when working with floats.

[Alex P]

No, the problem is not in comparison. Problem with display output. I don’t understand why, when assigning the value 23.8 to a variable, it turns out to have 23.799999.
Let,9,[var#5#D.1] I tried the same thing, it doesn't cut

[Ath]

No, the problem is not in comparison. Problem with display output. I don’t understand why, when assigning the value 23.8 to a variable, it turns out to have 23.799999.
Let,9,[var#5#D.1] I tried the same thing, it doesn't cut

You should use that formatted version when displaying the value using "7dtext,[var#5#D.1]H". After assignment it will be still stored as a float, with all rounding/accuracy issues described above

[TD-er]

This is an issue when working with floating point values on a computer.
There are some values you can't represent exactly when using binary floating point values, just like with the decimal system we use.
For example you cannot exactly represent 1/3 in decimal notation.
No matter how many decimals you use, you will never represent exactly 1/3.

So let's assume you write down on paper "0.33333 x 3"
The answer should be 0.99999
Thus strictly speaking, when you write down 1/3 and then multiply it with 3, you will end up with something that isn't equal to 1.

The same for binary representation of floating point values.
For some values, you will see rounding errors occur.

[TD-er]

Floating point calculations can be compared with how we do decimal calculations, but only then with a fixed number of decimals and optional exponent representing powers of 10.
Just like you did during math at school when you had to use a number of significant digits.

So let's assume you can only use 3 digits to represent a number.
e.g.
0.123 (= 1.23 x 10^-1)
1.23 (= 1.23 x 10^0)
12.3 (= 1.23 x 10^1)
123 (= 1.23 x 10^2)
1230 (= 1.23 x 10^3)

As you can see, in this notation with only 3 digits, you can't distinguish between 1230 or 1234 for example.

Also there isn't a perfect 1-to-1 conversion for binary floating point values to decimal and back.
Some number simply cannot be represented in binary floating point representation and thus cause rounding errors.

[Alex P]

Thanks for your clarification. I understand your point.

[Alex P]

You should use that formatted version when displaying the value using "7dtext,[var#5#D.1]H". After assignment it will be still stored as a float, with all rounding/accuracy issues described above

Thanks for your idea. Everything worked.

[Alex P]

Also there isn't a perfect 1-to-1 conversion for binary floating point values to decimal and back.
Some number simply cannot be represented in binary floating point representation and thus cause rounding errors.

Still, I don’t understand why the number 23.6 from the sensor, presented in binary form, when written to a variable, becomes 23.599999. After all, no transformations occur with it, and the same number should be preserved in binary form.

[TD-er]

What kind of build are you using?
Looks like it might be an ESP8266 with some build where LIMIT_BUILD_SIZE is enabled to make it all fit (nearly all "collection" builds for ESP8266)

Those builds use the "float" type when dealing with floating point values and storing variables in memory.
On ESP32 and ESP8266 builds which have this not set, variables are stored internally as "double".

Anyway, I am now as we speak looking into the code handling these floating point values and I think I can make it a bit more praktical to use and less error prone when trying to match event values for example.

Still there will always be some rounding errors.

For example, if you are using a build which does use "float" to store variabled in memory, you can easily test this.
A float type can only store about 6 - 7 decimals.

Thus 1000000000 (1 with 9 zeroes) and 1000000001 cannot be distinguished from eachother when using a float representation.
This is the same rounding error as with 23.599999 instead of 23.600000

[Alex P]

What kind of build are you using?

Build: ESP_Easy_mega_20240414_normal_ESP8266_4M1M Apr 14 2024
Build: ESP_Easy_mega_20240414_normal_ESP8266_1M_VCC Apr 14 2024
I noticed this on two devices on these builds