Error in variable value
Moderators: grovkillen, Stuntteam, TDer
Error in variable value
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
in the sensor settings there is one digit after the dot
 Attachments

 Снимок2.JPG (65.63 KiB) Viewed 1070 times

 Снимок1.JPG (34.93 KiB) Viewed 1070 times

 Снимок.JPG (71.65 KiB) Viewed 1070 times
Re: Error in variable value
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 ... redvalues
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?
Must then be replaced by this:
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.
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 ... redvalues
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
Code: Select all
if [var#1#D.1] = 23.8
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.
Re: Error in variable value
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
Let,9,[var#5#D.1] I tried the same thing, it doesn't cut
Re: Error in variable value
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
/Ton (PayPal.me)
Re: Error in variable value
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.
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.
Re: Error in variable value
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 1to1 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.
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 1to1 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.
Re: Error in variable value
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.
Re: Error in variable value
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
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
Who is online
Users browsing this forum: Ahrefs [Bot] and 1 guest